Return JSON response in default error handlers for ajax requests

[Tomáš Ehrlich]

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.

[Tim Graham]

The main issue I see is that I'm not sure there's a standard format for returning JSON errors. I found ​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.

[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. 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 ​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.

[Alan Justino da Silva]

Replying to 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?