Re: Deprecate HttpRequest.is_ajax

[Jure Erznožnik]

>> "I want A, B, C or D - I can give you B or D - Then D - OK"

Yes, this. As long as I have the chance to determine B & D BEFORE the 
content negotiation is complete. As opposed to having them fixed in code 
by e.g. specifying to_json & to_html methods.


LP,
Jure

On 22/11/2019 02:04, Matemática A3K wrote:

"I want A, B, C or D - I can give you B or D - Then D - OK"


--
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/5ed3ebaf-9f89-8570-f6a6-9f4453d27751%40gmail.com.

Re: Deprecate HttpRequest.is_ajax

[Matemática A3K]

On Thu, Nov 21, 2019 at 3:03 AM Jure Erznožnik 
wrote:

> If possible, could the logic determining "the best match for your options"
> be overridable?
>
Actually it is quite straightforward, the client set in the header of its
request all the media types it wants ("accepts as a response") with a
preference parameter, i.e. "Accepts:JSON;q=0.9,XML;q=1,*/*;q=0.8" for
wanting XML, if not JSON, if not anything else (the client's demand
preferences).

You previously decide which one you support on your view, i.e. this view
will deliver its content in HTML and JSON - it doesn't matter which one,
that's what is available as a delivery (your offering).

Then you have to match which one of your offerings will better satisfy the
client demand expressed by its preferences. What's best for you is already
set when you express your preferences for the request in the header, the
problem is that you may not have what is best for the client - but you may
have something that satisfies it better than others: you don't have XML but
you have JSON which it preffers to the rest.

It is the best match in that sense: given the client request preferences,
respond with the more "satisfying" offering available.

This is done (mostly) to avoid a request, instead of doing a request for
the available formats and do another with the choosen one, you request with
the ones that makes you happy and then let the server find the best way to
serve you, and for the spec writers resembles a negotiation ("I want A, B,
C or D - I can give you B or D - Then D - OK").

If you filter the client's demand with your offering (you intersect them),
i.e. "Accepts:JSON;q=0.9,XML;q=1,*/*;q=0.8" \Int "JSON, HTML" ->
"Accepts:JSON;q=0.9,HTML;q=0.8", and then you order them, the one that you
should serve would be always the first one, because if there is a tie, it
is the same for the client - the client chose that the server choose
between them (though you can specify a default media serving ordering that
will handle also no preferences).

That's why "Just parsing them it and make them available in the request -
filtered by the supported ones - as an ordered list
("accepted_media_types") and the preferred one ("preferred_media_type")
seems sufficient to me."

With that API, you could implement easily content negotiation, both in
functional views and CBVs. In CBVs, you can go further and use
metaprograming techniques (like the ones used for "get_FOO_display()") to
make the methods available "on the fly": "to_LABEL" and have the dispatcher
choose the method according to "preferred_media_type"  - although making
that explicit by the user may not be bad at all.

Note that this is mostly needed in REST APIs, where an endpoint is exposed
to several clients which may have different requirements - i.e. a table in
CSV, XML, etc. But for many Django applications this would be between
browsers and the server, and between HTML and JSON if AJAX.

As converting to JSON it may seems straightforward, it may not - that's why
DRF exists and addresses this problem in an excellent way (IMO :), so the
user in "plain" Django will have to deal with serialization (
https://docs.djangoproject.com/en/2.2/topics/serialization/) and not much
besides defaulting to DjangoJsonEncoder for the context in CVB and for
functional views (like https://github.com/jsocol/django-jsonview) can be
done - at least that comes to my mind - for giving convenience :)

That way standard implementation would cater for 80/20 and everyone would
> still have an option to customise further.
>
> LP,
> Jure
> On 21/11/2019 02:22, Matemática A3K wrote:
>
>
>
> On Wed, Nov 20, 2019 at 11:52 PM James Bennett 
> wrote:
>
>> On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney 
>> wrote:
>>
>>>
>>> Yeah, I expected DRF had this "solved" already. From my own
>>> experimentation, mapping `cgi.parse_header` over the the "Accept" header
>>> value, split by comma, gets a usable result; then sort that list by 'q'
>>> (defaulting to 1.0) and you have your priority.
>>>
>>
>> Both the original and forks seem to've been abandoned now, but the
>> mimeparse library encapsulated this into a nice little function that took
>> an Accept header, and a list of content-types you could support in the
>> response, and told you which one was the best match. The code's still out
>> there and under a permissive license if somebody wants to pick it up again.
>>
>
> I think now that providing alternatives is the way to go :)
>
> When 'is_ajax' is used for content negotiation, then proper content
> negotiation via the Accept headers should be done.
>
> When 'is_ajax' is used for different content delivery (like routing), then
> make the convention explicit or refactoring should be done.
>
> In the case of content negotiation -
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation -
> this is only about media types (Accept-Language is already parsed in i18n).
>
> Just parsing them it and make them available in the request - filtered by

Re: Deprecate HttpRequest.is_ajax

[Jure Erznožnik]

If possible, could the logic determining "the best match for your 
options" be overridable?


That way standard implementation would cater for 80/20 and everyone 
would still have an option to customise further.


LP,
Jure

On 21/11/2019 02:22, Matemática A3K wrote:



On Wed, Nov 20, 2019 at 11:52 PM James Bennett > wrote:


On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney
mailto:cur...@tinbrain.net>> wrote:


Yeah, I expected DRF had this "solved" already. From my own
experimentation, mapping `cgi.parse_header` over the the
"Accept" header value, split by comma, gets a usable result;
then sort that list by 'q' (defaulting to 1.0) and you have
your priority.


Both the original and forks seem to've been abandoned now, but the
mimeparse library encapsulated this into a nice little function
that took an Accept header, and a list of content-types you could
support in the response, and told you which one was the best
match. The code's still out there and under a permissive license
if somebody wants to pick it up again.


I think now that providing alternatives is the way to go :)

