#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.

Change History (1)

comment:1 by Natalia Bidart, 23 minutes ago

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top