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

[Aswanth V C]

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.

[Natalia Bidart]

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.

[Jacob Walls]

I saw this and wanted to double-check if we need a release note.

If I understand correctly, requests without an Accept header still get the HTML response as before, and requests with an Accept header preferring only application/json still get the plain text response as before, so the behavior change only affects clients that requested text/plain with a higher priority than text/html. Given that, I don't think we need a release note.