When 'is_ajax' is used for content negotiation, then proper content 
negotiation via the Accept headers should be done.


When 'is_ajax' is used for different content delivery (like routing), 
then make the convention explicit or refactoring should be done.

|
|
|In the case of content negotiation - 
https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation 
- this is only about media types (Accept-Language is already parsed in 
i18n).|

|
|
|Just parsing them it and make them available in the request - 
filtered by the supported ones - as an ordered list 
("accepted_media_types") and the preferred one 
("preferred_media_type") seems sufficient to me.|

|
|
|For functional views, it would be up to you to decide which one you 
support and how it is delivered with something like "if 'json' in 
request.preferred_media_type:".  We can add decorators for setting the 
response type for a specific media type and optionally returning a 406.

|
|
|
|For CBVs, a mixin should be done - something like 
ContentNegotiationMixin - where you define the the types you want to 
support in it (or otherwise use the settings) and you should define or 
override methods like "to_JSON", "to_XML", "to_LABEL" that will 
serialize your context into the media type that is the best match for 
your options.

|
|
|
||
|As more than one media type may correspond to one format, if a dict 
that labels the supported types is defined, something like:|

|
|
|SUPPORTED_MEDIA_TYPES_LABELS = {|
|  "application/json": "JSON",|
|  "text/json": "JSON",|
|  "application/pdf": "PDF",|
|  "text/html": "HTML",|
|}
|
||
||
|
|
|All the filtering can be easily done.
|
|
|
||
||
||
If so, the deprecation warning should be something like:
|DeprecationWarning: Request.is_ajax is deprecated. Given that the 
X-Requested-With header is not a part of any spec, it is not reliable. 
If you are doing content negotiation, see 
..docs/media_type_negotiation. If you are serving different content if 
the requests are made via AJAX, choose a convention for *your* project 
to discern them or consider refactoring your code (making your views 
specific to one intent for each verb).|

||
|
|
|If you agree - in general - with this direction, I can find time to 
implement it.

|

-- 
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/CAL13Cg9x9ZWM0LTLoMMF%3DxgMydqrOKhEnhsRn-miFkVk5Rx6tg%40mail.gmail.com

.

--
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/CA%2BFDnhKbzzst8PxCr8q26UfYzLAZKi6fqQV9nUjpotkFb%2Byo1w%40mail.gmail.com 
.


--
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 

Re: Deprecate HttpRequest.is_ajax

[Matemática A3K]

On Wed, Nov 20, 2019 at 11:52 PM James Bennett 
wrote:

> On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney 
> wrote:
>
>>
>> Yeah, I expected DRF had this "solved" already. From my own
>> experimentation, mapping `cgi.parse_header` over the the "Accept" header
>> value, split by comma, gets a usable result; then sort that list by 'q'
>> (defaulting to 1.0) and you have your priority.
>>
>
> Both the original and forks seem to've been abandoned now, but the
> mimeparse library encapsulated this into a nice little function that took
> an Accept header, and a list of content-types you could support in the
> response, and told you which one was the best match. The code's still out
> there and under a permissive license if somebody wants to pick it up again.
>

I think now that providing alternatives is the way to go :)

When 'is_ajax' is used for content negotiation, then proper content
negotiation via the Accept headers should be done.

When 'is_ajax' is used for different content delivery (like routing), then
make the convention explicit or refactoring should be done.

In the case of content negotiation -
https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation -
this is only about media types (Accept-Language is already parsed in i18n).

Just parsing them it and make them available in the request - filtered by
the supported ones - as an ordered list ("accepted_media_types") and the
preferred one ("preferred_media_type") seems sufficient to me.

For functional views, it would be up to you to decide which one you support
and how it is delivered with something like "if 'json' in
request.preferred_media_type:".  We can add decorators for setting the
response type for a specific media type and optionally returning a 406.

For CBVs, a mixin should be done - something like ContentNegotiationMixin -
where you define the the types you want to support in it (or otherwise use
the settings) and you should define or override methods like "to_JSON",
"to_XML", "to_LABEL" that will serialize your context into the media type
that is the best match for your options.

As more than one media type may correspond to one format, if a dict that
labels the supported types is defined, something like:

SUPPORTED_MEDIA_TYPES_LABELS = {
  "application/json": "JSON",
  "text/json": "JSON",
  "application/pdf": "PDF",
  "text/html": "HTML",
}

