aspnetcore: ProblemDetails is not returned for 404NotFound and 500Exception

Describe the bug

Given a new ASPNET Core 2.2 “API” Website, ProblemDetails are not returned when:

the route doesn’t exist (404 Not found)
an exception is thrown from inside an ActionMethod.

I understand that currently ProblemDetails are provided when a Controller is decorated with ApiController. So the first scenario (route doesn’t exist/match) can’t currently be handled. The second scenario (exeception thrown) is inside an Controller/ActionMethod that has been decorated.

ProblemDetails should apply globally, not just on a half-specific set of scenario’s. This breaks application-consistency.

Currently, the only workaround is to use @khellang 's ProblemDetails nuget library (part of his ‘Middleware’ repo).

Would be very helpful to either consider: a) implementing the full functionality b) just removing it because the current implementation feels inconsistent / half-complete. (NOTE: please don’t remove it! lets complete it!!)

To Reproduce

Open Visual Studio 2018
File -> New -> Project -> Visual C# -> Web -> NET Core -> ASP.NET Core Web Application -> API
Edit Startup.cs. Comment out \\ app.UseDeveloperExceptionPage();
Edit Controllers\ValuesController to (more or less) the following:

[Route("api/[controller]")]
[ApiController]
public class ValuesController : ControllerBase
{
    // GET api/values
    [HttpGet]
    public ActionResult<IEnumerable<string>> Get()
    {
        return new string[] { "value1", "value2" };
    }

    // GET api/values/5
    [HttpGet("{id}")]
    public ActionResult<string> Get(int id)
    {
        return Ok(id);
    }

    // GET api/values/notfound
    [HttpGet("notfound")]
    public ActionResult<string> Get2()
    {
        return NotFound();
    }

    // GET api/values/notfound/aaaa
    [HttpGet("notfound/{text}")]
    public ActionResult<string> Get3(string text)
    {
        return NotFound(text);
    }

    // GET api/values/exception
    [HttpGet("exception")]
    public ActionResult<string> Get4()
    {
        throw new Exception("pew pew");
    }
}

I’ve just added some specific routes to test problem details. (look below 😎 )

Test the following routes:
- ✅ https://localhost:7001/api/values/a (400 Bad Request)
- ✅ https://localhost:7001/api/values/notfound (404 Not Found)
- ❌ https://localhost:7001/api/values/notfound/aaaaaa (404 Not Found)
- ❌ https://localhost:7001/api/values/exception (500 Server Error)
- ❌ https://localhost:7001/api/values/sdfkdsjfhksdfh (404 Not Found and route doesn’t exist)

Expected behavior

At any time the response is 4xx/5xx I would expect the ProblemDetails to be returned.
Would love to have the option to specify wether exception details are included (default is not). This just helps when IsDevelopment mode.
Assumption would be to wire this up in Startup.cs.

Additional context

.NET Core SDK (reflecting any global.json):
 Version:   2.2.100
 Commit:    b9f2fa0ca8

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.2.100\

Host (useful for support):
  Version: 2.2.0
  Commit:  1249f08fed

Also using Visual Studio 15.9.4

polite cc @glennc

Thank you kindly for your awesome work and here’s Dwayne/TheRock singing sweet nothings to help persuade the decision process, here. Like, who would say ‘no’ to TheRock??

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 38
Comments: 36 (32 by maintainers)

Most upvoted comments

While the templates aren’t exactly wired up to do this, it does seem like there are enough building blocks to meet your goals. What do you think?

Yep - there are enough building blocks to do this. As a case in point, I did this nearly a year ago and have been using this in various .NET apps.

I guess my main request was to try and bake this more into the common template stuff. Part of the issue here was that having a webapi only handle some errors are problem-details feels like an incomplete solution. Think about it -> why would a webapi only return some errors as PD’s while other scenario’s as … not-PD’s?

So the discussion was more about having a consistent solution across a webapi template.

+13

PureKrome on Jun 14, 2019

@nsmithdev the current, best solution IMO is @khellang 's nuget. Works great.

that said this issue is about making that functionality the DEFAULT/BAKED IN. not a 3rd party. Yes, the 3rd party nuget is awesome but the suggestion/issue hits to the core of what an API is or should be. Right now, it’s a hybrid … which feels messy and confusing. So hopefully this issue will gather some traction behind the scenes to promote a consistent message and consumer experience of “api websites”.

PureKrome on Dec 3, 2020

👋 @pranavkm - thanks again for replying … I (we) really appreciate it.

it’s a non-trivial amount of work

Ok wait a sec. Hold up. ✋

This is a technical answer to the problem. Lets not even go down that path, just yet.

I was hoping to get a business/product answer about this.

So, regardless of the technical problems/solution … does the MS team think:

there should be consistency with the returning ProblemDetails across all facets in the framework?

ProblemDetails should only be returned for a subset of scenario’s in the framework. So some 4xx/5xx will return PD's and others will not [which is the current status quo].

And the answer is about the Product, nothing to do with tech.

PureKrome on Nov 9, 2019

Just want to mention that there are a lot of scenarios that this ProblemDetail isn’t returned. E.g. media type mismatch using the ConsumeAttribute.

I like the idea having a ProblemDetail, but as of now I have to turn it of need some consistency. IF this is ever going to be solved and we want to turn it on it will break the API’s which is unfortunate 😐

It’s pity this wasn’t thought through before implementing it in the first place and analyzed in all scenarios a status is returned in the framework. 😕

dozer75 on Feb 25, 2020

Polite ping to @glennc and @pranavkm 👋

