[Django] #22621: Return JSON response in default error handlers for ajax requests
Django
-----------------------------+--------------------
Reporter: Elvard | Owner: nobody
Type: New feature | Status: new
Component: Core (URLs) | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------
Default error handlers in `django.views.defaults` always return
`text/html` content type with HTML response.
It would be useful to check if:
- `request.is_ajax()`
- client accepts `application/json` content type
and then return JSON response.
--
Ticket URL: <https://code.djangoproject.com/ticket/22621>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Elvard | Owner: nobody
Type: New feature | Status: new
Component: Core (URLs) | Version: master
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 timo):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
The main issue I see is that I'm not sure there's a standard format for
returning JSON errors. I found [https://pypi.python.org/pypi/django-
jsonview/0.3.0 django-jsonview] which returns
{{{
json.dumps({
'error': STATUS_CODE,
'message': str(exception),
})
}}}
which seems reasonable. I'm not convinced this functionality needs to live
in Django since it's easy to redefine the error handlers based on your
needs, but I'll leave it open for a second opinion.
--
Ticket URL: <https://code.djangoproject.com/ticket/22621#comment:1>
Django
Reporter: Elvard | Owner: nobody
Type: New feature | Status: closed
Component: Core (URLs) | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by erikr):
* status: new => closed
* resolution: => wontfix
Comment:
We might be talking about the two different mutually exclusive 500 views
in Django. As Tim's example includes the exception, that sounds like a
debug view. The standard Django debug mode 500 page lives in
`django.views.debug.technical_500_response`. There appears to be no method
to customise that. Separate from that is the view Elvard mentioned, in
`django.views.defaults`. That is
[[https://docs.djangoproject.com/en/dev/topics/http/views/#http-internal-
server-error-view|trivial to customize]].
Although this change sounds logical at first, I'm not seeing how it is
helpful to return more data in the JSON in either scenario. What would you
do with these values? When is it not enough to just look at the 500
response code? Also remember that Tim's example would not be acceptable in
non-debug mode (as default built-in Django view), because we don't want to
provide details on the exception in the output.
So, adding this to the code is simple, but I do not understand what
problem you are trying to solve. Until that is clarified, I'm closing as
wontfix.
--
Ticket URL: <https://code.djangoproject.com/ticket/22621#comment:2>
Django
Reporter: Tomáš Ehrlich | Owner: nobody
Type: New feature | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Alan Justino da Silva):
Replying to [comment:2 Sasha Romijn]:
> We might be talking about the two different mutually exclusive 500 views
in Django. As Tim's example includes the exception, that sounds like a
debug view.
Please correct me, but doing `str()` over an Exception returns only the
error name/details, not the full traceback. That is what I would expect as
a 500 on JSON, exactly the same as a 500 on HTML.
> What would you do with these values? When is it not enough to just look
at the 500 response code?
I expect JSON client callers to be able to parse the answers in JSON when
providing `Accept: application/json`, even if the call errors out.
> Also remember that Tim's example would not be acceptable in non-debug
mode (as default built-in Django view), because we don't want to provide
details on the exception in the output.
That is fair. What about providing only the same of HTML "Server Error
(500)" but in a JSON wrap instead of a HTML wrap?
> So, adding this to the code is simple, but I do not understand what
problem you are trying to solve. Until that is clarified, I'm closing as
wontfix.
The problem is about a client asking for `Accept: application/json` not
expecting to handle anything but JSON, and the 500 response being HTML
even for a request with `Accept: application/json`.
That said, would you reconsider the `wontfix` solution?
--
Ticket URL: <https://code.djangoproject.com/ticket/22621#comment:3>
Django
Reporter: Tomáš Ehrlich | Owner: nobody
Type: New feature | Status: closed
Component: Core (URLs) | Version: dev
Severity: Normal | Resolution: wontfix
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Alan Justino da Silva):
* cc: Alan Justino da Silva (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/22621#comment:4>