All the filtering can be easily done.

If so, the deprecation warning should be something like:
DeprecationWarning: Request.is_ajax is deprecated. Given that the
X-Requested-With header is not a part of any spec, it is not reliable. If
you are doing content negotiation, see ..docs/media_type_negotiation. If
you are serving different content if the requests are made via AJAX, choose
a convention for *your* project to discern them or consider refactoring
your code (making your views specific to one intent for each verb).

If you agree - in general - with this direction, I can find time to
implement it.

> --
> 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/CAL13Cg9x9ZWM0LTLoMMF%3DxgMydqrOKhEnhsRn-miFkVk5Rx6tg%40mail.gmail.com
> 
> .
>

-- 
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/CA%2BFDnhKbzzst8PxCr8q26UfYzLAZKi6fqQV9nUjpotkFb%2Byo1w%40mail.gmail.com.

Re: Deprecate HttpRequest.is_ajax

[Asif Saif Uddin]

Not so sure though, but would like to know if 
https://github.com/python-hyper these libraries are of any use for django 
http?

On Thursday, November 21, 2019 at 5:52:12 AM UTC+6, James Bennett wrote:
>
> On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney  > wrote:
>
>>
>> Yeah, I expected DRF had this "solved" already. From my own 
>> experimentation, mapping `cgi.parse_header` over the the "Accept" header 
>> value, split by comma, gets a usable result; then sort that list by 'q' 
>> (defaulting to 1.0) and you have your priority.
>>
>
> Both the original and forks seem to've been abandoned now, but the 
> mimeparse library encapsulated this into a nice little function that took 
> an Accept header, and a list of content-types you could support in the 
> response, and told you which one was the best match. The code's still out 
> there and under a permissive license if somebody wants to pick it up again. 
>

-- 
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/1b5fde50-b61f-42b3-b59d-13c4fa4b5efb%40googlegroups.com.

Re: Deprecate HttpRequest.is_ajax

[James Bennett]

On Wed, Nov 20, 2019 at 3:44 PM Curtis Maloney  wrote:

>
> Yeah, I expected DRF had this "solved" already. From my own
> experimentation, mapping `cgi.parse_header` over the the "Accept" header
> value, split by comma, gets a usable result; then sort that list by 'q'
> (defaulting to 1.0) and you have your priority.
>

Both the original and forks seem to've been abandoned now, but the
mimeparse library encapsulated this into a nice little function that took
an Accept header, and a list of content-types you could support in the
response, and told you which one was the best match. The code's still out
there and under a permissive license if somebody wants to pick it up again.

-- 
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/CAL13Cg9x9ZWM0LTLoMMF%3DxgMydqrOKhEnhsRn-miFkVk5Rx6tg%40mail.gmail.com.

Re: Deprecate HttpRequest.is_ajax

[Curtis Maloney]

On Thu, 21 Nov 2019, at 09:25, Tom Forbes wrote:
> > If Django were to provide a solid API for parsing Accept headers [not as 
> > easy as it sounds] and selecting a preferred response type [based on accept 
> > preference weights] ... would that take care of the bulk of "content 
> > negotiation”?
> 
> > I could imagine a view progressing past the boiler plate [verifying the 
> > target object exists, etc], doing its "work", then checking what response 
> > form to use, and branching there.
> 
> I had a look at how DRF handles parses Accept headers, and it honestly 
> doesn’t look too tricky: 
> https://github.com/encode/django-rest-framework/blob/39876e66070c1d6f97740789d5c6f6a0a3ea06cf/rest_framework/utils/mediatypes.py#L52-L62.
>  The precedence logic is a bit complex, but all in all it’s under ~30 lines 
> of actual implementation code.

Yeah, I expected DRF had this "solved" already. From my own experimentation, 
mapping `cgi.parse_header` over the the "Accept" header value, split by comma, 
gets a usable result; then sort that list by 'q' (defaulting to 1.0) and you 
have your priority.

But knowing that's the right way to parse Accept headers, and asking for match 
or quality measures of your response options, feel like an abstraction Django 
could/should provide.

> But providing the ability to parse accept headers and branch is simple enough 
> to match a lot of the current “is_ajax” usages without too many changes. I 
> don’t see much value in trying to tackle more complex/structured content 
> negotiation handing.

This was my hope - an 80/20 solution that in no way precluded other solutions.

--
C

-- 
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/519f9b4e-ad9d-4814-ad6f-c6faff809867%40www.fastmail.com.

Re: Deprecate HttpRequest.is_ajax

[Tom Forbes]

