An API application should respect a request's content-type header in production when an error occurs

[StefanDorresteijn]

Description

When buffalo is running as an API-only app in production and an error occurs, the application should respect the request's content type, the way it does in development.

A frontend application requesting JSON content is always expecting to get JSON, even if the content only contains error information.

Steps to Reproduce the Problem

Please describe in painful detail what you did (so others can play along with you) to get to this point. This includes things like the exact command(s) you used, or the curl command you used, that sort of thing.

1. Create an "API-only" application
2. Set GO_ENV to production
3. Make any request you know will produce an error, using application/json or any other non-html content-type header
4. Let your eyes rest on an HTML page, instead of showing you information about the error
5. Cry

Expected Behavior

One would expect the backend to always respect the request's content-type, and show useful error data when possible.

Actual Behavior

The response is HTML.

Fix

https://github.com/gobuffalo/buffalo/blob/master/errors.go#L168 should be removed so the content-type parsing and usage can be respected.

Additionally, errors should be cleaned to remove trace and other sensitive information.

[StefanDorresteijn]

I'm sure there's a cleaner way to do this, but I've made a merge request for my solution.

master...StefanDorresteijn:feature/improved-error-reporting-in-production

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue was closed because it has been stalled for 5 days with no activity.