Provide option to disable ajax text/plain response in technical_500_response

[thenewguy]

Line in question: ​https://github.com/django/django/blob/master/django/views/debug.py#L89

Ticket #10841 from a long time ago made a change to return text/plain responses unconditionally when the request was made via ajax. It would be handy if this special casing of ajax requests could be disabled with a setting or something.

I just spent the last 45 minutes tracking down why the debug error pages were not rendering with styles on a new project I was basing on an older one that did not exhibit the issue.

Turns out I hit this before and the approach I came up with in the past was to monkey patch the handler and forcefully set ajax to false. Otherwise it seems like there is a lot of code to copy and also warnings in the source about writing error handlers. So I'd rather not, but I need to display the error messages during development...

Below is a sample of the monkey patch. It would probably be better to move the condition outside of the function and disable it when not in DEBUG mode. I am going to do that now I guess, but I figure it was worthwhile to raise the issue.

from django.conf import settings
from django.core.handlers.base import BaseHandler

handle_uncaught_exception = BaseHandler.handle_uncaught_exception

def _handle_uncaught_exception_monkey_patch(self, request, resolver, exc_info):
    if settings.DEBUG:
        request.is_ajax = lambda: False
    
    return handle_uncaught_exception(self, request, resolver, exc_info)

BaseHandler.handle_uncaught_exception = _handle_uncaught_exception_monkey_patch

[Tim Graham]

I guess you use something like Chrome inspector which renders HTML just fine? It would be a nice feature, but I doubt adding a setting will be a popular solution.

There was ​an idea to replace settings.DEFAULT_EXCEPTION_REPORTER_FILTER with a DEFAULT_EXCEPTION_REPORTER setting:

Introduce DEFAULT_EXCEPTION_REPORTER settings to allow custom ExceptionReporter class. To avoid new setting, it can actually replace original DEFAULT_EXCEPTION_REPORTER_FILTER setting either by merging ExceptionReporterFilter class into ExceptionReporter or defining filter as a class attribute of the ExceptionReporter. I don't quite see a need to have the implementation split into two classes in this case. Developers could further profit from this change by getting control over the context and templates of the error reports.

Implementing that would likely make allow customizing this behavior easy.

[Carlton Gibson]

#30752 (Django 3.1) allows providing a custom ExceptionReporter sublcass. (Exactly via the DEFAULT_EXCEPTION_REPORTER setting Tim discusses above.) That will be the place to add the logic you need. (Make get_traceback_text() a proxy to get_traceback_html() being the first thing that comes to mind.)