“In my opinion there are not many good reasons to have to change behaviour if a request is made via XHR. I think the most common usage is to have a single view that returns a JSON response or a HTML response depending on if XHR is used (https://github.com/search?l=Python&q=request.is_ajax&type=Code), which isn’t great and isn’t reliable.”
I do this. What would the best way to handle this? Perhaps the proper practice should be documented when it is deprecated? From: django-developers@googlegroups.com [mailto:django-developers@googlegroups.com] On Behalf Of Tom Forbes Sent: Saturday, November 16, 2019 10:16 AM To: django-developers@googlegroups.com Subject: Re: Deprecate HttpRequest.is_ajax I would agree. Flask has done the same: DeprecationWarning: Request.is_xhr is deprecated. Given that the X-Requested-With header is not a part of any spec, it is not reliable In my opinion there are not many good reasons to have to change behaviour if a request is made via XHR. I think the most common usage is to have a single view that returns a JSON response or a HTML response depending on if XHR is used (https://github.com/search?l=Python&q=request.is_ajax&type=Code), which isn’t great and isn’t reliable. On 16 Nov 2019, at 16:08, Adam Johnson <m...@adamj.eu<mailto:m...@adamj.eu>> wrote: Django's HttpRequest.is_ajax method determines whether the request was made with the JS API XMLHttpRequest https://docs.djangoproject.com/en/2.2/ref/request-response/#django.http.HttpRequest.is_ajax . It does so by checking the X-Requested-With header. The new way of making "AJAX" requests from the browser is the JavaScript fetch() API : https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API . I think the is_ajax() documentation is at least a little misleading in pretending XMLHttpRequest is the only JS API. There also aren't any special headers set by fetch() so it's not possible to detect its requests. I propose deprecating is_ajax() with no replacement. Thoughts? -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com<mailto:django-developers+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAMyDDM0i-p0ZxBj-fSheGs-2pMXH7K7Oka%3DCjy1YXx-emBu3mw%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com<mailto:django-developers+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es<https://groups.google.com/d/msgid/django-developers/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/cb12b0005c5e4191be3a97d0d2c44cc5%40iss2.ISS.LOCAL.