Opened 9 years ago

Closed 4 years ago

Last modified 4 years ago

#24619 closed New feature (duplicate)

Technical error responses (404 and 500) should return responses dependent on Accept header

Reported by: Marcin Nowak Owned by: nobody
Component: Error reporting Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Tim Graham)

Technical error responses are used in DEBUG mode only and they aren't customizable.
In most cases they are resulting HTML output, but plain text only for AJAX-like requests (based on request.is_ajax() return value).

As a developer who is creating views/services non HTML-related (JSON, XML, etc as a response) I have huge problems with reading output from technical responses when error occurs. I'm getting in my console or shell HTML mixed with Javascript and CSS, which is hard to read. Text output from technical responses is hard-readable too, but better than HTML.

Technical responses should use some sort of output renderers registry based on Accept header. They should implement or use content type negotiation strategy and match against available renderers. Current HTML and text output can be mapped for text/html and text/plain types respectively. Also as a developer I need to extend registry of supported content types for my specific needs. For example - I need error 500 technical response returned as application/json content-type. Django can provide some built-in technical output renderers.

Optionally content-type negotiation functionality can be built as a standalone helper for common use.


Extracted from #24610

Change History (5)

comment:1 by Tim Graham, 9 years ago

Description: modified (diff)
Triage Stage: UnreviewedAccepted
Type: UncategorizedNew feature

comment:2 by Claude Paroz, 4 years ago

The current patch for ticket #30997 is doing that, returning HTML only when the request accepts text/html.

comment:3 by Claude Paroz, 4 years ago

My previous comment was valid for 500 responses only. For 404, we'll need more work.

comment:4 by Carlton Gibson, 4 years ago

Component: Core (Other)Error reporting

comment:5 by Carlton Gibson, 4 years ago

Resolution: duplicate
Status: newclosed

As Claude says, better content negotiation is a work in progress.

I think the vast majority of this ticket covers 500 responses. #30752 (Django 3.1) allows providing a custom ExceptionReporter sublcass. That will be the place to add the logic needed to return the desired response format.

Doing similar for 404s would require a rewrite of the handler to use a reporter class, similar to the 500 case. I don't think that's in scope for this issue. If there's a genuine demand for that, happy to see it suggested in a separate ticket. But... given the age of this one, I suspect most (all?) users are using DRF for this kind of case these days, and that there is, in fact, no demand for that change.

Last edited 4 years ago by Carlton Gibson (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top