oposed and refactors.
>>> 
>>> It seems to me that if there is no reliable way of determining it from the 
>>> back-end side, then in the end it will be a convention between the front 
>>> and the back. This could be a GET parameter, a "ClientWants: JSONOrNothing" 
>>> header, or whatever convention you like to make, but not rely on a 
>>> convention which seems to be fading out.
>>> 
>>> You can ensure the actual convention by setting the header manually (as 
>>> stated in the is_ajax doc) - as you do with the CSRF token. Another 
>>> convention could be better (i.e. "accepts json")
>>> 
>>> So far, is what the discussion went through to my understanding :)
>>> 
>>> 
>>> I'm currently handling this with custom headers and the caller (the 
>>> browser) tells the server what kind of outputs it can handle in different 
>>> types of output.
>>> 
>>> The server then performs the branching at certain code points, specifically 
>>> the ones mentioned above. DRF allows me to choose the appropriate renderer. 
>>> Though I should mention here, that the data is already serialised at that 
>>> point: sometimes this creates issues for renderers that might desire more 
>>> information to do their work. Just mentioning that render stages need to be 
>>> accounted for too. This may not be a problem for core Django as it doesn't 
>>> have stages.
>>> 
>>> Again, sorry, but still hoping this helped in some way.
>>> 
>>> 
>>> 
>>> 
>>> LP,
>>> Jure
>>> 
>>> 
>>> 
>>> On 19/11/2019 01:06, Matemática A3K wrote:
>>>> 
>>>> I agree with Adam that it should be deprecated with no replacement.
>>>> 
>>>> The content negotiation is something that should be in but not as a 
>>>> replacement of it, as a general improvement.
>>>> 
>>>> I think there shouldn't be a replacement because "is_ajax" asks whether it 
>>>> came from a ""regular"" browser instead of jQuery and with the content 
>>>> negotiation you ask if the requester accepts a type - which can also lead 
>>>> to errors because the client may also accept other types (no example 
>>>> coming to my mind), and if so, it will lead to undesired behavior.
>>>> 
>>>> The right approach would be making AJAX requests request JSON output 
>>>> explicitly, by using a dedicated endpoint or by appending something that 
>>>> manifests their intention - like in 
>>>> https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#more-than-just-html
>>>>  
>>>> <https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#more-than-just-html>
>>>>  is done with a get parameter. Not decide the response type by where it 
>>>> came from as it is unreliable as stated before, it provides convenience in 
>>>> some use cases but can lead to errors.
>>>> 
>>>> Seems better to me to refactor the view code so you can write a different 
>>>> view for Ajax requests that returns a JSON without code duplication.
>>>> 
>>>> As a shortcut, something like "For simple AJAX endpoints wrap your view 
>>>> with (something like) a "jsonview" decorator which will check the accept 
>>>> header (with something like Claude's code), return the appropriate error 
>>>> code if not, set the response type accordingly, and you should return a 
>>>> dict of strings (you have to take care of the serialization, i.e with 
>>>> https://docs.djangoproject.com/en/2.2/topics/serialization/#serialization-formats-json
>>>>  
>>>> <https://docs.djangoproject.com/en/2.2/topics/serialization/#serialization-formats-json>).
>>>> 
>>>> On Mon, Nov 18, 2019 at 3:28 PM Tom Forbes >>> <mailto:t...@tomforb.es>> wrote:
>>>> What I meant by that is it’s not an approach that scales well to lots of 
>>>> views. It might be better to have separate endpoints to return JSON (e.g 
>>>> adding a /json suffix), and in the past this has made services I’ve worked 
>>>> on a lot more maintainable and easy to understand. But it’s not as quick 
>>>> to do as `if request.is_ajax()` and requires a bit more upfront work. If 
>>>> you find you need to do this a lot then maybe something more structured 
>>>> like Django Rest Framewo

Re: Deprecate HttpRequest.is_ajax

[Claude Paroz]

Le 20.11.19 à 22:46, Curtis Maloney a écrit :
> My reading of this discussion boils down to "if we get rid of is_ajax (a
> buy-in convention nobody can rely on), how do people decide if it's an
> AJAX call or not?". To my mind, the "content negotiation" advocates have
> it right: HTTP has a mechanism for determining what response format is
> desired.

It doesn't cover all use cases. For example, I have a use case where an
AJAX call only returns a partial HTML snippet while a non-AJAX call is
returning a full HTML page (same content type in both cases)
.
But in that case, I agree with a previous poster that it's a matter of
convention between client and server. I can rather easily create my own
`is_ajax(request)` utility depending on the convention I choose.

Claude
-- 
www.2xlibre.net

-- 
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/53992754-6e8d-b138-a88b-85d4cfc68891%402xlibre.net.

Re: Deprecate HttpRequest.is_ajax

[Curtis Maloney]

gt; 

>>>> On 19/11/2019 01:06, Matemática A3K wrote:
>>>>> 
>>>>> I agree with Adam that it should be deprecated with no replacement.
>>>>> 
>>>>> The content negotiation is something that should be in but not as a 
>>>>> replacement of it, as a general improvement.
>>>>> 
>>>>> I think there shouldn't be a replacement because "is_ajax" asks whether 
>>>>> it came from a ""regular"" browser instead of jQuery and with the content 
>>>>> negotiation you ask if the requester accepts a type - which can also lead 
>>>>> to errors because the client may also accept other types (no example 
>>>>> coming to my mind), and if so, it will lead to undesired behavior.
>>>>> 
>>>>> The right approach would be making AJAX requests request JSON output 
>>>>> explicitly, by using a dedicated endpoint or by appending something that 
>>>>> manifests their intention - like in 
>>>>> https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#more-than-just-html
>>>>>  is done with a get parameter. Not decide the response type by where it 
>>>>> came from as it is unreliable as stated before, it provides convenience 
>>>>> in some use cases but can lead to errors.
>>>>> 
>>>>> Seems better to me to refactor the view code so you can write a different 
>>>>> view for Ajax requests that returns a JSON without code duplication.
>>>>> 
>>>>> As a shortcut, something like "For simple AJAX endpoints wrap your view 
>>>>> with (something like) a "jsonview" decorator which will check the accept 
>>>>> header (with something like Claude's code), return the appropriate error 
>>>>> code if not, set the response type accordingly, and you should return a 
>>>>> dict of strings (you have to take care of the serialization, i.e with 
>>>>> https://docs.djangoproject.com/en/2.2/topics/serialization/#serialization-formats-json).
>>>>> 
>>>>> On Mon, Nov 18, 2019 at 3:28 PM Tom Forbes  wrote:
>>>>>> What I meant by that is it’s not an approach that scales well to lots of 
>>>>>> views. It might be better to have separate endpoints to return JSON (e.g 
>>>>>> adding a /json suffix), and in the past this has made services I’ve 
>>>>>> worked on a lot more maintainable and easy to understand. But it’s not 
>>>>>> as quick to do as `if request.is_ajax()` and requires a bit more upfront 
>>>>>> work. If you find you need to do this a lot then maybe something more 
>>>>>> structured like Django Rest Framework will be a better choice, which 
>>>>>> also handles content negotiation really well (it can produce XML, CSV, 
>>>>>> JSON, etc etc). 
>>>>>> 
>>>>>>> On 18 Nov 2019, at 15:18, Matthew Pava  wrote:
>>>>>>> 
>>>>>>> “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=request.is_ajax=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

Re: Deprecate HttpRequest.is_ajax

[Manoj Kiraula]

I want ask a question regarding creating a string,why while creating a
string where user give the input,there are different references of that
object

On Mon, Nov 18, 2019, 8:58 PM Tom Forbes  wrote:

> What I meant by that is it’s not an approach that scales well to lots of
> views. It might be better to have separate endpoints to return JSON (e.g
> adding a /json suffix), and in the past this has made services I’ve worked
> on a lot more maintainable and easy to understand. But it’s not as quick to
> do as `if request.is_ajax()` and requires a bit more upfront work. If you
> find you need to do this a lot then maybe something more structured like
> Django Rest Framework will be a better choice, which also handles content
> negotiation really well (it can produce XML, CSV, JSON, etc etc).
>
> On 18 Nov 2019, at 15:18, Matthew Pava  wrote:
>
> “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=request.is_ajax=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=request.is_ajax=Code), which
> isn’t great and isn’t reliable.
>
>
>
> On 16 Nov 2019, at 16:08, Adam Johnson  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.
> 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_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/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_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
> <https://groups.google.com/d/msgid/django-developers/cb12b0005c5e4191be3a97d0d2c44cc5%40iss2.ISS.LOCAL?utm_medium=email_source=footer>
> 

Re: Deprecate HttpRequest.is_ajax

[Jure Erznožnik]

on.

As a shortcut, something like "For simple AJAX endpoints wrap
your view with (something like) a "jsonview" decorator which
will check the accept header (with something like Claude's
code), return the appropriate error code if not, set the
response type accordingly, and you should return a dict of
strings (you have to take care of the serialization, i.e with

https://docs.djangoproject.com/en/2.2/topics/serialization/#serialization-formats-json).


On Mon, Nov 18, 2019 at 3:28 PM Tom Forbes mailto:t...@tomforb.es>> wrote:

What I meant by that is it’s not an approach that scales
well to lots of views. It might be better to have
separate endpoints to return JSON (e.g adding a /json
suffix), and in the past this has made services I’ve
worked on a lot more maintainable and easy to understand.
But it’s not as quick to do as `if request.is_ajax()` and
requires a bit more upfront work. If you find you need to
do this a lot then maybe something more structured like
Django Rest Framework will be a better choice, which also
handles content negotiation really well (it can produce
XML, CSV, JSON, etc etc).



On 18 Nov 2019, at 15:18, Matthew Pava
mailto:matthew.p...@iss.com>> wrote:

“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=request.is_ajax=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>
[mailto:django-developers@googlegroups.com]*On Behalf
Of*Tom Forbes
*Sent:*Saturday, November 16, 2019 10:16 AM
        *To:*django-developers@googlegroups.com
<mailto: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=request.is_ajax=Code),
which isn’t great and isn’t reliable.


On 16 Nov 2019, at 16:08, Adam Johnson mailto:m...@adamj.eu>> wrote:
Django's HttpRequest.is_ajax method determines whether
the request was made with the JS API

XMLHttpRequesthttps://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
todjango-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web

visithttps://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_source=footer>.
--
You received this message because you are subscribed to
the Google Groups "Django developers (Co

Re: Deprecate HttpRequest.is_ajax

[Matemática A3K]

rn a
>> dict of strings (you have to take care of the serialization, i.e with
>> https://docs.djangoproject.com/en/2.2/topics/serialization/#serialization-formats-json).
>>
>>
>> On Mon, Nov 18, 2019 at 3:28 PM Tom Forbes  wrote:
>>
>>> What I meant by that is it’s not an approach that scales well to lots of
>>> views. It might be better to have separate endpoints to return JSON (e.g
>>> adding a /json suffix), and in the past this has made services I’ve worked
>>> on a lot more maintainable and easy to understand. But it’s not as quick to
>>> do as `if request.is_ajax()` and requires a bit more upfront work. If you
>>> find you need to do this a lot then maybe something more structured like
>>> Django Rest Framework will be a better choice, which also handles content
>>> negotiation really well (it can produce XML, CSV, JSON, etc etc).
>>>
>>
>>> On 18 Nov 2019, at 15:18, Matthew Pava  wrote:
>>>
>>> “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=request.is_ajax=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=request.is_ajax=Code), which
>>> isn’t great and isn’t reliable.
>>>
>>>
>>>
>>> On 16 Nov 2019, at 16:08, Adam Johnson  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.
>>> 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_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/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es
>>> <https://groups.google.com/d/msgid/django-de

Re: Deprecate HttpRequest.is_ajax

[Matemática A3K]

>>
>> 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=request.is_ajax=Code), which
>> isn’t great and isn’t reliable.
>>
>>
>>
>> On 16 Nov 2019, at 16:08, Adam Johnson  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.
>> 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_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/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_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
>> <https://groups.google.com/d/msgid/django-developers/cb12b0005c5e4191be3a97d0d2c44cc5%40iss2.ISS.LOCAL?utm_medium=email_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/DA72EC9C-AE24-4C04-854A-A6E19DD64132%40tomforb.es
>> <https://groups.google.com/d/msgid/django-developers/DA72EC9C-AE24-4C04-854A-A6E19DD64132%40tomforb.es?utm_medium=email_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...@goo

Re: Deprecate HttpRequest.is_ajax

[Jure Erznožnik]

Sorry for barging in like this, but this is actually a problem I have 
been dealing with quite a bit lately, so:


In my work I very often have to decide, depending on what's calling, 
what the rendered output might be. Ultimately I went with DRF and its 
content negotiation, though even that one - as implemented - sometimes 
isn't sufficient.


See, the problem sometimes isn't that you request JSON and then get 
JSON, request HTML and get HTML. You also have to cater for exceptions. 
Maybe a 4xx would return additional objects to insert into the DOM while 
a 200 would be fine with a JSON or even without data. What about 500?


I'm currently handling this with custom headers and the caller (the 
browser) tells the server what kind of outputs it can handle in 
different types of output.


