[Django] #24619: Technical error responses (404 and 500) should return responses dependent on Accept header
Django
on Accept header
-------------------------------+--------------------
Reporter: marcinn | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Other) | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
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 builtin technical output renderes.
Optionally content-type negotiation functionality can be built as a
standalone helper for common use.
--------
Extracted from #24610
--
Ticket URL: <https://code.djangoproject.com/ticket/24619>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
on Accept header
Reporter: marcinn | Owner: nobody
Type: New feature | Status: new
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
* type: Uncategorized => New feature
* stage: Unreviewed => Accepted
Old description:
> 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 builtin technical output renderes.
>
> Optionally content-type negotiation functionality can be built as a
> standalone helper for common use.
>
> --------
>
> Extracted from #24610
New description:
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
--
--
Ticket URL: <https://code.djangoproject.com/ticket/24619#comment:1>
Django
on Accept header
Reporter: marcinn | Owner: adminq80
Type: New feature | Status: assigned
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by adminq80):
* status: new => assigned
* owner: nobody => adminq80
--
Ticket URL: <https://code.djangoproject.com/ticket/24619#comment:2>
Django
on Accept header
Reporter: Marcin Nowak | Owner: nobody
Type: New feature | Status: new
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
The current patch for ticket #30997 is doing that, returning HTML only
when the request accepts `text/html`.
--
Ticket URL: <https://code.djangoproject.com/ticket/24619#comment:2>
Django
on Accept header
Reporter: Marcin Nowak | Owner: nobody
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
My previous comment was valid for 500 responses only. For 404, we'll need
more work.
--
Ticket URL: <https://code.djangoproject.com/ticket/24619#comment:3>
Django
on Accept header
Reporter: Marcin Nowak | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* component: Core (Other) => Error reporting
--
Ticket URL: <https://code.djangoproject.com/ticket/24619#comment:4>
Django
on Accept header
Reporter: Marcin Nowak | Owner: nobody
Component: Error reporting | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => duplicate
Comment:
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 this change.
--
Ticket URL: <https://code.djangoproject.com/ticket/24619#comment:5>