Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server Error - Respect the Accept header in responses #3246

Open
nils-van-zuijlen opened this issue Jul 17, 2024 · 1 comment
Open

Server Error - Respect the Accept header in responses #3246

nils-van-zuijlen opened this issue Jul 17, 2024 · 1 comment

Comments

@nils-van-zuijlen
Copy link

When a timeout occurs, gunicorn kill the worker (good) and answers the client (good) with a fixed error page in HTML, regardless of the Accept header sent by the client (bad).

I would like that this header would be taken into account when returning the error page, so that a client can expect the response to be in his wanted type.

For example, when a client requests XML, he gets XML, when he requests HTML, he gets HTML, and when he requests JSON, he gets JSON.

Related to #2281

@pajod
Copy link
Contributor

pajod commented Jul 17, 2024

  1. What is your use case?
  2. What solution are you thinking of that would meaningfully improve on what one can already do with configuration in a proxy (such as Nginx) sitting in front of gunicorn, or in the application itself?
  3. Do you have examples of other applications being more accommodating to client preferences even after encountering unexpected errors?
  4. Can you point to relevant specification sections (rfc9110, rfc9112, pep3333) that restrict or mandate the specifics of the behaviour?

There appear to be three distinct yet related cases, only two of which Gunicorn has full control of:

  • Non-fatal exception during processing before headers are sent: util.write_error() generates text/html payload
  • Exception on loading app with debugging helpers (e.g. --reload): util.make_fail_app() generates text/plain payload
  • Fatal exception, failure loading app without debugging helpers, exception after headers: possibly 502 from a frontend proxy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants