Currently, error pages are delivered using the normal TopicController. This works fine, and especially if the application only wants to capture unhandled exceptions (via UseExceptionHandler()), or handle all status codes the same (via e.g. UseStatusCodePages()).
Different Error Messages
If different messages are needed for different status codes, however, this introduces additional work by requiring that a custom route be setup to capture the status code (via the {0} placeholder), a custom controller be setup to access the status code (via either HttpContext.Response.StatusCode or the IStatusCodeReExecuteFeature dependency), or using the legacy <httpErrors /> in the web.config. This would be needed, for example, if a different error page were required for 404 Not Found, 401 Not Authorized, and 500 Internal Server Errors.
Controller
As this is a fairly common scenario, it would be useful to (re)introduce an ErrorController that handles the status code, and automatically routes to a page with the corresponding status code, if available, and otherwise returns a basic Content() block. As a nice to have, this could also support falling back to general categories—e.g., if a 403 status is thrown, but a corresponding 403 page doesn't exist, then fallback to a 400 page, assuming it exists.
Note: OnTopic 3.x previously had a ErrorController, which was deprecated as part of OnTopic 5.x. This didn't include any intelligence for routing status code to the appropriate page, however, and was simply present for handle /Error/ routes. This was, rightfully, replaced with TopicController in OnTopic 5.x.
Configuration
To enable this, a new extension method would need be introduced off of IApplicationBuilder, such as UseTopicErrors(), which might optionally accept a unique path in order to customize the location of the error topics. This would largely act as a wrapper on top of UseExceptionHandler() and UseStatusCodePages(). It may also be useful to add a MapErrorRoute()—though, that can likely just be handled by MapControllers(), too.
Content Types
Optionally, this could use a new ContentType, such as ErrorConfiguration. This would require additional upfront setup, but would allow more configuration of how error pages are handled. For example, it might allow the fallback to be toggled, or to bypass the friendly error pages for static file types. It could also define an ErrorMessage nested topic which defines an error-specific data model (e.g., StatusCode, ErrorMessage, UseFriendlyPage, &c.).
Currently, error pages are delivered using the normal
TopicController. This works fine, and especially if the application only wants to capture unhandled exceptions (viaUseExceptionHandler()), or handle all status codes the same (via e.g.UseStatusCodePages()).Different Error Messages
If different messages are needed for different status codes, however, this introduces additional work by requiring that a custom route be setup to capture the status code (via the
{0}placeholder), a custom controller be setup to access the status code (via eitherHttpContext.Response.StatusCodeor theIStatusCodeReExecuteFeaturedependency), or using the legacy<httpErrors />in theweb.config. This would be needed, for example, if a different error page were required for 404 Not Found, 401 Not Authorized, and 500 Internal Server Errors.Controller
As this is a fairly common scenario, it would be useful to (re)introduce an
ErrorControllerthat handles the status code, and automatically routes to a page with the corresponding status code, if available, and otherwise returns a basicContent()block. As a nice to have, this could also support falling back to general categories—e.g., if a 403 status is thrown, but a corresponding 403 page doesn't exist, then fallback to a 400 page, assuming it exists.Configuration
To enable this, a new extension method would need be introduced off of
IApplicationBuilder, such asUseTopicErrors(), which might optionally accept a unique path in order to customize the location of the error topics. This would largely act as a wrapper on top ofUseExceptionHandler()andUseStatusCodePages(). It may also be useful to add aMapErrorRoute()—though, that can likely just be handled byMapControllers(), too.Content Types
Optionally, this could use a new
ContentType, such asErrorConfiguration. This would require additional upfront setup, but would allow more configuration of how error pages are handled. For example, it might allow the fallback to be toggled, or to bypass the friendly error pages for static file types. It could also define anErrorMessagenested topic which defines an error-specific data model (e.g.,StatusCode,ErrorMessage,UseFriendlyPage, &c.).