The server then performs the branching at certain code points, 
specifically the ones mentioned above. DRF allows me to choose the 
appropriate renderer. Though I should mention here, that the data is 
already serialised at that point: sometimes this creates issues for 
renderers that might desire more information to do their work. Just 
mentioning that render stages need to be accounted for too. This may not 
be a problem for core Django as it doesn't have stages.


Again, sorry, but still hoping this helped in some way.

LP,
Jure


On 19/11/2019 01:06, Matemática A3K wrote:


I agree with Adam that it should be deprecated with no replacement.

The content negotiation is something that should be in but not as a 
replacement of it, as a general improvement.


I think there shouldn't be a replacement because "is_ajax" asks 
whether it came from a ""regular"" browser instead of jQuery and with 
the content negotiation you ask if the requester accepts a type - 
which can also lead to errors because the client may also accept other 
types (no example coming to my mind), and if so, it will lead to 
undesired behavior.


The right approach would be making AJAX requests request JSON output 
explicitly, by using a dedicated endpoint or by appending something 
that manifests their intention - like in 
https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#more-than-just-html 
is done with a get parameter. Not decide the response type by where it 
came from as it is unreliable as stated before, it provides 
convenience in some use cases but can lead to errors.


Seems better to me to refactor the view code so you can write a 
different view for Ajax requests that returns a JSON without code 
duplication.


