ProblemDetails is not returned for 404NotFound and 500Exception

[PureKrome]

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??

[wangengzheng]

try to use routetemplate [HttpGet("/notfound/{text}")]

[khellang]

Y NO USE MY MIDDLEWARE? 🤔 😢

[PureKrome]

@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.

[mkArtakMSFT]

Thanks for contacting us, @PureKrome.
@pranavkm, any suggestions? Thanks!

[pranavkm]

cc @rynowak \ @JamesNK for thoughts about 404 from routing. IMO, our philosophy has been to use ApiControllerAttribute to determine if a particular action should have web API-like behavior. We cannot make that determination for a 404 for an action that does not exist.

It's fairly trivial to configure the filter to respond to additional status codes (https://github.com/aspnet/AspNetCore/blob/release/2.2/src/Mvc/src/Microsoft.AspNetCore.Mvc.Core/ApiBehaviorOptions.cs#L194-L203). Even if we configured it to handle 5xx status codes, we wouldn't add an exception filter \ do exception handling by default (too opinionated, breaks existing logging and exception handling etc). I'm not sure if it would be of much use in this configuration.

[PureKrome]

@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.

vs

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

[pranavkm]

@glennc thoughts on this?

[PureKrome]

/me tries poorly to jedi-mind trick Glenn...