Replace is_ajax with accepts

[OutOfFocus4]

django.http.request.HttpRequest.is_ajax is deprecated. The documentation for version 3 indicated that instead of calling is_ajax, the code should check if the text/html MIME type is acceptable based on the request's Accept header.

[tim-schilling]

Django 2.2 is in LTS for a few more years. Can you write in a compatibility check for 2.2 to fix the tests?

[matthiask]

Maybe the JS code should explicitly set an Accept: application/json header to discern between AJAX and other requests.

I know that the docs suggest replacing request.is_ajax() with not request.accepts("text/html"), however I'm not sure it's the best way to do it. After all, until recently we also did fetch HTML, too.

I'd like a more explicit solution for this, not just in django-debug-toolbar but also in my own projects.

[OutOfFocus4]

I can check if the request has an accepts method and fall back to is_ajax if it doesn't, like this:

accepts = getattr(request, "accepts", None)
if accepts is None:
    is_ajax = request.is_ajax()
else:
    is_ajax = not accepts("text/html")

Another option is to add a custom header to all fetch calls, such as X-Toolbar-AJAX: 1.
That can be checked easily in all supporter versions of Django:

is_ajax = request.headers.get("X-Toolbar-AJAX") == "1"

[tim-schilling]

Maybe the JS code should explicitly set an Accept: application/json header to discern between AJAX and other requests.

I understand this to mean we should have the toolbar's JS manipulate the header on AJAX requests for the developer's application. I don't think that's what we want.

This part of the code isn't related to the history panel's internal API requests. It's checking for AJAX or JSON requests that we should capture the toolbar's measurements for so the history panel can show them.

[OutOfFocus4]

Checking for JSON requests is easy, but an AJAX request is just a normal HTTP request; there is no built-in way to determine if a request is AJAX or not.

The code currently checks for a jQuery-specific header to determine if a request is an AJAX request or not. As more developers move from jQuery to fetch, that check will become less useful.

In my view (which could be totally wrong), the best way forward is to introduce a new custom header that developers can choose to add to their AJAX requests if those requests return anything other than JSON. If all of the developer’s AJAX APIs respond with JSON, they won’t have to change anything, since JSON is already properly handled, but if the response is HTML or XML, adding the header indicates that the request was made via AJAX.

[tim-schilling]

I'm not sure we need this check. If someone has an app that runs some business logic before returning a file, we should be trying to help them debug that process. We shouldn't exclude that use case based on the response type. Granted, moving in this direction means we have to verify the existing panels don't break on non html/json responses.

[OutOfFocus4]

I'm going to close this PR and open a new issue to discuss the best path forward.