As a shortcut, something like "For simple AJAX endpoints wrap your 
view with (something like) a "jsonview" decorator which will check the 
accept header (with something like Claude's code), return the 
appropriate error code if not, set the response type accordingly, and 
you should return a dict of strings (you have to take care of the 
serialization, i.e with 
https://docs.djangoproject.com/en/2.2/topics/serialization/#serialization-formats-json). 



On Mon, Nov 18, 2019 at 3:28 PM Tom Forbes <mailto:t...@tomforb.es>> wrote:


What I meant by that is it’s not an approach that scales well to
lots of views. It might be better to have separate endpoints to
return JSON (e.g adding a /json suffix), and in the past this has
made services I’ve worked on a lot more maintainable and easy to
understand. But it’s not as quick to do as `if request.is_ajax()`
and requires a bit more upfront work. If you find you need to do
this a lot then maybe something more structured like Django Rest
Framework will be a better choice, which also handles content
negotiation really well (it can produce XML, CSV, JSON, etc etc).



On 18 Nov 2019, at 15:18, Matthew Pava mailto:matthew.p...@iss.com>> wrote:

“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=request.is_ajax=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>
[mailto:django-developers@googlegroups.com]*On Behalf Of*Tom Forbes
*Sent:*Saturday, November 16, 2019 10:16 AM
*To:*django-developers@googlegroups.com
<mailto: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 

Re: Deprecate HttpRequest.is_ajax

[Matemática A3K]

I agree with Adam that it should be deprecated with no replacement.

The content negotiation is something that should be in but not as a
replacement of it, as a general improvement.

I think there shouldn't be a replacement because "is_ajax" asks whether it
came from a ""regular"" browser instead of jQuery and with the content
negotiation you ask if the requester accepts a type - which can also lead
to errors because the client may also accept other types (no example coming
to my mind), and if so, it will lead to undesired behavior.

The right approach would be making AJAX requests request JSON output
explicitly, by using a dedicated endpoint or by appending something that
manifests their intention - like in
https://docs.djangoproject.com/en/2.2/topics/class-based-views/mixins/#more-than-just-html
is done with a get parameter. Not decide the response type by where it came
from as it is unreliable as stated before, it provides convenience in some
use cases but can lead to errors.

Seems better to me to refactor the view code so you can write a different
view for Ajax requests that returns a JSON without code duplication.

As a shortcut, something like "For simple AJAX endpoints wrap your view
with (something like) a "jsonview" decorator which will check the accept
header (with something like Claude's code), return the appropriate error
code if not, set the response type accordingly, and you should return a
dict of strings (you have to take care of the serialization, i.e with
https://docs.djangoproject.com/en/2.2/topics/serialization/#serialization-formats-json).


On Mon, Nov 18, 2019 at 3:28 PM Tom Forbes  wrote:

> What I meant by that is it’s not an approach that scales well to lots of
> views. It might be better to have separate endpoints to return JSON (e.g
> adding a /json suffix), and in the past this has made services I’ve worked
> on a lot more maintainable and easy to understand. But it’s not as quick to
> do as `if request.is_ajax()` and requires a bit more upfront work. If you
> find you need to do this a lot then maybe something more structured like
> Django Rest Framework will be a better choice, which also handles content
> negotiation really well (it can produce XML, CSV, JSON, etc etc).
>

> On 18 Nov 2019, at 15:18, Matthew Pava  wrote:
>
> “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=request.is_ajax=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=request.is_ajax=Code), which
> isn’t great and isn’t reliable.
>
>
>
> On 16 Nov 2019, at 16:08, Adam Johnson  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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/

Re: Deprecate HttpRequest.is_ajax

[Tom Forbes]

What I meant by that is it’s not an approach that scales well to lots of views. 
It might be better to have separate endpoints to return JSON (e.g adding a 
/json suffix), and in the past this has made services I’ve worked on a lot more 
maintainable and easy to understand. But it’s not as quick to do as `if 
request.is_ajax()` and requires a bit more upfront work. If you find you need 
to do this a lot then maybe something more structured like Django Rest 
Framework will be a better choice, which also handles content negotiation 
really well (it can produce XML, CSV, JSON, etc etc).

> On 18 Nov 2019, at 15:18, Matthew Pava  wrote:
> 
> “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=request.is_ajax=Code 
> <https://github.com/search?l=Python=request.is_ajax=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=request.is_ajax=Code 
> <https://github.com/search?l=Python=request.is_ajax=Code>), which 
> isn’t great and isn’t reliable.
>  
> 
> 
> On 16 Nov 2019, at 16:08, Adam Johnson 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
>  
> <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 
> <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_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_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:djan

RE: Deprecate HttpRequest.is_ajax

[Matthew Pava]

“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=request.is_ajax=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=request.is_ajax=Code), which isn’t 
great and isn’t reliable.



On 16 Nov 2019, at 16:08, Adam Johnson 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_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_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.

Re: Deprecate HttpRequest.is_ajax

[Tom Forbes]

I think this is a good starting point. What do we think about adding a 
“accepts_json” helper of some kind? It seems that the vast, vast majority of 
usages I can find of “is_ajax” is to return a JSON response, which I feel could 
be served nicely with a helper. There are also, annoyingly, two different JSON 
content types that are sent (the correct application/json and the incorrect 
text/json), which a helper could take care of. 


> On 17 Nov 2019, at 12:56, Claude Paroz  wrote:
> 
> I'm afraid that implementing a whole content negociation framework is a bit 
> ambitious, unless someone has much time to devote to that.
> 
> We could start smaller, similar to django-accept-header. I quickly sketched 
> what it could look like in:
> https://github.com/django/django/compare/master...claudep:accept_header?expand=1
> 
> Claude
> 
> Le dimanche 17 novembre 2019 12:32:50 UTC+1, Asif Saif Uddin a écrit :
> any plan with 
> https://github.com/django/deps/blob/master/draft/content-negotiation.rst 
>  
> one?
>  
> 
> -- 
> 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/7aff16cc-aeff-4b5e-b402-e4d587bc9315%40googlegroups.com
>  
> .

-- 
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/22260C6C-702C-40F3-A847-38C0A69D3C43%40tomforb.es.

Re: Deprecate HttpRequest.is_ajax

[Claude Paroz]

I'm afraid that implementing a whole content negociation framework is a bit 
ambitious, unless someone has much time to devote to that.

We could start smaller, similar to django-accept-header. I quickly sketched 
what it could look like in:
https://github.com/django/django/compare/master...claudep:accept_header?expand=1

Claude

Le dimanche 17 novembre 2019 12:32:50 UTC+1, Asif Saif Uddin a écrit :
>
> any plan with 
> https://github.com/django/deps/blob/master/draft/content-negotiation.rst 
> one?
>
 

-- 
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/7aff16cc-aeff-4b5e-b402-e4d587bc9315%40googlegroups.com.

Re: Deprecate HttpRequest.is_ajax

[Asif Saif Uddin]

any plan with 
https://github.com/django/deps/blob/master/draft/content-negotiation.rst 
one?

On Sunday, November 17, 2019 at 2:00:26 PM UTC+6, Adam Johnson wrote:
>
> Right - Flask's error message also points to something I was mistaken 
> about. XMLHttpRequest does not set this header. jQuery adds it ( 
> https://api.jquery.com/jquery.ajax/#jQuery-ajax-settings ), and 
> presumably some other JS libraries.
>
> 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=request.is_ajax=Code), which 
>> isn’t great and isn’t reliable.
>>
>
> Riight too. A better way would be to check the Accept header. DRF does 
> this: https://www.django-rest-framework.org/api-guide/content-negotiation/ 
> . Django doesn't provide any tools at the moment for parsing Accept. We 
> could add an API like https://pypi.org/project/django-accept-header/ ?
>
> On Sat, 16 Nov 2019 at 16:16, Tom Forbes > 
> wrote:
>
>> 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=request.is_ajax=Code), which 
>> isn’t great and isn’t reliable.
>>
>>
>> On 16 Nov 2019, at 16:08, Adam Johnson > 
>> 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-d...@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
>>  
>> 
>> .
>>
>>
>> -- 
>> 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-d...@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
>>  
>> 
>> .
>>
>
>
> -- 
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/48b34cca-02bf-4f2c-817d-65afbd1ab125%40googlegroups.com.

Re: Deprecate HttpRequest.is_ajax

[Jani Tiainen]

Hi.

I would be really favorable suggested approach which would open up more
possibilities to responses. And in general sounds good direction.

su 17. marrask. 2019 klo 10.00 Adam Johnson  kirjoitti:

> Right - Flask's error message also points to something I was mistaken
> about. XMLHttpRequest does not set this header. jQuery adds it (
> https://api.jquery.com/jquery.ajax/#jQuery-ajax-settings ), and
> presumably some other JS libraries.
>
> 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=request.is_ajax=Code), which
>> isn’t great and isn’t reliable.
>>
>
> Riight too. A better way would be to check the Accept header. DRF does
> this: https://www.django-rest-framework.org/api-guide/content-negotiation/
> . Django doesn't provide any tools at the moment for parsing Accept. We
> could add an API like https://pypi.org/project/django-accept-header/ ?
>
> On Sat, 16 Nov 2019 at 16:16, Tom Forbes  wrote:
>
>> 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=request.is_ajax=Code), which
>> isn’t great and isn’t reliable.
>>
>>
>> On 16 Nov 2019, at 16:08, Adam Johnson  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.
>> 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
>> 
>> .
>>
>>
>> --
>> 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/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es
>> 
>> .
>>
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM12ozNou4y6s-AktSwnMfBLDR5FJjYAw-n0kofZ3%3DYtoA%40mail.gmail.com
> 
> .
>

