HTTP 500 Internal Server Error means that the server encountered an unexpected condition and could not fulfill the request. In an ASP.NET Minimal API, exception handling can return a standard RFC 7807 ProblemDetails response instead of exposing an unhandled failure. section 6.2.4
A basic production configuration follows this flow:
- Route exceptions through /error with app.UseExceptionHandler("/error"). section 6.2.4
- Map /error to Results.Problem(), producing an RFC 7807-compatible JSON body with status 500. section 6.2.4
- Customize the endpoint with HttpContext and IExceptionHandlerPathFeature to read the exception, add its message, and attach a trace identifier. section 6.2.4
A useful 500 response
A failed request can return status 500 with a title, an RFC reference, a human-readable detail such as "test", and a traceId for correlating the failure. Keep the response informative enough for diagnosis while using the exception middleware for logging or notifications. section 6.2.4
app.MapGet("/error",
[EnableCors("AnyOrigin")]
[ResponseCache(NoStore = true)] (HttpContext context) => #1
{
var exceptionHandler =
context.Features.Get<IExceptionHandlerPathFeature>(); #2
// TODO: logging, sending notifications, and more #3
var details = new ProblemDetails();
details.Detail = exceptionHandler?.Error.Message; #4
details.Extensions["traceId"] =
System.Diagnostics.Activity.Current?.Id
?? context.TraceIdentifier;
details.Type =
"https://tools.ietf.org/html/rfc7231#section-6.6.1";
details.Status = StatusCodes.Status500InternalServerError;
return Results.Problem(details);
});
The customized /error handler retrieves the exception, sets ProblemDetails fields, adds a traceId, and returns the 500 response. section 6.2.4
Exception type can determine a more specific result: NotImplementedException maps to 501, TimeoutException maps to 504, and other exception types remain 500. Test these behaviors with dedicated /error/test/501 and /error/test/504 endpoints. section 6.3.5