.NET Core v3 is not far off and preview 7 is next. Any chance to try and include this in there before stuff is closed off?

pwitty pwease ?

PureKrome on Jun 13, 2019

Thanks @captainsafia for the update! Really appreciate it 😄 🍰

Despite not being the best answer, there’s still hope this can get some more love, next release. It’s nice to see that tough decisions can be made and then explained to us - so cheers.

@khellang your code lives for another day!

PureKrome on Jun 25, 2021

I agree with @PureKrome, the main reason, because I have enabled ProblemDetails, was one fine data structure to resolve problems with error handling. That’s really important. Please, consider how to include other status codes into ProblemDetails as default.

ukod on May 22, 2019

@khellang but I am 😃 and it’s great! Just seeing if the feature could be further expanded/completed or … not (which means we all stick with yours). It just feels incomplete, right now. Sure, this ‘might be as designed’ but I thought … when comparing your middleware to the one in MVC … there’s a heap of gaps.

I also understand that this can be compared to the MS IoC/DI vs structuremap, etc. (3rd parties). I feel that the MS DI is really usable for seriously most “common” scenarios - very workable. But comparing the the MS ProblemDetails stuff, I don’t think it’s complete for “common” scenario’s.

PureKrome on Dec 15, 2018

Y NO USE MY MIDDLEWARE? 🤔 😢

khellang on Dec 14, 2018

our philosophy has been to use ApiControllerAttribute to determine if a particular action should have web API-like behavior

The thing is, if your app is purely a web API (i.e. no UI controllers), the API-like behavior should apply to all calls, whether or not the route matches an API controller.

thomaslevesque on Dec 3, 2020

yay @captainsafia and @mkArtakMSFT! thank you! the API community will be happy to get this update.

bradygaster on May 19, 2021

Thanks for contacting us. We’re moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it’s not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it’s very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

msftbot[bot] on Apr 21, 2021

no route that matches … 404 and not a PD.

This is because the behavior is MVC-specific. If a path doesn’t match any routes, MVC won’t even touch the request and fall through. Without middleware to handle this on the way back, there’s no way to be consistent here…

Yep correct! that’s the technical reason why this is currently occurring. I’m hoping the product team can answer why they prefer this hybrid result and explain the reasoning for it. I’m not hating, just trying to learn and understand the decision, here.

PureKrome on Nov 7, 2019

/me tries poorly to jedi-mind trick Glenn…

PureKrome on Jan 8, 2019

@PureKrome here is the final API https://github.com/dotnet/aspnetcore/issues/42212#issuecomment-1183761752.

Basically, it is the introduction of the ProblemDetailsService that could be used everywhere. In the PR, the DeveloperExceptionHandler, ExceptionHandler and StatusCodePages middleware were updated to use it when nothing custom is defined.

That means, for your very initial example: ✅ https://localhost:7001/api/values/a (400 Bad Request) ✅ https://localhost:7001/api/values/notfound (404 Not Found) ❌ https://localhost:7001/api/values/notfound/aaaaaa (404 Not Found) ❌ https://localhost:7001/api/values/exception (500 Server Error) ❌ https://localhost:7001/api/values/sdfkdsjfhksdfh (404 Not Found and route doesn’t exist)

you could get a full ProblemDetails generation, adding this your code:

builder.Service.AddProblemDetails()

and adding the following middleware:

app.UseExceptionHandler();
app.UseStatusCodePages();

brunolins16 on Jul 20, 2022

Thanks for the feedback everyone! We took a stab at designing a solution for this for .NET 6. Ultimately, we realized that creating a robust solution that works well with all the scenarios we want to support (both MVC and the new minimal APIs) would require more time than we have for .NET 6, so this is going back to the drawing board.

For the moment, we recommend continuing to use the open source ProblemDetails middleware or building on top of the ExceptionHandler.

captainsafia on Jun 25, 2021

https://www.strathweb.com/2019/01/enabling-apicontroller-globally-in-asp-net-core-2-2/

Something like this built-in would be helpful for api only projects https://github.com/khellang/Middleware/tree/master/src/ProblemDetails https://andrewlock.net/handling-web-api-exceptions-with-problemdetails-middleware/

nsmithdev on Dec 3, 2020

@PureKrome it’s a non-trivial amount of work to move ProblemDetails and everything else required to configure and serialize it closer to the heart of the stack. We would need very compelling reasons to invest in something like this which we just haven’t seen as yet.

pranavkm on Nov 8, 2019

Cheers @pranavkm ! Okay - so nothing new has changed and the initial question still remains a valid one.

We understand that we can do some custom code to handle this stuff … but the root question remains valid, IMO. So far, what I’m reading is this (unfortunately):

If you return a 5xx/4xx from your ActionMethod, then a ProblemDetails will be returned.
Otherwise, it won’t -AND- we (Microsoft) want this ‘hybrid’ behaviour.

As such, can you please explain the reasoning for this hybrid behavior? To keep things simple, can you use the 404 example, please?

return 404 from an Action Method == PD.
no route that matches … 404 and not a PD.

PureKrome on Nov 7, 2019

@pranavkm thanks heaps for jumping into this issue 👍

Even if we configured it to handle 5xx status codes, we wouldn’t add an exception filter \ do exception handling by default

Ok - so based upon this answer, what you’re suggesting is that you think it’s totally fine/acceptable to have mixed results for a standard Web/REST Api website (** I hate those names to describe an API website but it’s a common way to describe these apps).

Mixed == sometimes we get problem details. Other times, we don’t get PD’s and (by default I think) just a status code.

An API website that returns PD’s for any non 200 response.

PureKrome on Dec 31, 2018