-- 
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/CAHn91ofvv3JXppzfGojGgOrQSRrXPhwAMmt_xos4GUsi_BFZdA%40mail.gmail.com.

Re: Deprecate HttpRequest.is_ajax

[Adam Johnson]

Right - Flask's error message also points to something I was mistaken
about. XMLHttpRequest does not set this header. jQuery adds it (
https://api.jquery.com/jquery.ajax/#jQuery-ajax-settings ), and presumably
some other JS libraries.

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=request.is_ajax=Code), which
> isn’t great and isn’t reliable.
>

Riight too. A better way would be to check the Accept header. DRF does
this: https://www.django-rest-framework.org/api-guide/content-negotiation/
. Django doesn't provide any tools at the moment for parsing Accept. We
could add an API like https://pypi.org/project/django-accept-header/ ?

On Sat, 16 Nov 2019 at 16:16, Tom Forbes  wrote:

> 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=request.is_ajax=Code), which
> isn’t great and isn’t reliable.
>
>
> On 16 Nov 2019, at 16:08, Adam Johnson  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.
> 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
> 
> .
>
>
> --
> 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/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es
> 
> .
>


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM12ozNou4y6s-AktSwnMfBLDR5FJjYAw-n0kofZ3%3DYtoA%40mail.gmail.com.

Re: Deprecate HttpRequest.is_ajax

[Tom Forbes]

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=request.is_ajax=Code 
), which isn’t 
great and isn’t reliable.


> On 16 Nov 2019, at 16:08, Adam Johnson  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 
> .
> 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
>  
> .

-- 
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/84DCD242-69A8-4B8D-9EB6-243312B5F77F%40tomforb.es.