[Django] #37207: Add a backend setting to enforce HTML response for technical 500 errors

[Django]

#37207: Add a backend setting to enforce HTML response for technical 500 errors
-----------------------------+-------------------------------------------
Reporter: Aswanth V C | Type: New feature
Status: new | Component: Error reporting
Version: 6.0 | Severity: Normal
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+-------------------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/37207>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#37207: Add a backend setting to enforce HTML response for technical 500 errors

---------------------------------+--------------------------------------
Reporter: Aswanth V C | Owner: (none)
Type: New feature | Status: closed

Component: Error reporting | Version: 6.0

Severity: Normal | Resolution: wontfix

Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

---------------------------------+--------------------------------------
Changes (by Natalia Bidart):

* resolution: => wontfix
* status: new => closed

Comment:

Hello Aswanth V C, thanks for the ticket.

The behavior introduced in #36456 is intentional: `technical_500_response`
now respects the `Accept` header sent by the client. If your frontend
sends requests without `text/html` in `Accept`, 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 to `DEBUG` mode, which means it could accidentally affect
production if someone leaves it set.

For cases where you need unconditional HTML output,
`technical_500_response` is 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`.
--
Ticket URL: <https://code.djangoproject.com/ticket/37207#comment:1>