Opened 57 minutes ago
Closed 23 minutes ago
#37207 closed New feature (wontfix)
Add a backend setting to enforce HTML response for technical 500 errors
| Reported by: | Aswanth V C | Owned by: | |
|---|---|---|---|
| Component: | Error reporting | Version: | 6.0 |
| Severity: | Normal | Keywords: | |
| Cc: | Aswanth V C | Triage Stage: | Unreviewed |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Following the improvements to content type negotiation for the 500 error response in Ticket #36456 (django.views.debug.technical_500_response), the error response is now being converted to plain text in certain scenarios based on the request's preferred type.
This behavior change makes debugging more difficult for existing systems that rely on receiving an HTML response by default (for example, utilizing the HTML response within Chrome DevTools' Inspect tab).
Updating the requested content type across various existing frontend applications is time-consuming and risks breaking existing logic, especially where frontend conditions directly depend on the request's content type.
To resolve this and support existing workflows, we should provide a backend setting that allows developers to explicitly prefer or enforce an HTML response for technical 500 errors, bypassing the strict content-type negotiation when needed.
Hello Aswanth V C, thanks for the ticket.
The behavior introduced in #36456 is intentional:
technical_500_responsenow respects theAcceptheader sent by the client. If your frontend sends requests withouttext/htmlinAccept, that is a client-side problem, not a server-side configuration problem. A Django setting does nothing for the actual negotiation contract and just punches a hole in behavior that was deliberately designed and released. It is also not scoped toDEBUGmode, which means it could accidentally affect production if someone leaves it set.For cases where you need unconditional HTML output,
technical_500_responseis a public API you can override in your project with a few lines. That is the right scope for this kind of customization.More broadly, Django is actively avoiding adding new top-level settings unless truly necessary, and when it does add configuration, the direction is toward grouped dict-based settings (like
DATABASES,STORAGES,CACHES). A one-off boolean to override content negotiation does not meet that bar.I'll close accordingly as
wontfix.