Re: GOALS? Feature Request: $.ajax(): Detect json via response header

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

Rick Waldron
We're struggling with the best way to inform .ajax() that we expect
multiple data types. Either, with a setting like "auto" or by passing an
array of data types (or maybe allowing both).

Perhaps it would help if we defined a list of goals. I'll start.

1. $.ajax() - if dataType has not been defined in the argument list, $.ajax() should respect the returned Content-type header and translate accordingly.

2. ....


Fill it in!




Rick




 
On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
We're struggling with the best way to inform .ajax() that we expect
multiple data types. Either, with a setting like "auto" or by passing an
array of data types (or maybe allowing both).


On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson <[hidden email]>
wrote:
> Seems like a lot of awkward wheel reinventing going on here. Content
> type negotiation is a feature of HTTP; is there a reason we aren't
> using it?
>
> --Erik
>
>
> On Saturday, December 26, 2009, webbiedave <[hidden email]>
> wrote:
>> "Following your idea that a library has to keep exactly the same
>> behavior from versions to versions [...] then what happens if & when
>> jQuery introduces a new auto-detectable dataType in 1.4.1"
>>
>> Things could break *without* the introduction of new auto-detectable
>> types. If you use "auto" and are only handling json and html and
>> suddenly javascript is returned, that javascript will be eval'd and
>> things will will not turn out well. That's why you can't use "auto" on
>> untrusted/incompetent servers. That's the whole point of "auto". You
>> are trusting the server to return the correct data. Use at your own
>> risk. But it's there if you need it.
>>
>> Having said that, #1 in my suggestions is passing an array (dataType:
>> ["json", html"]).
>>
>>
>>
>> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]> wrote:
>>> > As I mentioned in my previous
>>> > post, one of this approach's downside is "null vs auto" confusion as
>>> > auto is like null plus more (json, script, future accepted
dataTypes).
>>> > The whole point is that "auto" means auto-detect type via
content-type
>>> > headers and null does not mean that (it means guess between html or
>>> > xml)
>>>
>>> This is exactly where the solution is inconsistent.
>>>
>>> "auto", in your implementation, does not mean "null plus more (json,
>>> script,
>>> *future accepted dataTypes*)" but it just means "null plus json &
>>> script"
>>> and only that. Following your idea that a library has to keep exactly
>>> the
>>> same behavior from versions to versions (which jQuery broke btw when
>>> ditching the @ syntax for attributes in selectors) then what happens if
>>> &
>>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You
>>> create
>>> an "auto2" dataType so that existing code running in 1.4 is unaffected
>>> (ie:
>>> the new dataType is not auto-detected)? How would you document such a
>>> behaviour? What happens when there's another auto-detectable dataType
>>> introduced in 1.4.2?
>>>
>>> Giving programmers a way to specify exactly the dataTypes they expect
to
>>> be
>>> auto-detected is the way to go (would it be with an array or an
>>> expression).
>>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code and
>>> you're
>>> done: no backward compatibility issue... plus you're safe for future
>>> developments in the dataType auto-detection area.
>>>
>>> 2009/12/27 webbiedave <[hidden email]>
>>>
>>> > "Second, auto seems like the weirdest thing ever to me used like it
is
>>> > here. So dataType==null and dataType=="auto" act the same for xml but
>>> > not for script & json? Seems completely inconsistant to me."
>>>
>>> > It's not that weird. I don't think that different settings yielding
>>> > different results is necessarily inconsistent. There are two ways to
>>> > get xml and now there'll be a third. As I mentioned in my previous
>>> > post, one of this approach's downside is "null vs auto" confusion as
>>> > auto is like null plus more (json, script, future accepted
dataTypes).
>>> > The whole point is that "auto" means auto-detect type via
content-type
>>> > headers and null does not mean that (it means guess between html or
>>> > xml). It is imperative that the behavior of dataType: null remains
the
>>> > same so this is a way to do that while affording multiple expected
>>> > dataTypes in a way that's secure, doesn't bloat and doesn't break
>>> > existing apps. Quite frankly, it usage makes simple sense to me and
>>> > those who need it will know exactly what it means and how to use it
>>> > (and will be relieved they can ditch their hacked libraries).
>>>
>>> > "If a coder does not want auto conversion, then he simply specifies a
>>> > dataType (namely "text")."
>>>
>>> > But null does not mean auto convert. It means guess between html or
>>> > xml and that cannot change.
>>>
>>> > "But, please, do not introduce a behavior that will act differently
>>> > for xml than it does for any other dataType deduced from content type
>>> > headers."
>>>
>>> > I admit I don't share your fear of such behavior and, in fact,
greatly
>>> > desire such a new setting. I'll know that my live apps that are using
>>> > dataType: null will be unaffected and in the future I'd be able to
>>> > write ajax calls that can respond to various data types. Also, I've
>>> > suggested several approaches and look forward to reading what others
>>> > think of them.
>>>
>>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]> wrote:
>>> > > Regardless, I'm leaning towards the dataType: "auto" approach as
>>> > > it's easy to use/implement and affords enough control.
>>>
>>> > > Well, so, first, I translated the dataType to "auto" when it was
>>> > > null/undefined in my rewriting (because I hate messy/undefined
>>> > > values).
>>> > But
>>> > > that's no biggy.
>>>
>>> > > Second, auto seems like the weirdest thing ever to me used like it
>>> > > is
>>> > here.
>>> > > So dataType==null and dataType=="auto" act the same for xml but not
>>> > > for
>>> > > script & json? Seems completely inconsistant to me.
>>>
>>> > > If a coder does not want auto conversion, then he simply specifies
a
>>> > > dataType (namely "text"). You just have to document it. But,
please,
>>> > > do
>>> > not
>>> > > introduce a behavior that will act differentely for xml than it
does
>>> > > for
>>> > any
>>> > > other dataType deduced from content type headers.
>>>
>>> > > 2009/12/26 webbiedave <[hidden email]>
>>>
>>> > > > I was referring solely to the "bitwise or" style. Regardless, I'm
>>> > > > leaning towards the dataType: "auto" approach as it's easy to
use/
>>> > > > implement and affords enough control.
>>>
>>> > > > Julian Aubourg wrote:
>>>
>>> > > > > As for string expressions not being in the calling style of
>>> > > > > jQuery...
>>> > > > > well... I really disagree here, since jQuery has expression
>>> > > > > parsed
>>> > parsed
>>> > > > > pretty much everywhere ;)
>>>
>>> > > > --
>>>
>>> > > > You received this message because you are subscribed to the
Google
>>> > Groups
>>> > > > "jQuery Development" group.
>>> > > > To post to this group, send email to [hidden email].
>>> > > > To unsubscribe from this group, send email to
>>> > > > > >
<[hidden email]<[hidden email]>
>>>
>>> > > > .
>>> > > > For more options, visit this group at
>>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>>>
>>> > --
>>>
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "jQuery Development" group.
>>> > To post to this group, send email to [hidden email].
>>> > To unsubscribe from this group, send email to
>>> >
[hidden email]<[hidden email]>
>>> > .
>>> > For more options, visit this group at
>>> >http://groups.google.com/group/jquery-dev?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google
Groups
>> "jQuery Development" group.
>> To post to this group, send email to [hidden email].
>> To unsubscribe from this group, send email to
>> [hidden email].
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.



--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

webbiedave-2
Rick, your 1 (which I too have suggested in the past) might bring about
unease as folks would prefer any eval-ing to come through explicit request.
I also think it's imperative that the behavior of any dataType setting
(including null) shouldn't change (especially to one that suddenly evals!).
But that's just my opinion. My 1, 2 would be:

1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.



On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron <[hidden email]>
wrote:

>>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>
> Perhaps it would help if we defined a list of goals. I'll start.
>
> 1. $.ajax() - if dataType has not been defined in the argument list,
> $.ajax() should respect the returned Content-type header and translate
> accordingly.
>
> 2. ....
>
>
> Fill it in!
>
>
>
>
> Rick
>
>
>
>
>
> On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>>
>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson <[hidden email]>
>> wrote:
>> > Seems like a lot of awkward wheel reinventing going on here. Content
>> > type negotiation is a feature of HTTP; is there a reason we aren't
>> > using it?
>> >
>> > --Erik
>> >
>> >
>> > On Saturday, December 26, 2009, webbiedave
>> > <[hidden email]>
>> > wrote:
>> >> "Following your idea that a library has to keep exactly the same
>> >> behavior from versions to versions [...] then what happens if & when
>> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>> >>
>> >> Things could break *without* the introduction of new auto-detectable
>> >> types. If you use "auto" and are only handling json and html and
>> >> suddenly javascript is returned, that javascript will be eval'd and
>> >> things will will not turn out well. That's why you can't use "auto"
on

>> >> untrusted/incompetent servers. That's the whole point of "auto". You
>> >> are trusting the server to return the correct data. Use at your own
>> >> risk. But it's there if you need it.
>> >>
>> >> Having said that, #1 in my suggestions is passing an array (dataType:
>> >> ["json", html"]).
>> >>
>> >>
>> >>
>> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]> wrote:
>> >>> > As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml)
>> >>>
>> >>> This is exactly where the solution is inconsistent.
>> >>>
>> >>> "auto", in your implementation, does not mean "null plus more (json,
>> >>> script,
>> >>> *future accepted dataTypes*)" but it just means "null plus json &
>> >>> script"
>> >>> and only that. Following your idea that a library has to keep
exactly

>> >>> the
>> >>> same behavior from versions to versions (which jQuery broke btw when
>> >>> ditching the @ syntax for attributes in selectors) then what happens
>> >>> if
>> >>> &
>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You
>> >>> create
>> >>> an "auto2" dataType so that existing code running in 1.4 is
>> >>> unaffected
>> >>> (ie:
>> >>> the new dataType is not auto-detected)? How would you document such
a
>> >>> behaviour? What happens when there's another auto-detectable
dataType
>> >>> introduced in 1.4.2?
>> >>>
>> >>> Giving programmers a way to specify exactly the dataTypes they
expect
>> to
>> >>> be
>> >>> auto-detected is the way to go (would it be with an array or an
>> >>> expression).
>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code
and
>> >>> you're
>> >>> done: no backward compatibility issue... plus you're safe for future
>> >>> developments in the dataType auto-detection area.
>> >>>
>> >>> 2009/12/27 webbiedave <[hidden email]>
>> >>>
>> >>> > "Second, auto seems like the weirdest thing ever to me used like
it
>> is
>> >>> > here. So dataType==null and dataType=="auto" act the same for xml
>> >>> > but
>> >>> > not for script & json? Seems completely inconsistant to me."
>> >>>
>> >>> > It's not that weird. I don't think that different settings
yielding

>> >>> > different results is necessarily inconsistent. There are two ways
>> >>> > to
>> >>> > get xml and now there'll be a third. As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml). It is imperative that the behavior of dataType: null remains
>> the
>> >>> > same so this is a way to do that while affording multiple expected
>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't break
>> >>> > existing apps. Quite frankly, it usage makes simple sense to me
and
>> >>> > those who need it will know exactly what it means and how to use
it
>> >>> > (and will be relieved they can ditch their hacked libraries).
>> >>>
>> >>> > "If a coder does not want auto conversion, then he simply
specifies
>> >>> > a
>> >>> > dataType (namely "text")."
>> >>>
>> >>> > But null does not mean auto convert. It means guess between html
or
>> >>> > xml and that cannot change.
>> >>>
>> >>> > "But, please, do not introduce a behavior that will act
differently

>> >>> > for xml than it does for any other dataType deduced from content
>> >>> > type
>> >>> > headers."
>> >>>
>> >>> > I admit I don't share your fear of such behavior and, in fact,
>> greatly
>> >>> > desire such a new setting. I'll know that my live apps that are
>> >>> > using
>> >>> > dataType: null will be unaffected and in the future I'd be able to
>> >>> > write ajax calls that can respond to various data types. Also,
I've

>> >>> > suggested several approaches and look forward to reading what
>> >>> > others
>> >>> > think of them.
>> >>>
>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>> >>> > wrote:
>> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach as
>> >>> > > it's easy to use/implement and affords enough control.
>> >>>
>> >>> > > Well, so, first, I translated the dataType to "auto" when it was
>> >>> > > null/undefined in my rewriting (because I hate messy/undefined
>> >>> > > values).
>> >>> > But
>> >>> > > that's no biggy.
>> >>>
>> >>> > > Second, auto seems like the weirdest thing ever to me used like
>> >>> > > it
>> >>> > > is
>> >>> > here.
>> >>> > > So dataType==null and dataType=="auto" act the same for xml but
>> >>> > > not
>> >>> > > for
>> >>> > > script & json? Seems completely inconsistant to me.
>> >>>
>> >>> > > If a coder does not want auto conversion, then he simply
>> >>> > > specifies
>> a
>> >>> > > dataType (namely "text"). You just have to document it. But,
>> please,
>> >>> > > do
>> >>> > not
>> >>> > > introduce a behavior that will act differentely for xml than it
>> does
>> >>> > > for
>> >>> > any
>> >>> > > other dataType deduced from content type headers.
>> >>>
>> >>> > > 2009/12/26 webbiedave <[hidden email]>
>> >>>
>> >>> > > > I was referring solely to the "bitwise or" style. Regardless,
>> >>> > > > I'm
>> >>> > > > leaning towards the dataType: "auto" approach as it's easy to
>> use/
>> >>> > > > implement and affords enough control.
>> >>>
>> >>> > > > Julian Aubourg wrote:
>> >>>
>> >>> > > > > As for string expressions not being in the calling style of
>> >>> > > > > jQuery...
>> >>> > > > > well... I really disagree here, since jQuery has expression
>> >>> > > > > parsed
>> >>> > parsed
>> >>> > > > > pretty much everywhere ;)
>> >>>
>> >>> > > > --
>> >>>
>> >>> > > > You received this message because you are subscribed to the
>> Google
>> >>> > Groups
>> >>> > > > "jQuery Development" group.
>> >>> > > > To post to this group, send email to
>> >>> > > > [hidden email]
>> .
>> >>> > > > To unsubscribe from this group, send email to
>> >>> > > > > >
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>> >
>> >>>
>> >>> > > > .
>> >>> > > > For more options, visit this group at
>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>> >>>
>> >>> > --
>> >>>
>> >>> > You received this message because you are subscribed to the Google
>> >>> > Groups
>> >>> > "jQuery Development" group.
>> >>> > To post to this group, send email to [hidden email].
>> >>> > To unsubscribe from this group, send email to
>> >>> >
>>
[hidden email]<jquery-dev%[hidden email]>
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>> >
>> >>> > .
>> >>> > For more options, visit this group at
>> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >> --
>> >>
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "jQuery Development" group.
>> >> To post to this group, send email to [hidden email].
>> >> To unsubscribe from this group, send email to
>> >>
[hidden email]<jquery-dev%[hidden email]>

>> .
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >>
>> >>
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> > To post to this group, send email to [hidden email].
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<jquery-dev%[hidden email]>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google
Groups
>> "jQuery Development" group.
>> To post to this group, send email to [hidden email].
>> To unsubscribe from this group, send email to
>>
[hidden email]<jquery-dev%[hidden email]>

>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

Rick Waldron
I can compromise with your #2, and give them both my vote.

Passing it on...

1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.




Julian - your thoughts?


On Mon, Dec 28, 2009 at 3:39 PM, webbiedave <[hidden email]> wrote:
Rick, your 1 (which I too have suggested in the past) might bring about
unease as folks would prefer any eval-ing to come through explicit request.
I also think it's imperative that the behavior of any dataType setting
(including null) shouldn't change (especially to one that suddenly evals!).
But that's just my opinion. My 1, 2 would be:

1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.



On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron <[hidden email]>
wrote:
>>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>
> Perhaps it would help if we defined a list of goals. I'll start.
>
> 1. $.ajax() - if dataType has not been defined in the argument list,
> $.ajax() should respect the returned Content-type header and translate
> accordingly.
>
> 2. ....
>
>
> Fill it in!
>
>
>
>
> Rick
>
>
>
>
>
> On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>>
>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson <[hidden email]>
>> wrote:
>> > Seems like a lot of awkward wheel reinventing going on here. Content
>> > type negotiation is a feature of HTTP; is there a reason we aren't
>> > using it?
>> >
>> > --Erik
>> >
>> >
>> > On Saturday, December 26, 2009, webbiedave
>> > <[hidden email]>
>> > wrote:
>> >> "Following your idea that a library has to keep exactly the same
>> >> behavior from versions to versions [...] then what happens if & when
>> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>> >>
>> >> Things could break *without* the introduction of new auto-detectable
>> >> types. If you use "auto" and are only handling json and html and
>> >> suddenly javascript is returned, that javascript will be eval'd and
>> >> things will will not turn out well. That's why you can't use "auto"
on
>> >> untrusted/incompetent servers. That's the whole point of "auto". You
>> >> are trusting the server to return the correct data. Use at your own
>> >> risk. But it's there if you need it.
>> >>
>> >> Having said that, #1 in my suggestions is passing an array (dataType:
>> >> ["json", html"]).
>> >>
>> >>
>> >>
>> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]> wrote:
>> >>> > As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml)
>> >>>
>> >>> This is exactly where the solution is inconsistent.
>> >>>
>> >>> "auto", in your implementation, does not mean "null plus more (json,
>> >>> script,
>> >>> *future accepted dataTypes*)" but it just means "null plus json &
>> >>> script"
>> >>> and only that. Following your idea that a library has to keep
exactly
>> >>> the
>> >>> same behavior from versions to versions (which jQuery broke btw when
>> >>> ditching the @ syntax for attributes in selectors) then what happens
>> >>> if
>> >>> &
>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You
>> >>> create
>> >>> an "auto2" dataType so that existing code running in 1.4 is
>> >>> unaffected
>> >>> (ie:
>> >>> the new dataType is not auto-detected)? How would you document such
a
>> >>> behaviour? What happens when there's another auto-detectable
dataType
>> >>> introduced in 1.4.2?
>> >>>
>> >>> Giving programmers a way to specify exactly the dataTypes they
expect
>> to
>> >>> be
>> >>> auto-detected is the way to go (would it be with an array or an
>> >>> expression).
>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code
and
>> >>> you're
>> >>> done: no backward compatibility issue... plus you're safe for future
>> >>> developments in the dataType auto-detection area.
>> >>>
>> >>> 2009/12/27 webbiedave <[hidden email]>
>> >>>
>> >>> > "Second, auto seems like the weirdest thing ever to me used like
it
>> is
>> >>> > here. So dataType==null and dataType=="auto" act the same for xml
>> >>> > but
>> >>> > not for script & json? Seems completely inconsistant to me."
>> >>>
>> >>> > It's not that weird. I don't think that different settings
yielding
>> >>> > different results is necessarily inconsistent. There are two ways
>> >>> > to
>> >>> > get xml and now there'll be a third. As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml). It is imperative that the behavior of dataType: null remains
>> the
>> >>> > same so this is a way to do that while affording multiple expected
>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't break
>> >>> > existing apps. Quite frankly, it usage makes simple sense to me
and
>> >>> > those who need it will know exactly what it means and how to use
it
>> >>> > (and will be relieved they can ditch their hacked libraries).
>> >>>
>> >>> > "If a coder does not want auto conversion, then he simply
specifies
>> >>> > a
>> >>> > dataType (namely "text")."
>> >>>
>> >>> > But null does not mean auto convert. It means guess between html
or
>> >>> > xml and that cannot change.
>> >>>
>> >>> > "But, please, do not introduce a behavior that will act
differently
>> >>> > for xml than it does for any other dataType deduced from content
>> >>> > type
>> >>> > headers."
>> >>>
>> >>> > I admit I don't share your fear of such behavior and, in fact,
>> greatly
>> >>> > desire such a new setting. I'll know that my live apps that are
>> >>> > using
>> >>> > dataType: null will be unaffected and in the future I'd be able to
>> >>> > write ajax calls that can respond to various data types. Also,
I've
>> >>> > suggested several approaches and look forward to reading what
>> >>> > others
>> >>> > think of them.
>> >>>
>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>> >>> > wrote:
>> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach as
>> >>> > > it's easy to use/implement and affords enough control.
>> >>>
>> >>> > > Well, so, first, I translated the dataType to "auto" when it was
>> >>> > > null/undefined in my rewriting (because I hate messy/undefined
>> >>> > > values).
>> >>> > But
>> >>> > > that's no biggy.
>> >>>
>> >>> > > Second, auto seems like the weirdest thing ever to me used like
>> >>> > > it
>> >>> > > is
>> >>> > here.
>> >>> > > So dataType==null and dataType=="auto" act the same for xml but
>> >>> > > not
>> >>> > > for
>> >>> > > script & json? Seems completely inconsistant to me.
>> >>>
>> >>> > > If a coder does not want auto conversion, then he simply
>> >>> > > specifies
>> a
>> >>> > > dataType (namely "text"). You just have to document it. But,
>> please,
>> >>> > > do
>> >>> > not
>> >>> > > introduce a behavior that will act differentely for xml than it
>> does
>> >>> > > for
>> >>> > any
>> >>> > > other dataType deduced from content type headers.
>> >>>
>> >>> > > 2009/12/26 webbiedave <[hidden email]>
>> >>>
>> >>> > > > I was referring solely to the "bitwise or" style. Regardless,
>> >>> > > > I'm
>> >>> > > > leaning towards the dataType: "auto" approach as it's easy to
>> use/
>> >>> > > > implement and affords enough control.
>> >>>
>> >>> > > > Julian Aubourg wrote:
>> >>>
>> >>> > > > > As for string expressions not being in the calling style of
>> >>> > > > > jQuery...
>> >>> > > > > well... I really disagree here, since jQuery has expression
>> >>> > > > > parsed
>> >>> > parsed
>> >>> > > > > pretty much everywhere ;)
>> >>>
>> >>> > > > --
>> >>>
>> >>> > > > You received this message because you are subscribed to the
>> Google
>> >>> > Groups
>> >>> > > > "jQuery Development" group.
>> >>> > > > To post to this group, send email to
>> >>> > > > [hidden email]
>> .
>> >>> > > > To unsubscribe from this group, send email to
>> >>> > > > > >
>>
<[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>>
>> >>> > > > .
>> >>> > > > For more options, visit this group at
>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>> >>>
>> >>> > --
>> >>>
>> >>> > You received this message because you are subscribed to the Google
>> >>> > Groups
>> >>> > "jQuery Development" group.
>> >>> > To post to this group, send email to [hidden email].
>> >>> > To unsubscribe from this group, send email to
>> >>> >
>>
[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>> > .
>> >>> > For more options, visit this group at
>> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >> --
>> >>
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "jQuery Development" group.
>> >> To post to this group, send email to [hidden email].
>> >> To unsubscribe from this group, send email to
>> >>
[hidden email]<[hidden email]>
>> .
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >>
>> >>
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> > To post to this group, send email to [hidden email].
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<[hidden email]>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google
Groups
>> "jQuery Development" group.
>> To post to this group, send email to [hidden email].
>> To unsubscribe from this group, send email to
>>
[hidden email]<[hidden email]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.



--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

Erik Beeson
Again, why not do this with an Accept header?

Client sends acceptable content types, server responds with a content type, if the server's response is one of the accepted types, jQuery processes accordingly, if not, jQuery returns data unprocessed.

The dataType option should be for things that aren't necessarily well communicated via content-type alone, like JSONP, or anything else that modifies the nature of the request, not just the content type.

If you're worried about your server sending malicious javascript, then only accept text/plain or text/xml (even dataType: 'html' isn't safe since it executes script blocks). If you don't care, then accept "*/*".

Or am I missing something?

--Erik


On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron <[hidden email]> wrote:
I can compromise with your #2, and give them both my vote.

Passing it on...


1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.




Julian - your thoughts?



On Mon, Dec 28, 2009 at 3:39 PM, webbiedave <[hidden email]> wrote:
Rick, your 1 (which I too have suggested in the past) might bring about
unease as folks would prefer any eval-ing to come through explicit request.
I also think it's imperative that the behavior of any dataType setting
(including null) shouldn't change (especially to one that suddenly evals!).
But that's just my opinion. My 1, 2 would be:

1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.



On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron <[hidden email]>
wrote:
>>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>
> Perhaps it would help if we defined a list of goals. I'll start.
>
> 1. $.ajax() - if dataType has not been defined in the argument list,
> $.ajax() should respect the returned Content-type header and translate
> accordingly.
>
> 2. ....
>
>
> Fill it in!
>
>
>
>
> Rick
>
>
>
>
>
> On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>>
>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson <[hidden email]>
>> wrote:
>> > Seems like a lot of awkward wheel reinventing going on here. Content
>> > type negotiation is a feature of HTTP; is there a reason we aren't
>> > using it?
>> >
>> > --Erik
>> >
>> >
>> > On Saturday, December 26, 2009, webbiedave
>> > <[hidden email]>
>> > wrote:
>> >> "Following your idea that a library has to keep exactly the same
>> >> behavior from versions to versions [...] then what happens if & when
>> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>> >>
>> >> Things could break *without* the introduction of new auto-detectable
>> >> types. If you use "auto" and are only handling json and html and
>> >> suddenly javascript is returned, that javascript will be eval'd and
>> >> things will will not turn out well. That's why you can't use "auto"
on
>> >> untrusted/incompetent servers. That's the whole point of "auto". You
>> >> are trusting the server to return the correct data. Use at your own
>> >> risk. But it's there if you need it.
>> >>
>> >> Having said that, #1 in my suggestions is passing an array (dataType:
>> >> ["json", html"]).
>> >>
>> >>
>> >>
>> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]> wrote:
>> >>> > As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml)
>> >>>
>> >>> This is exactly where the solution is inconsistent.
>> >>>
>> >>> "auto", in your implementation, does not mean "null plus more (json,
>> >>> script,
>> >>> *future accepted dataTypes*)" but it just means "null plus json &
>> >>> script"
>> >>> and only that. Following your idea that a library has to keep
exactly
>> >>> the
>> >>> same behavior from versions to versions (which jQuery broke btw when
>> >>> ditching the @ syntax for attributes in selectors) then what happens
>> >>> if
>> >>> &
>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You
>> >>> create
>> >>> an "auto2" dataType so that existing code running in 1.4 is
>> >>> unaffected
>> >>> (ie:
>> >>> the new dataType is not auto-detected)? How would you document such
a
>> >>> behaviour? What happens when there's another auto-detectable
dataType
>> >>> introduced in 1.4.2?
>> >>>
>> >>> Giving programmers a way to specify exactly the dataTypes they
expect
>> to
>> >>> be
>> >>> auto-detected is the way to go (would it be with an array or an
>> >>> expression).
>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code
and
>> >>> you're
>> >>> done: no backward compatibility issue... plus you're safe for future
>> >>> developments in the dataType auto-detection area.
>> >>>
>> >>> 2009/12/27 webbiedave <[hidden email]>
>> >>>
>> >>> > "Second, auto seems like the weirdest thing ever to me used like
it
>> is
>> >>> > here. So dataType==null and dataType=="auto" act the same for xml
>> >>> > but
>> >>> > not for script & json? Seems completely inconsistant to me."
>> >>>
>> >>> > It's not that weird. I don't think that different settings
yielding
>> >>> > different results is necessarily inconsistent. There are two ways
>> >>> > to
>> >>> > get xml and now there'll be a third. As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml). It is imperative that the behavior of dataType: null remains
>> the
>> >>> > same so this is a way to do that while affording multiple expected
>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't break
>> >>> > existing apps. Quite frankly, it usage makes simple sense to me
and
>> >>> > those who need it will know exactly what it means and how to use
it
>> >>> > (and will be relieved they can ditch their hacked libraries).
>> >>>
>> >>> > "If a coder does not want auto conversion, then he simply
specifies
>> >>> > a
>> >>> > dataType (namely "text")."
>> >>>
>> >>> > But null does not mean auto convert. It means guess between html
or
>> >>> > xml and that cannot change.
>> >>>
>> >>> > "But, please, do not introduce a behavior that will act
differently
>> >>> > for xml than it does for any other dataType deduced from content
>> >>> > type
>> >>> > headers."
>> >>>
>> >>> > I admit I don't share your fear of such behavior and, in fact,
>> greatly
>> >>> > desire such a new setting. I'll know that my live apps that are
>> >>> > using
>> >>> > dataType: null will be unaffected and in the future I'd be able to
>> >>> > write ajax calls that can respond to various data types. Also,
I've
>> >>> > suggested several approaches and look forward to reading what
>> >>> > others
>> >>> > think of them.
>> >>>
>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>> >>> > wrote:
>> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach as
>> >>> > > it's easy to use/implement and affords enough control.
>> >>>
>> >>> > > Well, so, first, I translated the dataType to "auto" when it was
>> >>> > > null/undefined in my rewriting (because I hate messy/undefined
>> >>> > > values).
>> >>> > But
>> >>> > > that's no biggy.
>> >>>
>> >>> > > Second, auto seems like the weirdest thing ever to me used like
>> >>> > > it
>> >>> > > is
>> >>> > here.
>> >>> > > So dataType==null and dataType=="auto" act the same for xml but
>> >>> > > not
>> >>> > > for
>> >>> > > script & json? Seems completely inconsistant to me.
>> >>>
>> >>> > > If a coder does not want auto conversion, then he simply
>> >>> > > specifies
>> a
>> >>> > > dataType (namely "text"). You just have to document it. But,
>> please,
>> >>> > > do
>> >>> > not
>> >>> > > introduce a behavior that will act differentely for xml than it
>> does
>> >>> > > for
>> >>> > any
>> >>> > > other dataType deduced from content type headers.
>> >>>
>> >>> > > 2009/12/26 webbiedave <[hidden email]>
>> >>>
>> >>> > > > I was referring solely to the "bitwise or" style. Regardless,
>> >>> > > > I'm
>> >>> > > > leaning towards the dataType: "auto" approach as it's easy to
>> use/
>> >>> > > > implement and affords enough control.
>> >>>
>> >>> > > > Julian Aubourg wrote:
>> >>>
>> >>> > > > > As for string expressions not being in the calling style of
>> >>> > > > > jQuery...
>> >>> > > > > well... I really disagree here, since jQuery has expression
>> >>> > > > > parsed
>> >>> > parsed
>> >>> > > > > pretty much everywhere ;)
>> >>>
>> >>> > > > --
>> >>>
>> >>> > > > You received this message because you are subscribed to the
>> Google
>> >>> > Groups
>> >>> > > > "jQuery Development" group.
>> >>> > > > To post to this group, send email to
>> >>> > > > [hidden email]
>> .
>> >>> > > > To unsubscribe from this group, send email to
>> >>> > > > > >
>>
<[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>>
>> >>> > > > .
>> >>> > > > For more options, visit this group at
>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>> >>>
>> >>> > --
>> >>>
>> >>> > You received this message because you are subscribed to the Google
>> >>> > Groups
>> >>> > "jQuery Development" group.
>> >>> > To post to this group, send email to [hidden email].
>> >>> > To unsubscribe from this group, send email to
>> >>> >
>>
[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>> > .
>> >>> > For more options, visit this group at
>> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >> --
>> >>
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "jQuery Development" group.
>> >> To post to this group, send email to [hidden email].
>> >> To unsubscribe from this group, send email to
>> >>
[hidden email]<[hidden email]>
>> .
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >>
>> >>
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> > To post to this group, send email to [hidden email].
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<[hidden email]>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google
Groups
>> "jQuery Development" group.
>> To post to this group, send email to [hidden email].
>> To unsubscribe from this group, send email to
>>
[hidden email]<[hidden email]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.



--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

Rick Waldron
Actually, I think you are right in line with the rest of us.

Rick


On Mon, Dec 28, 2009 at 4:11 PM, Erik Beeson <[hidden email]> wrote:
Again, why not do this with an Accept header?

Client sends acceptable content types, server responds with a content type, if the server's response is one of the accepted types, jQuery processes accordingly, if not, jQuery returns data unprocessed.

The dataType option should be for things that aren't necessarily well communicated via content-type alone, like JSONP, or anything else that modifies the nature of the request, not just the content type.

If you're worried about your server sending malicious javascript, then only accept text/plain or text/xml (even dataType: 'html' isn't safe since it executes script blocks). If you don't care, then accept "*/*".

Or am I missing something?

--Erik


On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron <[hidden email]> wrote:
I can compromise with your #2, and give them both my vote.

Passing it on...


1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.




Julian - your thoughts?



On Mon, Dec 28, 2009 at 3:39 PM, webbiedave <[hidden email]> wrote:
Rick, your 1 (which I too have suggested in the past) might bring about
unease as folks would prefer any eval-ing to come through explicit request.
I also think it's imperative that the behavior of any dataType setting
(including null) shouldn't change (especially to one that suddenly evals!).
But that's just my opinion. My 1, 2 would be:

1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.



On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron <[hidden email]>
wrote:
>>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>
> Perhaps it would help if we defined a list of goals. I'll start.
>
> 1. $.ajax() - if dataType has not been defined in the argument list,
> $.ajax() should respect the returned Content-type header and translate
> accordingly.
>
> 2. ....
>
>
> Fill it in!
>
>
>
>
> Rick
>
>
>
>
>
> On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>>
>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson <[hidden email]>
>> wrote:
>> > Seems like a lot of awkward wheel reinventing going on here. Content
>> > type negotiation is a feature of HTTP; is there a reason we aren't
>> > using it?
>> >
>> > --Erik
>> >
>> >
>> > On Saturday, December 26, 2009, webbiedave
>> > <[hidden email]>
>> > wrote:
>> >> "Following your idea that a library has to keep exactly the same
>> >> behavior from versions to versions [...] then what happens if & when
>> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>> >>
>> >> Things could break *without* the introduction of new auto-detectable
>> >> types. If you use "auto" and are only handling json and html and
>> >> suddenly javascript is returned, that javascript will be eval'd and
>> >> things will will not turn out well. That's why you can't use "auto"
on
>> >> untrusted/incompetent servers. That's the whole point of "auto". You
>> >> are trusting the server to return the correct data. Use at your own
>> >> risk. But it's there if you need it.
>> >>
>> >> Having said that, #1 in my suggestions is passing an array (dataType:
>> >> ["json", html"]).
>> >>
>> >>
>> >>
>> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]> wrote:
>> >>> > As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml)
>> >>>
>> >>> This is exactly where the solution is inconsistent.
>> >>>
>> >>> "auto", in your implementation, does not mean "null plus more (json,
>> >>> script,
>> >>> *future accepted dataTypes*)" but it just means "null plus json &
>> >>> script"
>> >>> and only that. Following your idea that a library has to keep
exactly
>> >>> the
>> >>> same behavior from versions to versions (which jQuery broke btw when
>> >>> ditching the @ syntax for attributes in selectors) then what happens
>> >>> if
>> >>> &
>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You
>> >>> create
>> >>> an "auto2" dataType so that existing code running in 1.4 is
>> >>> unaffected
>> >>> (ie:
>> >>> the new dataType is not auto-detected)? How would you document such
a
>> >>> behaviour? What happens when there's another auto-detectable
dataType
>> >>> introduced in 1.4.2?
>> >>>
>> >>> Giving programmers a way to specify exactly the dataTypes they
expect
>> to
>> >>> be
>> >>> auto-detected is the way to go (would it be with an array or an
>> >>> expression).
>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code
and
>> >>> you're
>> >>> done: no backward compatibility issue... plus you're safe for future
>> >>> developments in the dataType auto-detection area.
>> >>>
>> >>> 2009/12/27 webbiedave <[hidden email]>
>> >>>
>> >>> > "Second, auto seems like the weirdest thing ever to me used like
it
>> is
>> >>> > here. So dataType==null and dataType=="auto" act the same for xml
>> >>> > but
>> >>> > not for script & json? Seems completely inconsistant to me."
>> >>>
>> >>> > It's not that weird. I don't think that different settings
yielding
>> >>> > different results is necessarily inconsistent. There are two ways
>> >>> > to
>> >>> > get xml and now there'll be a third. As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml). It is imperative that the behavior of dataType: null remains
>> the
>> >>> > same so this is a way to do that while affording multiple expected
>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't break
>> >>> > existing apps. Quite frankly, it usage makes simple sense to me
and
>> >>> > those who need it will know exactly what it means and how to use
it
>> >>> > (and will be relieved they can ditch their hacked libraries).
>> >>>
>> >>> > "If a coder does not want auto conversion, then he simply
specifies
>> >>> > a
>> >>> > dataType (namely "text")."
>> >>>
>> >>> > But null does not mean auto convert. It means guess between html
or
>> >>> > xml and that cannot change.
>> >>>
>> >>> > "But, please, do not introduce a behavior that will act
differently
>> >>> > for xml than it does for any other dataType deduced from content
>> >>> > type
>> >>> > headers."
>> >>>
>> >>> > I admit I don't share your fear of such behavior and, in fact,
>> greatly
>> >>> > desire such a new setting. I'll know that my live apps that are
>> >>> > using
>> >>> > dataType: null will be unaffected and in the future I'd be able to
>> >>> > write ajax calls that can respond to various data types. Also,
I've
>> >>> > suggested several approaches and look forward to reading what
>> >>> > others
>> >>> > think of them.
>> >>>
>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>> >>> > wrote:
>> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach as
>> >>> > > it's easy to use/implement and affords enough control.
>> >>>
>> >>> > > Well, so, first, I translated the dataType to "auto" when it was
>> >>> > > null/undefined in my rewriting (because I hate messy/undefined
>> >>> > > values).
>> >>> > But
>> >>> > > that's no biggy.
>> >>>
>> >>> > > Second, auto seems like the weirdest thing ever to me used like
>> >>> > > it
>> >>> > > is
>> >>> > here.
>> >>> > > So dataType==null and dataType=="auto" act the same for xml but
>> >>> > > not
>> >>> > > for
>> >>> > > script & json? Seems completely inconsistant to me.
>> >>>
>> >>> > > If a coder does not want auto conversion, then he simply
>> >>> > > specifies
>> a
>> >>> > > dataType (namely "text"). You just have to document it. But,
>> please,
>> >>> > > do
>> >>> > not
>> >>> > > introduce a behavior that will act differentely for xml than it
>> does
>> >>> > > for
>> >>> > any
>> >>> > > other dataType deduced from content type headers.
>> >>>
>> >>> > > 2009/12/26 webbiedave <[hidden email]>
>> >>>
>> >>> > > > I was referring solely to the "bitwise or" style. Regardless,
>> >>> > > > I'm
>> >>> > > > leaning towards the dataType: "auto" approach as it's easy to
>> use/
>> >>> > > > implement and affords enough control.
>> >>>
>> >>> > > > Julian Aubourg wrote:
>> >>>
>> >>> > > > > As for string expressions not being in the calling style of
>> >>> > > > > jQuery...
>> >>> > > > > well... I really disagree here, since jQuery has expression
>> >>> > > > > parsed
>> >>> > parsed
>> >>> > > > > pretty much everywhere ;)
>> >>>
>> >>> > > > --
>> >>>
>> >>> > > > You received this message because you are subscribed to the
>> Google
>> >>> > Groups
>> >>> > > > "jQuery Development" group.
>> >>> > > > To post to this group, send email to
>> >>> > > > [hidden email]
>> .
>> >>> > > > To unsubscribe from this group, send email to
>> >>> > > > > >
>>
<[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>>
>> >>> > > > .
>> >>> > > > For more options, visit this group at
>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>> >>>
>> >>> > --
>> >>>
>> >>> > You received this message because you are subscribed to the Google
>> >>> > Groups
>> >>> > "jQuery Development" group.
>> >>> > To post to this group, send email to [hidden email].
>> >>> > To unsubscribe from this group, send email to
>> >>> >
>>
[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>> > .
>> >>> > For more options, visit this group at
>> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >> --
>> >>
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "jQuery Development" group.
>> >> To post to this group, send email to [hidden email].
>> >> To unsubscribe from this group, send email to
>> >>
[hidden email]<[hidden email]>
>> .
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >>
>> >>
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> > To post to this group, send email to [hidden email].
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<[hidden email]>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google
Groups
>> "jQuery Development" group.
>> To post to this group, send email to [hidden email].
>> To unsubscribe from this group, send email to
>>
[hidden email]<[hidden email]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.



--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

webbiedave-2
In reply to this post by Erik Beeson
dataType does exactly what you're describing via one simple setting. It
sets accept headers for us and then translates the returned data for us,
all with a single word. That's what dataType is for. We want to continue to
use such a mechanism for easily handling such tasks.



On Mon, 28 Dec 2009 13:11:11 -0800, Erik Beeson <[hidden email]>
wrote:
> Again, why not do this with an Accept header?
>
> Client sends acceptable content types, server responds with a content
type,
> if the server's response is one of the accepted types, jQuery processes
> accordingly, if not, jQuery returns data unprocessed.
>
> The dataType option should be for things that aren't necessarily well
> communicated via content-type alone, like JSONP, or anything else that
> modifies the nature of the request, not just the content type.
>
> If you're worried about your server sending malicious javascript, then
only

> accept text/plain or text/xml (even dataType: 'html' isn't safe since it
> executes script blocks). If you don't care, then accept "*/*".
>
> Or am I missing something?
>
> --Erik
>
>
> On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron
> <[hidden email]>wrote:
>
>> I can compromise with your #2, and give them both my vote.
>>
>> Passing it on...
>>
>>
>> *1. Allow $.ajax() to accept multiple expected dataTypes.
>>
>> 2. Setting to have $.ajax() auto-detect/translate via response
>> content-type
>> header.*
>>
>>
>>
>> Julian - your thoughts?
>>
>>
>>
>> On Mon, Dec 28, 2009 at 3:39 PM, webbiedave
>> <[hidden email]>wrote:
>>
>>> Rick, your 1 (which I too have suggested in the past) might bring about
>>> unease as folks would prefer any eval-ing to come through explicit
>>> request.
>>> I also think it's imperative that the behavior of any dataType setting
>>> (including null) shouldn't change (especially to one that suddenly
>>> evals!).
>>> But that's just my opinion. My 1, 2 would be:
>>>
>>> 1. Allow $.ajax() to accept multiple expected dataTypes.
>>>
>>> 2. Setting to have $.ajax() auto-detect/translate via response
>>> content-type
>>> header.
>>>
>>>
>>>
>>> On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron
>>> <[hidden email]>
>>> wrote:
>>> >>
>>> >> We're struggling with the best way to inform .ajax() that we expect
>>> >> multiple data types. Either, with a setting like "auto" or by
passing
>>> an
>>> >> array of data types (or maybe allowing both).
>>> >>
>>> >
>>> > Perhaps it would help if we defined a list of goals. I'll start.
>>> >
>>> > 1. $.ajax() - if dataType has not been defined in the argument list,
>>> > $.ajax() should respect the returned Content-type header and
translate

>>> > accordingly.
>>> >
>>> > 2. ....
>>> >
>>> >
>>> > Fill it in!
>>> >
>>> >
>>> >
>>> >
>>> > Rick
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>>> >
>>> >> We're struggling with the best way to inform .ajax() that we expect
>>> >> multiple data types. Either, with a setting like "auto" or by
passing

>>> an
>>> >> array of data types (or maybe allowing both).
>>> >>
>>> >>
>>> >> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson
>>> >> <[hidden email]
>>> >
>>> >> wrote:
>>> >> > Seems like a lot of awkward wheel reinventing going on here.
>>> >> > Content
>>> >> > type negotiation is a feature of HTTP; is there a reason we aren't
>>> >> > using it?
>>> >> >
>>> >> > --Erik
>>> >> >
>>> >> >
>>> >> > On Saturday, December 26, 2009, webbiedave
>>> >> > <[hidden email]>
>>> >> > wrote:
>>> >> >> "Following your idea that a library has to keep exactly the same
>>> >> >> behavior from versions to versions [...] then what happens if &
>>> >> >> when
>>> >> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>>> >> >>
>>> >> >> Things could break *without* the introduction of new
>>> >> >> auto-detectable
>>> >> >> types. If you use "auto" and are only handling json and html and
>>> >> >> suddenly javascript is returned, that javascript will be eval'd
>>> >> >> and
>>> >> >> things will will not turn out well. That's why you can't use
>>> >> >> "auto"
>>> on
>>> >> >> untrusted/incompetent servers. That's the whole point of "auto".
>>> >> >> You
>>> >> >> are trusting the server to return the correct data. Use at your
>>> >> >> own
>>> >> >> risk. But it's there if you need it.
>>> >> >>
>>> >> >> Having said that, #1 in my suggestions is passing an array
>>> (dataType:
>>> >> >> ["json", html"]).
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]>
>>> wrote:
>>> >> >>> > As I mentioned in my previous
>>> >> >>> > post, one of this approach's downside is "null vs auto"
>>> >> >>> > confusion
>>> >> >>> > as
>>> >> >>> > auto is like null plus more (json, script, future accepted
>>> >> dataTypes).
>>> >> >>> > The whole point is that "auto" means auto-detect type via
>>> >> content-type
>>> >> >>> > headers and null does not mean that (it means guess between
>>> >> >>> > html
>>> or
>>> >> >>> > xml)
>>> >> >>>
>>> >> >>> This is exactly where the solution is inconsistent.
>>> >> >>>
>>> >> >>> "auto", in your implementation, does not mean "null plus more
>>> (json,
>>> >> >>> script,
>>> >> >>> *future accepted dataTypes*)" but it just means "null plus json
&

>>> >> >>> script"
>>> >> >>> and only that. Following your idea that a library has to keep
>>> exactly
>>> >> >>> the
>>> >> >>> same behavior from versions to versions (which jQuery broke btw
>>> when
>>> >> >>> ditching the @ syntax for attributes in selectors) then what
>>> happens
>>> >> >>> if
>>> >> >>> &
>>> >> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1?
>>> >> >>> You
>>> >> >>> create
>>> >> >>> an "auto2" dataType so that existing code running in 1.4 is
>>> >> >>> unaffected
>>> >> >>> (ie:
>>> >> >>> the new dataType is not auto-detected)? How would you document
>>> >> >>> such
>>> a
>>> >> >>> behaviour? What happens when there's another auto-detectable
>>> dataType
>>> >> >>> introduced in 1.4.2?
>>> >> >>>
>>> >> >>> Giving programmers a way to specify exactly the dataTypes they
>>> expect
>>> >> to
>>> >> >>> be
>>> >> >>> auto-detected is the way to go (would it be with an array or an
>>> >> >>> expression).
>>> >> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax
code

>>> and
>>> >> >>> you're
>>> >> >>> done: no backward compatibility issue... plus you're safe for
>>> future
>>> >> >>> developments in the dataType auto-detection area.
>>> >> >>>
>>> >> >>> 2009/12/27 webbiedave <[hidden email]>
>>> >> >>>
>>> >> >>> > "Second, auto seems like the weirdest thing ever to me used
>>> >> >>> > like
>>> it
>>> >> is
>>> >> >>> > here. So dataType==null and dataType=="auto" act the same for
>>> >> >>> > xml
>>> >> >>> > but
>>> >> >>> > not for script & json? Seems completely inconsistant to me."
>>> >> >>>
>>> >> >>> > It's not that weird. I don't think that different settings
>>> yielding
>>> >> >>> > different results is necessarily inconsistent. There are two
>>> >> >>> > ways
>>> >> >>> > to
>>> >> >>> > get xml and now there'll be a third. As I mentioned in my
>>> previous
>>> >> >>> > post, one of this approach's downside is "null vs auto"
>>> >> >>> > confusion
>>> >> >>> > as
>>> >> >>> > auto is like null plus more (json, script, future accepted
>>> >> dataTypes).
>>> >> >>> > The whole point is that "auto" means auto-detect type via
>>> >> content-type
>>> >> >>> > headers and null does not mean that (it means guess between
>>> >> >>> > html
>>> or
>>> >> >>> > xml). It is imperative that the behavior of dataType: null
>>> remains
>>> >> the
>>> >> >>> > same so this is a way to do that while affording multiple
>>> expected
>>> >> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't
>>> >> >>> > break
>>> >> >>> > existing apps. Quite frankly, it usage makes simple sense to
me

>>> and
>>> >> >>> > those who need it will know exactly what it means and how to
>>> >> >>> > use
>>> it
>>> >> >>> > (and will be relieved they can ditch their hacked libraries).
>>> >> >>>
>>> >> >>> > "If a coder does not want auto conversion, then he simply
>>> specifies
>>> >> >>> > a
>>> >> >>> > dataType (namely "text")."
>>> >> >>>
>>> >> >>> > But null does not mean auto convert. It means guess between
>>> >> >>> > html
>>> or
>>> >> >>> > xml and that cannot change.
>>> >> >>>
>>> >> >>> > "But, please, do not introduce a behavior that will act
>>> differently
>>> >> >>> > for xml than it does for any other dataType deduced from
>>> >> >>> > content
>>> >> >>> > type
>>> >> >>> > headers."
>>> >> >>>
>>> >> >>> > I admit I don't share your fear of such behavior and, in fact,
>>> >> greatly
>>> >> >>> > desire such a new setting. I'll know that my live apps that
are
>>> >> >>> > using
>>> >> >>> > dataType: null will be unaffected and in the future I'd be
able

>>> to
>>> >> >>> > write ajax calls that can respond to various data types. Also,
>>> I've
>>> >> >>> > suggested several approaches and look forward to reading what
>>> >> >>> > others
>>> >> >>> > think of them.
>>> >> >>>
>>> >> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>>> >> >>> > wrote:
>>> >> >>> > > Regardless, I'm leaning towards the dataType: "auto"
approach

>>> as
>>> >> >>> > > it's easy to use/implement and affords enough control.
>>> >> >>>
>>> >> >>> > > Well, so, first, I translated the dataType to "auto" when it
>>> was
>>> >> >>> > > null/undefined in my rewriting (because I hate
>>> >> >>> > > messy/undefined
>>> >> >>> > > values).
>>> >> >>> > But
>>> >> >>> > > that's no biggy.
>>> >> >>>
>>> >> >>> > > Second, auto seems like the weirdest thing ever to me used
>>> >> >>> > > like
>>> >> >>> > > it
>>> >> >>> > > is
>>> >> >>> > here.
>>> >> >>> > > So dataType==null and dataType=="auto" act the same for xml
>>> >> >>> > > but
>>> >> >>> > > not
>>> >> >>> > > for
>>> >> >>> > > script & json? Seems completely inconsistant to me.
>>> >> >>>
>>> >> >>> > > If a coder does not want auto conversion, then he simply
>>> >> >>> > > specifies
>>> >> a
>>> >> >>> > > dataType (namely "text"). You just have to document it. But,
>>> >> please,
>>> >> >>> > > do
>>> >> >>> > not
>>> >> >>> > > introduce a behavior that will act differentely for xml than
>>> >> >>> > > it
>>> >> does
>>> >> >>> > > for
>>> >> >>> > any
>>> >> >>> > > other dataType deduced from content type headers.
>>> >> >>>
>>> >> >>> > > 2009/12/26 webbiedave <[hidden email]>
>>> >> >>>
>>> >> >>> > > > I was referring solely to the "bitwise or" style.
>>> >> >>> > > > Regardless,
>>> >> >>> > > > I'm
>>> >> >>> > > > leaning towards the dataType: "auto" approach as it's easy
>>> >> >>> > > > to
>>> >> use/
>>> >> >>> > > > implement and affords enough control.
>>> >> >>>
>>> >> >>> > > > Julian Aubourg wrote:
>>> >> >>>
>>> >> >>> > > > > As for string expressions not being in the calling style
>>> >> >>> > > > > of
>>> >> >>> > > > > jQuery...
>>> >> >>> > > > > well... I really disagree here, since jQuery has
>>> >> >>> > > > > expression
>>> >> >>> > > > > parsed
>>> >> >>> > parsed
>>> >> >>> > > > > pretty much everywhere ;)
>>> >> >>>
>>> >> >>> > > > --
>>> >> >>>
>>> >> >>> > > > You received this message because you are subscribed to
the

>>> >> Google
>>> >> >>> > Groups
>>> >> >>> > > > "jQuery Development" group.
>>> >> >>> > > > To post to this group, send email to
>>> >> >>> > > > [hidden email]
>>> >> .
>>> >> >>> > > > To unsubscribe from this group, send email to
>>> >> >>> > > > > >
>>> >>
>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>> >
>>> >>
>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>>> >
>>> >> >
>>> >> >>>
>>> >> >>> > > > .
>>> >> >>> > > > For more options, visit this group at
>>> >> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>>> >> >>>
>>> >> >>> > --
>>> >> >>>
>>> >> >>> > You received this message because you are subscribed to the
>>> Google
>>> >> >>> > Groups
>>> >> >>> > "jQuery Development" group.
>>> >> >>> > To post to this group, send email to
>>> >> >>> > [hidden email]
>>> .
>>> >> >>> > To unsubscribe from this group, send email to
>>> >> >>> >
>>> >>
>>>
[hidden email]<jquery-dev%[hidden email]>
>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>> >
>>> >>
>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>> >
>>> >> >
>>> >> >>> > .
>>> >> >>> > For more options, visit this group at
>>> >> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>>> >> >>
>>> >> >> --
>>> >> >>
>>> >> >> You received this message because you are subscribed to the
Google
>>> >> Groups
>>> >> >> "jQuery Development" group.
>>> >> >> To post to this group, send email to [hidden email].
>>> >> >> To unsubscribe from this group, send email to
>>> >> >>
>>>
[hidden email]<jquery-dev%[hidden email]>
>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>>> >
>>> >> .
>>> >> >> For more options, visit this group at
>>> >> >> http://groups.google.com/group/jquery-dev?hl=en.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >
>>> >> > --
>>> >> >
>>> >> > You received this message because you are subscribed to the Google
>>> >> > Groups
>>> >> > "jQuery Development" group.
>>> >> > To post to this group, send email to [hidden email].
>>> >> > To unsubscribe from this group, send email to
>>> >> >
>>>
[hidden email]<jquery-dev%[hidden email]>
>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>>> >
>>> >> .
>>> >> > For more options, visit this group at
>>> >> > http://groups.google.com/group/jquery-dev?hl=en.
>>> >>
>>> >> --
>>> >>
>>> >> You received this message because you are subscribed to the Google
>>> Groups
>>> >> "jQuery Development" group.
>>> >> To post to this group, send email to [hidden email].
>>> >> To unsubscribe from this group, send email to
>>> >>
>>>
[hidden email]<jquery-dev%[hidden email]>
>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>>> >
>>> >> .
>>> >> For more options, visit this group at
>>> >> http://groups.google.com/group/jquery-dev?hl=en.
>>> >>
>>> >>
>>> >>
>>> >
>>> > --
>>> >
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "jQuery Development" group.
>>> > To post to this group, send email to [hidden email].
>>> > To unsubscribe from this group, send email to
>>> >
[hidden email]<jquery-dev%[hidden email]>

>>> .
>>> > For more options, visit this group at
>>> > http://groups.google.com/group/jquery-dev?hl=en.
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "jQuery Development" group.
>>> To post to this group, send email to [hidden email].
>>> To unsubscribe from this group, send email to
>>>
[hidden email]<jquery-dev%[hidden email]>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/jquery-dev?hl=en.
>>>
>>>
>>>
>>  --
>> You received this message because you are subscribed to the Google
Groups
>> "jQuery Development" group.
>> To post to this group, send email to [hidden email].
>> To unsubscribe from this group, send email to
>>
[hidden email]<jquery-dev%[hidden email]>

>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

jaubourg
In reply to this post by Erik Beeson
Again, why not do this with an Accept header?

Client sends acceptable content types, server responds with a content type, if the server's response is one of the accepted types, jQuery processes accordingly, if not, jQuery returns data unprocessed.

The dataType option should be for things that aren't necessarily well communicated via content-type alone, like JSONP, or anything else that modifies the nature of the request, not just the content type.

If you're worried about your server sending malicious javascript, then only accept text/plain or text/xml (even dataType: 'html' isn't safe since it executes script blocks). If you don't care, then accept "*/*".


There are a couple of reasons why an accept / content-type system is not that simple:
1) When not specifying a dataType, accept is */* (which makes sense since we don't expect a particular dataType) while current behaviour is to autodetect xml against text (or, maybe, in future extensions, to autodetect any type). The only workaround if you're basing your tests around the accept header would be to associate all of the xx/yy possibilities known to men with their corresponding dataType. The behaviour, as it is now, is to group correspondance from content-type to dataType using simple regexps (ie /xml/, /json/) which I find much more efficient and not too configuration heavy.
2) It still doesn't address the issue of specifying a set of accepted dataTypes just with the dataType property (which is a much better abstraction than setting content-type headers in a beforeSend callback or globally adding accepted types in ajaxSettings).

I'm beginning to wonder if we're not buzzing for nothing with this conversation. Actually, not specifying a dataType could very well behave as a guess-anything system. In analogy to what you said with content-type, setting a dataType will prevent any automatic decision, so existing code that would be impacted by automatic json evaluation would just have to add the dataType option, something I don't see as such an atrocious maintenance task it would require some heavy-weight system in jQuery.

So, the more I think about it, the more I'm in favor of #1.

2009/12/28 Erik Beeson <[hidden email]>
Again, why not do this with an Accept header?

Client sends acceptable content types, server responds with a content type, if the server's response is one of the accepted types, jQuery processes accordingly, if not, jQuery returns data unprocessed.

The dataType option should be for things that aren't necessarily well communicated via content-type alone, like JSONP, or anything else that modifies the nature of the request, not just the content type.

If you're worried about your server sending malicious javascript, then only accept text/plain or text/xml (even dataType: 'html' isn't safe since it executes script blocks). If you don't care, then accept "*/*".

Or am I missing something?

--Erik


On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron <[hidden email]> wrote:
I can compromise with your #2, and give them both my vote.

Passing it on...


1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.




Julian - your thoughts?



On Mon, Dec 28, 2009 at 3:39 PM, webbiedave <[hidden email]> wrote:
Rick, your 1 (which I too have suggested in the past) might bring about
unease as folks would prefer any eval-ing to come through explicit request.
I also think it's imperative that the behavior of any dataType setting
(including null) shouldn't change (especially to one that suddenly evals!).
But that's just my opinion. My 1, 2 would be:

1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.



On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron <[hidden email]>
wrote:
>>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>
> Perhaps it would help if we defined a list of goals. I'll start.
>
> 1. $.ajax() - if dataType has not been defined in the argument list,
> $.ajax() should respect the returned Content-type header and translate
> accordingly.
>
> 2. ....
>
>
> Fill it in!
>
>
>
>
> Rick
>
>
>
>
>
> On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>>
>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson <[hidden email]>
>> wrote:
>> > Seems like a lot of awkward wheel reinventing going on here. Content
>> > type negotiation is a feature of HTTP; is there a reason we aren't
>> > using it?
>> >
>> > --Erik
>> >
>> >
>> > On Saturday, December 26, 2009, webbiedave
>> > <[hidden email]>
>> > wrote:
>> >> "Following your idea that a library has to keep exactly the same
>> >> behavior from versions to versions [...] then what happens if & when
>> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>> >>
>> >> Things could break *without* the introduction of new auto-detectable
>> >> types. If you use "auto" and are only handling json and html and
>> >> suddenly javascript is returned, that javascript will be eval'd and
>> >> things will will not turn out well. That's why you can't use "auto"
on
>> >> untrusted/incompetent servers. That's the whole point of "auto". You
>> >> are trusting the server to return the correct data. Use at your own
>> >> risk. But it's there if you need it.
>> >>
>> >> Having said that, #1 in my suggestions is passing an array (dataType:
>> >> ["json", html"]).
>> >>
>> >>
>> >>
>> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]> wrote:
>> >>> > As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml)
>> >>>
>> >>> This is exactly where the solution is inconsistent.
>> >>>
>> >>> "auto", in your implementation, does not mean "null plus more (json,
>> >>> script,
>> >>> *future accepted dataTypes*)" but it just means "null plus json &
>> >>> script"
>> >>> and only that. Following your idea that a library has to keep
exactly
>> >>> the
>> >>> same behavior from versions to versions (which jQuery broke btw when
>> >>> ditching the @ syntax for attributes in selectors) then what happens
>> >>> if
>> >>> &
>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You
>> >>> create
>> >>> an "auto2" dataType so that existing code running in 1.4 is
>> >>> unaffected
>> >>> (ie:
>> >>> the new dataType is not auto-detected)? How would you document such
a
>> >>> behaviour? What happens when there's another auto-detectable
dataType
>> >>> introduced in 1.4.2?
>> >>>
>> >>> Giving programmers a way to specify exactly the dataTypes they
expect
>> to
>> >>> be
>> >>> auto-detected is the way to go (would it be with an array or an
>> >>> expression).
>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code
and
>> >>> you're
>> >>> done: no backward compatibility issue... plus you're safe for future
>> >>> developments in the dataType auto-detection area.
>> >>>
>> >>> 2009/12/27 webbiedave <[hidden email]>
>> >>>
>> >>> > "Second, auto seems like the weirdest thing ever to me used like
it
>> is
>> >>> > here. So dataType==null and dataType=="auto" act the same for xml
>> >>> > but
>> >>> > not for script & json? Seems completely inconsistant to me."
>> >>>
>> >>> > It's not that weird. I don't think that different settings
yielding
>> >>> > different results is necessarily inconsistent. There are two ways
>> >>> > to
>> >>> > get xml and now there'll be a third. As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml). It is imperative that the behavior of dataType: null remains
>> the
>> >>> > same so this is a way to do that while affording multiple expected
>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't break
>> >>> > existing apps. Quite frankly, it usage makes simple sense to me
and
>> >>> > those who need it will know exactly what it means and how to use
it
>> >>> > (and will be relieved they can ditch their hacked libraries).
>> >>>
>> >>> > "If a coder does not want auto conversion, then he simply
specifies
>> >>> > a
>> >>> > dataType (namely "text")."
>> >>>
>> >>> > But null does not mean auto convert. It means guess between html
or
>> >>> > xml and that cannot change.
>> >>>
>> >>> > "But, please, do not introduce a behavior that will act
differently
>> >>> > for xml than it does for any other dataType deduced from content
>> >>> > type
>> >>> > headers."
>> >>>
>> >>> > I admit I don't share your fear of such behavior and, in fact,
>> greatly
>> >>> > desire such a new setting. I'll know that my live apps that are
>> >>> > using
>> >>> > dataType: null will be unaffected and in the future I'd be able to
>> >>> > write ajax calls that can respond to various data types. Also,
I've
>> >>> > suggested several approaches and look forward to reading what
>> >>> > others
>> >>> > think of them.
>> >>>
>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>> >>> > wrote:
>> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach as
>> >>> > > it's easy to use/implement and affords enough control.
>> >>>
>> >>> > > Well, so, first, I translated the dataType to "auto" when it was
>> >>> > > null/undefined in my rewriting (because I hate messy/undefined
>> >>> > > values).
>> >>> > But
>> >>> > > that's no biggy.
>> >>>
>> >>> > > Second, auto seems like the weirdest thing ever to me used like
>> >>> > > it
>> >>> > > is
>> >>> > here.
>> >>> > > So dataType==null and dataType=="auto" act the same for xml but
>> >>> > > not
>> >>> > > for
>> >>> > > script & json? Seems completely inconsistant to me.
>> >>>
>> >>> > > If a coder does not want auto conversion, then he simply
>> >>> > > specifies
>> a
>> >>> > > dataType (namely "text"). You just have to document it. But,
>> please,
>> >>> > > do
>> >>> > not
>> >>> > > introduce a behavior that will act differentely for xml than it
>> does
>> >>> > > for
>> >>> > any
>> >>> > > other dataType deduced from content type headers.
>> >>>
>> >>> > > 2009/12/26 webbiedave <[hidden email]>
>> >>>
>> >>> > > > I was referring solely to the "bitwise or" style. Regardless,
>> >>> > > > I'm
>> >>> > > > leaning towards the dataType: "auto" approach as it's easy to
>> use/
>> >>> > > > implement and affords enough control.
>> >>>
>> >>> > > > Julian Aubourg wrote:
>> >>>
>> >>> > > > > As for string expressions not being in the calling style of
>> >>> > > > > jQuery...
>> >>> > > > > well... I really disagree here, since jQuery has expression
>> >>> > > > > parsed
>> >>> > parsed
>> >>> > > > > pretty much everywhere ;)
>> >>>
>> >>> > > > --
>> >>>
>> >>> > > > You received this message because you are subscribed to the
>> Google
>> >>> > Groups
>> >>> > > > "jQuery Development" group.
>> >>> > > > To post to this group, send email to
>> >>> > > > [hidden email]
>> .
>> >>> > > > To unsubscribe from this group, send email to
>> >>> > > > > >
>>
<[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>>
>> >>> > > > .
>> >>> > > > For more options, visit this group at
>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>> >>>
>> >>> > --
>> >>>
>> >>> > You received this message because you are subscribed to the Google
>> >>> > Groups
>> >>> > "jQuery Development" group.
>> >>> > To post to this group, send email to [hidden email].
>> >>> > To unsubscribe from this group, send email to
>> >>> >
>>
[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>> > .
>> >>> > For more options, visit this group at
>> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >> --
>> >>
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "jQuery Development" group.
>> >> To post to this group, send email to [hidden email].
>> >> To unsubscribe from this group, send email to
>> >>
[hidden email]<[hidden email]>
>> .
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >>
>> >>
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> > To post to this group, send email to [hidden email].
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<[hidden email]>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google
Groups
>> "jQuery Development" group.
>> To post to this group, send email to [hidden email].
>> To unsubscribe from this group, send email to
>>
[hidden email]<[hidden email]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.



--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

jaubourg
So it was pure #2 obviously, not #1.

2009/12/29 Julian Aubourg <[hidden email]>
Again, why not do this with an Accept header?

Client sends acceptable content types, server responds with a content type, if the server's response is one of the accepted types, jQuery processes accordingly, if not, jQuery returns data unprocessed.

The dataType option should be for things that aren't necessarily well communicated via content-type alone, like JSONP, or anything else that modifies the nature of the request, not just the content type.

If you're worried about your server sending malicious javascript, then only accept text/plain or text/xml (even dataType: 'html' isn't safe since it executes script blocks). If you don't care, then accept "*/*".


There are a couple of reasons why an accept / content-type system is not that simple:
1) When not specifying a dataType, accept is */* (which makes sense since we don't expect a particular dataType) while current behaviour is to autodetect xml against text (or, maybe, in future extensions, to autodetect any type). The only workaround if you're basing your tests around the accept header would be to associate all of the xx/yy possibilities known to men with their corresponding dataType. The behaviour, as it is now, is to group correspondance from content-type to dataType using simple regexps (ie /xml/, /json/) which I find much more efficient and not too configuration heavy.
2) It still doesn't address the issue of specifying a set of accepted dataTypes just with the dataType property (which is a much better abstraction than setting content-type headers in a beforeSend callback or globally adding accepted types in ajaxSettings).

I'm beginning to wonder if we're not buzzing for nothing with this conversation. Actually, not specifying a dataType could very well behave as a guess-anything system. In analogy to what you said with content-type, setting a dataType will prevent any automatic decision, so existing code that would be impacted by automatic json evaluation would just have to add the dataType option, something I don't see as such an atrocious maintenance task it would require some heavy-weight system in jQuery.

So, the more I think about it, the more I'm in favor of #1.

2009/12/28 Erik Beeson <[hidden email]>

Again, why not do this with an Accept header?

Client sends acceptable content types, server responds with a content type, if the server's response is one of the accepted types, jQuery processes accordingly, if not, jQuery returns data unprocessed.

The dataType option should be for things that aren't necessarily well communicated via content-type alone, like JSONP, or anything else that modifies the nature of the request, not just the content type.

If you're worried about your server sending malicious javascript, then only accept text/plain or text/xml (even dataType: 'html' isn't safe since it executes script blocks). If you don't care, then accept "*/*".

Or am I missing something?

--Erik


On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron <[hidden email]> wrote:
I can compromise with your #2, and give them both my vote.

Passing it on...


1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.




Julian - your thoughts?



On Mon, Dec 28, 2009 at 3:39 PM, webbiedave <[hidden email]> wrote:
Rick, your 1 (which I too have suggested in the past) might bring about
unease as folks would prefer any eval-ing to come through explicit request.
I also think it's imperative that the behavior of any dataType setting
(including null) shouldn't change (especially to one that suddenly evals!).
But that's just my opinion. My 1, 2 would be:

1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.



On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron <[hidden email]>
wrote:
>>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>
> Perhaps it would help if we defined a list of goals. I'll start.
>
> 1. $.ajax() - if dataType has not been defined in the argument list,
> $.ajax() should respect the returned Content-type header and translate
> accordingly.
>
> 2. ....
>
>
> Fill it in!
>
>
>
>
> Rick
>
>
>
>
>
> On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>>
>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson <[hidden email]>
>> wrote:
>> > Seems like a lot of awkward wheel reinventing going on here. Content
>> > type negotiation is a feature of HTTP; is there a reason we aren't
>> > using it?
>> >
>> > --Erik
>> >
>> >
>> > On Saturday, December 26, 2009, webbiedave
>> > <[hidden email]>
>> > wrote:
>> >> "Following your idea that a library has to keep exactly the same
>> >> behavior from versions to versions [...] then what happens if & when
>> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>> >>
>> >> Things could break *without* the introduction of new auto-detectable
>> >> types. If you use "auto" and are only handling json and html and
>> >> suddenly javascript is returned, that javascript will be eval'd and
>> >> things will will not turn out well. That's why you can't use "auto"
on
>> >> untrusted/incompetent servers. That's the whole point of "auto". You
>> >> are trusting the server to return the correct data. Use at your own
>> >> risk. But it's there if you need it.
>> >>
>> >> Having said that, #1 in my suggestions is passing an array (dataType:
>> >> ["json", html"]).
>> >>
>> >>
>> >>
>> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]> wrote:
>> >>> > As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml)
>> >>>
>> >>> This is exactly where the solution is inconsistent.
>> >>>
>> >>> "auto", in your implementation, does not mean "null plus more (json,
>> >>> script,
>> >>> *future accepted dataTypes*)" but it just means "null plus json &
>> >>> script"
>> >>> and only that. Following your idea that a library has to keep
exactly
>> >>> the
>> >>> same behavior from versions to versions (which jQuery broke btw when
>> >>> ditching the @ syntax for attributes in selectors) then what happens
>> >>> if
>> >>> &
>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You
>> >>> create
>> >>> an "auto2" dataType so that existing code running in 1.4 is
>> >>> unaffected
>> >>> (ie:
>> >>> the new dataType is not auto-detected)? How would you document such
a
>> >>> behaviour? What happens when there's another auto-detectable
dataType
>> >>> introduced in 1.4.2?
>> >>>
>> >>> Giving programmers a way to specify exactly the dataTypes they
expect
>> to
>> >>> be
>> >>> auto-detected is the way to go (would it be with an array or an
>> >>> expression).
>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code
and
>> >>> you're
>> >>> done: no backward compatibility issue... plus you're safe for future
>> >>> developments in the dataType auto-detection area.
>> >>>
>> >>> 2009/12/27 webbiedave <[hidden email]>
>> >>>
>> >>> > "Second, auto seems like the weirdest thing ever to me used like
it
>> is
>> >>> > here. So dataType==null and dataType=="auto" act the same for xml
>> >>> > but
>> >>> > not for script & json? Seems completely inconsistant to me."
>> >>>
>> >>> > It's not that weird. I don't think that different settings
yielding
>> >>> > different results is necessarily inconsistent. There are two ways
>> >>> > to
>> >>> > get xml and now there'll be a third. As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml). It is imperative that the behavior of dataType: null remains
>> the
>> >>> > same so this is a way to do that while affording multiple expected
>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't break
>> >>> > existing apps. Quite frankly, it usage makes simple sense to me
and
>> >>> > those who need it will know exactly what it means and how to use
it
>> >>> > (and will be relieved they can ditch their hacked libraries).
>> >>>
>> >>> > "If a coder does not want auto conversion, then he simply
specifies
>> >>> > a
>> >>> > dataType (namely "text")."
>> >>>
>> >>> > But null does not mean auto convert. It means guess between html
or
>> >>> > xml and that cannot change.
>> >>>
>> >>> > "But, please, do not introduce a behavior that will act
differently
>> >>> > for xml than it does for any other dataType deduced from content
>> >>> > type
>> >>> > headers."
>> >>>
>> >>> > I admit I don't share your fear of such behavior and, in fact,
>> greatly
>> >>> > desire such a new setting. I'll know that my live apps that are
>> >>> > using
>> >>> > dataType: null will be unaffected and in the future I'd be able to
>> >>> > write ajax calls that can respond to various data types. Also,
I've
>> >>> > suggested several approaches and look forward to reading what
>> >>> > others
>> >>> > think of them.
>> >>>
>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>> >>> > wrote:
>> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach as
>> >>> > > it's easy to use/implement and affords enough control.
>> >>>
>> >>> > > Well, so, first, I translated the dataType to "auto" when it was
>> >>> > > null/undefined in my rewriting (because I hate messy/undefined
>> >>> > > values).
>> >>> > But
>> >>> > > that's no biggy.
>> >>>
>> >>> > > Second, auto seems like the weirdest thing ever to me used like
>> >>> > > it
>> >>> > > is
>> >>> > here.
>> >>> > > So dataType==null and dataType=="auto" act the same for xml but
>> >>> > > not
>> >>> > > for
>> >>> > > script & json? Seems completely inconsistant to me.
>> >>>
>> >>> > > If a coder does not want auto conversion, then he simply
>> >>> > > specifies
>> a
>> >>> > > dataType (namely "text"). You just have to document it. But,
>> please,
>> >>> > > do
>> >>> > not
>> >>> > > introduce a behavior that will act differentely for xml than it
>> does
>> >>> > > for
>> >>> > any
>> >>> > > other dataType deduced from content type headers.
>> >>>
>> >>> > > 2009/12/26 webbiedave <[hidden email]>
>> >>>
>> >>> > > > I was referring solely to the "bitwise or" style. Regardless,
>> >>> > > > I'm
>> >>> > > > leaning towards the dataType: "auto" approach as it's easy to
>> use/
>> >>> > > > implement and affords enough control.
>> >>>
>> >>> > > > Julian Aubourg wrote:
>> >>>
>> >>> > > > > As for string expressions not being in the calling style of
>> >>> > > > > jQuery...
>> >>> > > > > well... I really disagree here, since jQuery has expression
>> >>> > > > > parsed
>> >>> > parsed
>> >>> > > > > pretty much everywhere ;)
>> >>>
>> >>> > > > --
>> >>>
>> >>> > > > You received this message because you are subscribed to the
>> Google
>> >>> > Groups
>> >>> > > > "jQuery Development" group.
>> >>> > > > To post to this group, send email to
>> >>> > > > [hidden email]
>> .
>> >>> > > > To unsubscribe from this group, send email to
>> >>> > > > > >
>>
<[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>>
>> >>> > > > .
>> >>> > > > For more options, visit this group at
>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>> >>>
>> >>> > --
>> >>>
>> >>> > You received this message because you are subscribed to the Google
>> >>> > Groups
>> >>> > "jQuery Development" group.
>> >>> > To post to this group, send email to [hidden email].
>> >>> > To unsubscribe from this group, send email to
>> >>> >
>>
[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>> > .
>> >>> > For more options, visit this group at
>> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >> --
>> >>
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "jQuery Development" group.
>> >> To post to this group, send email to [hidden email].
>> >> To unsubscribe from this group, send email to
>> >>
[hidden email]<[hidden email]>
>> .
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >>
>> >>
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> > To post to this group, send email to [hidden email].
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<[hidden email]>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google
Groups
>> "jQuery Development" group.
>> To post to this group, send email to [hidden email].
>> To unsubscribe from this group, send email to
>>
[hidden email]<[hidden email]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.



--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

Rick Waldron
This is good. #2 has solid support.

John, care to chime in this?



-- Sent from my Palm Prē


Julian Aubourg wrote:

So it was pure #2 obviously, not #1.

2009/12/29 Julian Aubourg <[hidden email]>
Again, why not do this with an Accept header?

Client sends acceptable content types, server responds with a content type, if the server's response is one of the accepted types, jQuery processes accordingly, if not, jQuery returns data unprocessed.

The dataType option should be for things that aren't necessarily well communicated via content-type alone, like JSONP, or anything else that modifies the nature of the request, not just the content type.

If you're worried about your server sending malicious javascript, then only accept text/plain or text/xml (even dataType: 'html' isn't safe since it executes script blocks). If you don't care, then accept "*/*".


There are a couple of reasons why an accept / content-type system is not that simple:
1) When not specifying a dataType, accept is */* (which makes sense since we don't expect a particular dataType) while current behaviour is to autodetect xml against text (or, maybe, in future extensions, to autodetect any type). The only workaround if you're basing your tests around the accept header would be to associate all of the xx/yy possibilities known to men with their corresponding dataType. The behaviour, as it is now, is to group correspondance from content-type to dataType using simple regexps (ie /xml/, /json/) which I find much more efficient and not too configuration heavy.
2) It still doesn't address the issue of specifying a set of accepted dataTypes just with the dataType property (which is a much better abstraction than setting content-type headers in a beforeSend callback or globally adding accepted types in ajaxSettings).

I'm beginning to wonder if we're not buzzing for nothing with this conversation. Actually, not specifying a dataType could very well behave as a guess-anything system. In analogy to what you said with content-type, setting a dataType will prevent any automatic decision, so existing code that would be impacted by automatic json evaluation would just have to add the dataType option, something I don't see as such an atrocious maintenance task it would require some heavy-weight system in jQuery.

So, the more I think about it, the more I'm in favor of #1.

2009/12/28 Erik Beeson <[hidden email]>

Again, why not do this with an Accept header?

Client sends acceptable content types, server responds with a content type, if the server's response is one of the accepted types, jQuery processes accordingly, if not, jQuery returns data unprocessed.

The dataType option should be for things that aren't necessarily well communicated via content-type alone, like JSONP, or anything else that modifies the nature of the request, not just the content type.

If you're worried about your server sending malicious javascript, then only accept text/plain or text/xml (even dataType: 'html' isn't safe since it executes script blocks). If you don't care, then accept "*/*".

Or am I missing something?

--Erik


On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron <[hidden email]> wrote:
I can compromise with your #2, and give them both my vote.

Passing it on...


1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.




Julian - your thoughts?



On Mon, Dec 28, 2009 at 3:39 PM, webbiedave <[hidden email]> wrote:
Rick, your 1 (which I too have suggested in the past) might bring about
unease as folks would prefer any eval-ing to come through explicit request.
I also think it's imperative that the behavior of any dataType setting
(including null) shouldn't change (especially to one that suddenly evals!).
But that's just my opinion. My 1, 2 would be:

1. Allow $.ajax() to accept multiple expected dataTypes.

2. Setting to have $.ajax() auto-detect/translate via response content-type
header.



On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron <[hidden email]>
wrote:
>>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>
> Perhaps it would help if we defined a list of goals. I'll start.
>
> 1. $.ajax() - if dataType has not been defined in the argument list,
> $.ajax() should respect the returned Content-type header and translate
> accordingly.
>
> 2. ....
>
>
> Fill it in!
>
>
>
>
> Rick
>
>
>
>
>
> On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>
>> We're struggling with the best way to inform .ajax() that we expect
>> multiple data types. Either, with a setting like "auto" or by passing an
>> array of data types (or maybe allowing both).
>>
>>
>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson <[hidden email]>
>> wrote:
>> > Seems like a lot of awkward wheel reinventing going on here. Content
>> > type negotiation is a feature of HTTP; is there a reason we aren't
>> > using it?
>> >
>> > --Erik
>> >
>> >
>> > On Saturday, December 26, 2009, webbiedave
>> > <[hidden email]>
>> > wrote:
>> >> "Following your idea that a library has to keep exactly the same
>> >> behavior from versions to versions [...] then what happens if & when
>> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>> >>
>> >> Things could break *without* the introduction of new auto-detectable
>> >> types. If you use "auto" and are only handling json and html and
>> >> suddenly javascript is returned, that javascript will be eval'd and
>> >> things will will not turn out well. That's why you can't use "auto"
on
>> >> untrusted/incompetent servers. That's the whole point of "auto". You
>> >> are trusting the server to return the correct data. Use at your own
>> >> risk. But it's there if you need it.
>> >>
>> >> Having said that, #1 in my suggestions is passing an array (dataType:
>> >> ["json", html"]).
>> >>
>> >>
>> >>
>> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]> wrote:
>> >>> > As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml)
>> >>>
>> >>> This is exactly where the solution is inconsistent.
>> >>>
>> >>> "auto", in your implementation, does not mean "null plus more (json,
>> >>> script,
>> >>> *future accepted dataTypes*)" but it just means "null plus json &
>> >>> script"
>> >>> and only that. Following your idea that a library has to keep
exactly
>> >>> the
>> >>> same behavior from versions to versions (which jQuery broke btw when
>> >>> ditching the @ syntax for attributes in selectors) then what happens
>> >>> if
>> >>> &
>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You
>> >>> create
>> >>> an "auto2" dataType so that existing code running in 1.4 is
>> >>> unaffected
>> >>> (ie:
>> >>> the new dataType is not auto-detected)? How would you document such
a
>> >>> behaviour? What happens when there's another auto-detectable
dataType
>> >>> introduced in 1.4.2?
>> >>>
>> >>> Giving programmers a way to specify exactly the dataTypes they
expect
>> to
>> >>> be
>> >>> auto-detected is the way to go (would it be with an array or an
>> >>> expression).
>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code
and
>> >>> you're
>> >>> done: no backward compatibility issue... plus you're safe for future
>> >>> developments in the dataType auto-detection area.
>> >>>
>> >>> 2009/12/27 webbiedave <[hidden email]>
>> >>>
>> >>> > "Second, auto seems like the weirdest thing ever to me used like
it
>> is
>> >>> > here. So dataType==null and dataType=="auto" act the same for xml
>> >>> > but
>> >>> > not for script & json? Seems completely inconsistant to me."
>> >>>
>> >>> > It's not that weird. I don't think that different settings
yielding
>> >>> > different results is necessarily inconsistent. There are two ways
>> >>> > to
>> >>> > get xml and now there'll be a third. As I mentioned in my previous
>> >>> > post, one of this approach's downside is "null vs auto" confusion
>> >>> > as
>> >>> > auto is like null plus more (json, script, future accepted
>> dataTypes).
>> >>> > The whole point is that "auto" means auto-detect type via
>> content-type
>> >>> > headers and null does not mean that (it means guess between html
or
>> >>> > xml). It is imperative that the behavior of dataType: null remains
>> the
>> >>> > same so this is a way to do that while affording multiple expected
>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't break
>> >>> > existing apps. Quite frankly, it usage makes simple sense to me
and
>> >>> > those who need it will know exactly what it means and how to use
it
>> >>> > (and will be relieved they can ditch their hacked libraries).
>> >>>
>> >>> > "If a coder does not want auto conversion, then he simply
specifies
>> >>> > a
>> >>> > dataType (namely "text")."
>> >>>
>> >>> > But null does not mean auto convert. It means guess between html
or
>> >>> > xml and that cannot change.
>> >>>
>> >>> > "But, please, do not introduce a behavior that will act
differently
>> >>> > for xml than it does for any other dataType deduced from content
>> >>> > type
>> >>> > headers."
>> >>>
>> >>> > I admit I don't share your fear of such behavior and, in fact,
>> greatly
>> >>> > desire such a new setting. I'll know that my live apps that are
>> >>> > using
>> >>> > dataType: null will be unaffected and in the future I'd be able to
>> >>> > write ajax calls that can respond to various data types. Also,
I've
>> >>> > suggested several approaches and look forward to reading what
>> >>> > others
>> >>> > think of them.
>> >>>
>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>> >>> > wrote:
>> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach as
>> >>> > > it's easy to use/implement and affords enough control.
>> >>>
>> >>> > > Well, so, first, I translated the dataType to "auto" when it was
>> >>> > > null/undefined in my rewriting (because I hate messy/undefined
>> >>> > > values).
>> >>> > But
>> >>> > > that's no biggy.
>> >>>
>> >>> > > Second, auto seems like the weirdest thing ever to me used like
>> >>> > > it
>> >>> > > is
>> >>> > here.
>> >>> > > So dataType==null and dataType=="auto" act the same for xml but
>> >>> > > not
>> >>> > > for
>> >>> > > script & json? Seems completely inconsistant to me.
>> >>>
>> >>> > > If a coder does not want auto conversion, then he simply
>> >>> > > specifies
>> a
>> >>> > > dataType (namely "text"). You just have to document it. But,
>> please,
>> >>> > > do
>> >>> > not
>> >>> > > introduce a behavior that will act differentely for xml than it
>> does
>> >>> > > for
>> >>> > any
>> >>> > > other dataType deduced from content type headers.
>> >>>
>> >>> > > 2009/12/26 webbiedave <[hidden email]>
>> >>>
>> >>> > > > I was referring solely to the "bitwise or" style. Regardless,
>> >>> > > > I'm
>> >>> > > > leaning towards the dataType: "auto" approach as it's easy to
>> use/
>> >>> > > > implement and affords enough control.
>> >>>
>> >>> > > > Julian Aubourg wrote:
>> >>>
>> >>> > > > > As for string expressions not being in the calling style of
>> >>> > > > > jQuery...
>> >>> > > > > well... I really disagree here, since jQuery has expression
>> >>> > > > > parsed
>> >>> > parsed
>> >>> > > > > pretty much everywhere ;)
>> >>>
>> >>> > > > --
>> >>>
>> >>> > > > You received this message because you are subscribed to the
>> Google
>> >>> > Groups
>> >>> > > > "jQuery Development" group.
>> >>> > > > To post to this group, send email to
>> >>> > > > [hidden email]
>> .
>> >>> > > > To unsubscribe from this group, send email to
>> >>> > > > > >
>>
<[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>>
>> >>> > > > .
>> >>> > > > For more options, visit this group at
>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>> >>>
>> >>> > --
>> >>>
>> >>> > You received this message because you are subscribed to the Google
>> >>> > Groups
>> >>> > "jQuery Development" group.
>> >>> > To post to this group, send email to [hidden email].
>> >>> > To unsubscribe from this group, send email to
>> >>> >
>>
[hidden email]<[hidden email]>
>>
<[hidden email]<[hidden email]>
>> >
>> >>> > .
>> >>> > For more options, visit this group at
>> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >> --
>> >>
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "jQuery Development" group.
>> >> To post to this group, send email to [hidden email].
>> >> To unsubscribe from this group, send email to
>> >>
[hidden email]<[hidden email]>
>> .
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/jquery-dev?hl=en.
>> >>
>> >>
>> >>
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> > To post to this group, send email to [hidden email].
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<[hidden email]>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google
Groups
>> "jQuery Development" group.
>> To post to this group, send email to [hidden email].
>> To unsubscribe from this group, send email to
>>
[hidden email]<[hidden email]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.



--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

webbiedave-2
In reply to this post by jaubourg
On Tue, 29 Dec 2009 09:35:11 +0100, Julian Aubourg
[...]

>>
>> I'm beginning to wonder if we're not buzzing for nothing with this
>> conversation. Actually, not specifying a dataType could very well behave
>> as
>> a guess-anything system. In analogy to what you said with content-type,
>> setting a dataType will prevent any automatic decision, so existing code
>> that would be impacted by automatic json evaluation would just have to
>> add
>> the dataType option, something I don't see as such an atrocious
>> maintenance
>> task it would require some heavy-weight system in jQuery.
[...]


There's something significant behind the buzz, though. I really don't want
to read the announcement: "ATTN everyone using jQuery.ajax(). If you're
going to update your library or if you're linking to the latest on google
and it's updated FOR you without your knowledge, you MUST first go through
all of your existing code and explicitly choose a dataType. This is because
we have changed dataType's default behavior which now makes it possible
that javascript could be eval'd undesirably. Also, if you depended upon an
xml/html only guess in your app design, well then I guess you're out of
luck for now."

Obviously I'm no good at writing announcements but this is the gist of why
we need a new setting to allow guess-anything/auto-detect or whatever we
call it.




>>>
>>> Client sends acceptable content types, server responds with a content
>>> type, if the server's response is one of the accepted types, jQuery
>>> processes accordingly, if not, jQuery returns data unprocessed.
>>>
>>> The dataType option should be for things that aren't necessarily well
>>> communicated via content-type alone, like JSONP, or anything else that
>>> modifies the nature of the request, not just the content type.
>>>
>>> If you're worried about your server sending malicious javascript, then
>>> only accept text/plain or text/xml (even dataType: 'html' isn't safe
>>> since
>>> it executes script blocks). If you don't care, then accept "*/*".
>>>
>>> Or am I missing something?
>>>
>>> --Erik
>>>
>>>
>>> On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron
>>> <[hidden email]>wrote:
>>>
>>>> I can compromise with your #2, and give them both my vote.
>>>>
>>>> Passing it on...
>>>>
>>>>
>>>> *1. Allow $.ajax() to accept multiple expected dataTypes.
>>>>
>>>> 2. Setting to have $.ajax() auto-detect/translate via response
>>>> content-type
>>>> header.*
>>>>
>>>>
>>>>
>>>> Julian - your thoughts?
>>>>
>>>>
>>>>
>>>> On Mon, Dec 28, 2009 at 3:39 PM, webbiedave
>>>> <[hidden email]
>>>> > wrote:
>>>>
>>>>> Rick, your 1 (which I too have suggested in the past) might bring
>>>>> about
>>>>> unease as folks would prefer any eval-ing to come through explicit
>>>>> request.
>>>>> I also think it's imperative that the behavior of any dataType
setting

>>>>> (including null) shouldn't change (especially to one that suddenly
>>>>> evals!).
>>>>> But that's just my opinion. My 1, 2 would be:
>>>>>
>>>>> 1. Allow $.ajax() to accept multiple expected dataTypes.
>>>>>
>>>>> 2. Setting to have $.ajax() auto-detect/translate via response
>>>>> content-type
>>>>> header.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron <
>>>>> [hidden email]>
>>>>> wrote:
>>>>> >>
>>>>> >> We're struggling with the best way to inform .ajax() that we
expect
>>>>> >> multiple data types. Either, with a setting like "auto" or by
>>>>> >> passing
>>>>> an
>>>>> >> array of data types (or maybe allowing both).
>>>>> >>
>>>>> >
>>>>> > Perhaps it would help if we defined a list of goals. I'll start.
>>>>> >
>>>>> > 1. $.ajax() - if dataType has not been defined in the argument
list,

>>>>> > $.ajax() should respect the returned Content-type header and
>>>>> > translate
>>>>> > accordingly.
>>>>> >
>>>>> > 2. ....
>>>>> >
>>>>> >
>>>>> > Fill it in!
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > Rick
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]>
>>>>> > wrote:
>>>>> >
>>>>> >> We're struggling with the best way to inform .ajax() that we
expect

>>>>> >> multiple data types. Either, with a setting like "auto" or by
>>>>> >> passing
>>>>> an
>>>>> >> array of data types (or maybe allowing both).
>>>>> >>
>>>>> >>
>>>>> >> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson <
>>>>> [hidden email]>
>>>>> >> wrote:
>>>>> >> > Seems like a lot of awkward wheel reinventing going on here.
>>>>> Content
>>>>> >> > type negotiation is a feature of HTTP; is there a reason we
>>>>> >> > aren't
>>>>> >> > using it?
>>>>> >> >
>>>>> >> > --Erik
>>>>> >> >
>>>>> >> >
>>>>> >> > On Saturday, December 26, 2009, webbiedave
>>>>> >> > <[hidden email]>
>>>>> >> > wrote:
>>>>> >> >> "Following your idea that a library has to keep exactly the
same
>>>>> >> >> behavior from versions to versions [...] then what happens if &
>>>>> when
>>>>> >> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>>>>> >> >>
>>>>> >> >> Things could break *without* the introduction of new
>>>>> auto-detectable
>>>>> >> >> types. If you use "auto" and are only handling json and html
and
>>>>> >> >> suddenly javascript is returned, that javascript will be eval'd
>>>>> and
>>>>> >> >> things will will not turn out well. That's why you can't use
>>>>> "auto"
>>>>> on
>>>>> >> >> untrusted/incompetent servers. That's the whole point of
"auto".

>>>>> You
>>>>> >> >> are trusting the server to return the correct data. Use at your
>>>>> own
>>>>> >> >> risk. But it's there if you need it.
>>>>> >> >>
>>>>> >> >> Having said that, #1 in my suggestions is passing an array
>>>>> (dataType:
>>>>> >> >> ["json", html"]).
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]>
>>>>> wrote:
>>>>> >> >>> > As I mentioned in my previous
>>>>> >> >>> > post, one of this approach's downside is "null vs auto"
>>>>> confusion
>>>>> >> >>> > as
>>>>> >> >>> > auto is like null plus more (json, script, future accepted
>>>>> >> dataTypes).
>>>>> >> >>> > The whole point is that "auto" means auto-detect type via
>>>>> >> content-type
>>>>> >> >>> > headers and null does not mean that (it means guess between
>>>>> html
>>>>> or
>>>>> >> >>> > xml)
>>>>> >> >>>
>>>>> >> >>> This is exactly where the solution is inconsistent.
>>>>> >> >>>
>>>>> >> >>> "auto", in your implementation, does not mean "null plus more
>>>>> (json,
>>>>> >> >>> script,
>>>>> >> >>> *future accepted dataTypes*)" but it just means "null plus
json
>>>>> >> >>> &
>>>>> >> >>> script"
>>>>> >> >>> and only that. Following your idea that a library has to keep
>>>>> exactly
>>>>> >> >>> the
>>>>> >> >>> same behavior from versions to versions (which jQuery broke
btw
>>>>> when
>>>>> >> >>> ditching the @ syntax for attributes in selectors) then what
>>>>> happens
>>>>> >> >>> if
>>>>> >> >>> &
>>>>> >> >>> when jQuery introduces a new auto-detectable dataType in
1.4.1?

>>>>> You
>>>>> >> >>> create
>>>>> >> >>> an "auto2" dataType so that existing code running in 1.4 is
>>>>> >> >>> unaffected
>>>>> >> >>> (ie:
>>>>> >> >>> the new dataType is not auto-detected)? How would you document
>>>>> such
>>>>> a
>>>>> >> >>> behaviour? What happens when there's another auto-detectable
>>>>> dataType
>>>>> >> >>> introduced in 1.4.2?
>>>>> >> >>>
>>>>> >> >>> Giving programmers a way to specify exactly the dataTypes they
>>>>> expect
>>>>> >> to
>>>>> >> >>> be
>>>>> >> >>> auto-detected is the way to go (would it be with an array or
an

>>>>> >> >>> expression).
>>>>> >> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax
>>>>> >> >>> code
>>>>> and
>>>>> >> >>> you're
>>>>> >> >>> done: no backward compatibility issue... plus you're safe for
>>>>> future
>>>>> >> >>> developments in the dataType auto-detection area.
>>>>> >> >>>
>>>>> >> >>> 2009/12/27 webbiedave <[hidden email]>
>>>>> >> >>>
>>>>> >> >>> > "Second, auto seems like the weirdest thing ever to me used
>>>>> like
>>>>> it
>>>>> >> is
>>>>> >> >>> > here. So dataType==null and dataType=="auto" act the same
for

>>>>> xml
>>>>> >> >>> > but
>>>>> >> >>> > not for script & json? Seems completely inconsistant to me."
>>>>> >> >>>
>>>>> >> >>> > It's not that weird. I don't think that different settings
>>>>> yielding
>>>>> >> >>> > different results is necessarily inconsistent. There are two
>>>>> ways
>>>>> >> >>> > to
>>>>> >> >>> > get xml and now there'll be a third. As I mentioned in my
>>>>> previous
>>>>> >> >>> > post, one of this approach's downside is "null vs auto"
>>>>> confusion
>>>>> >> >>> > as
>>>>> >> >>> > auto is like null plus more (json, script, future accepted
>>>>> >> dataTypes).
>>>>> >> >>> > The whole point is that "auto" means auto-detect type via
>>>>> >> content-type
>>>>> >> >>> > headers and null does not mean that (it means guess between
>>>>> html
>>>>> or
>>>>> >> >>> > xml). It is imperative that the behavior of dataType: null
>>>>> remains
>>>>> >> the
>>>>> >> >>> > same so this is a way to do that while affording multiple
>>>>> expected
>>>>> >> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't
>>>>> break
>>>>> >> >>> > existing apps. Quite frankly, it usage makes simple sense to
>>>>> >> >>> > me
>>>>> and
>>>>> >> >>> > those who need it will know exactly what it means and how to
>>>>> use
>>>>> it
>>>>> >> >>> > (and will be relieved they can ditch their hacked
libraries).

>>>>> >> >>>
>>>>> >> >>> > "If a coder does not want auto conversion, then he simply
>>>>> specifies
>>>>> >> >>> > a
>>>>> >> >>> > dataType (namely "text")."
>>>>> >> >>>
>>>>> >> >>> > But null does not mean auto convert. It means guess between
>>>>> html
>>>>> or
>>>>> >> >>> > xml and that cannot change.
>>>>> >> >>>
>>>>> >> >>> > "But, please, do not introduce a behavior that will act
>>>>> differently
>>>>> >> >>> > for xml than it does for any other dataType deduced from
>>>>> content
>>>>> >> >>> > type
>>>>> >> >>> > headers."
>>>>> >> >>>
>>>>> >> >>> > I admit I don't share your fear of such behavior and, in
>>>>> >> >>> > fact,
>>>>> >> greatly
>>>>> >> >>> > desire such a new setting. I'll know that my live apps that
>>>>> >> >>> > are
>>>>> >> >>> > using
>>>>> >> >>> > dataType: null will be unaffected and in the future I'd be
>>>>> >> >>> > able
>>>>> to
>>>>> >> >>> > write ajax calls that can respond to various data types.
>>>>> >> >>> > Also,
>>>>> I've
>>>>> >> >>> > suggested several approaches and look forward to reading
what
>>>>> >> >>> > others
>>>>> >> >>> > think of them.
>>>>> >> >>>
>>>>> >> >>> > On Dec 26, 3:47 pm, Julian Aubourg
<[hidden email]>

>>>>> >> >>> > wrote:
>>>>> >> >>> > > Regardless, I'm leaning towards the dataType: "auto"
>>>>> >> >>> > > approach
>>>>> as
>>>>> >> >>> > > it's easy to use/implement and affords enough control.
>>>>> >> >>>
>>>>> >> >>> > > Well, so, first, I translated the dataType to "auto" when
>>>>> >> >>> > > it
>>>>> was
>>>>> >> >>> > > null/undefined in my rewriting (because I hate
>>>>> messy/undefined
>>>>> >> >>> > > values).
>>>>> >> >>> > But
>>>>> >> >>> > > that's no biggy.
>>>>> >> >>>
>>>>> >> >>> > > Second, auto seems like the weirdest thing ever to me used
>>>>> like
>>>>> >> >>> > > it
>>>>> >> >>> > > is
>>>>> >> >>> > here.
>>>>> >> >>> > > So dataType==null and dataType=="auto" act the same for
xml

>>>>> but
>>>>> >> >>> > > not
>>>>> >> >>> > > for
>>>>> >> >>> > > script & json? Seems completely inconsistant to me.
>>>>> >> >>>
>>>>> >> >>> > > If a coder does not want auto conversion, then he simply
>>>>> >> >>> > > specifies
>>>>> >> a
>>>>> >> >>> > > dataType (namely "text"). You just have to document it.
>>>>> >> >>> > > But,
>>>>> >> please,
>>>>> >> >>> > > do
>>>>> >> >>> > not
>>>>> >> >>> > > introduce a behavior that will act differentely for xml
>>>>> >> >>> > > than
>>>>> it
>>>>> >> does
>>>>> >> >>> > > for
>>>>> >> >>> > any
>>>>> >> >>> > > other dataType deduced from content type headers.
>>>>> >> >>>
>>>>> >> >>> > > 2009/12/26 webbiedave <[hidden email]>
>>>>> >> >>>
>>>>> >> >>> > > > I was referring solely to the "bitwise or" style.
>>>>> Regardless,
>>>>> >> >>> > > > I'm
>>>>> >> >>> > > > leaning towards the dataType: "auto" approach as it's
>>>>> >> >>> > > > easy
>>>>> to
>>>>> >> use/
>>>>> >> >>> > > > implement and affords enough control.
>>>>> >> >>>
>>>>> >> >>> > > > Julian Aubourg wrote:
>>>>> >> >>>
>>>>> >> >>> > > > > As for string expressions not being in the calling
>>>>> >> >>> > > > > style
>>>>> of
>>>>> >> >>> > > > > jQuery...
>>>>> >> >>> > > > > well... I really disagree here, since jQuery has
>>>>> expression
>>>>> >> >>> > > > > parsed
>>>>> >> >>> > parsed
>>>>> >> >>> > > > > pretty much everywhere ;)
>>>>> >> >>>
>>>>> >> >>> > > > --
>>>>> >> >>>
>>>>> >> >>> > > > You received this message because you are subscribed to
>>>>> >> >>> > > > the
>>>>> >> Google
>>>>> >> >>> > Groups
>>>>> >> >>> > > > "jQuery Development" group.
>>>>> >> >>> > > > To post to this group, send email to
>>>>> >> >>> > > > [hidden email]
>>>>> >> .
>>>>> >> >>> > > > To unsubscribe from this group, send email to
>>>>> >> >>> > > > > >
>>>>> >>
>>>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>>>> >
>>>>> >>
>>>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>>>>> >
>>>>> >> >
>>>>> >> >>>
>>>>> >> >>> > > > .
>>>>> >> >>> > > > For more options, visit this group at
>>>>> >> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>>>>> >> >>>
>>>>> >> >>> > --
>>>>> >> >>>
>>>>> >> >>> > You received this message because you are subscribed to the
>>>>> Google
>>>>> >> >>> > Groups
>>>>> >> >>> > "jQuery Development" group.
>>>>> >> >>> > To post to this group, send email to
>>>>> [hidden email].
>>>>> >> >>> > To unsubscribe from this group, send email to
>>>>> >> >>> >
>>>>> >>
>>>>>
[hidden email]<jquery-dev%[hidden email]>
>>>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>>>> >
>>>>> >>
>>>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>>>>> >
>>>>> >> >
>>>>> >> >>> > .
>>>>> >> >>> > For more options, visit this group at
>>>>> >> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>>>>> >> >>
>>>>> >> >> --
>>>>> >> >>
>>>>> >> >> You received this message because you are subscribed to the
>>>>> >> >> Google
>>>>> >> Groups
>>>>> >> >> "jQuery Development" group.
>>>>> >> >> To post to this group, send email to
>>>>> >> >> [hidden email].
>>>>> >> >> To unsubscribe from this group, send email to
>>>>> >> >>
>>>>>
[hidden email]<jquery-dev%[hidden email]>
>>>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>>>>> >
>>>>> >> .
>>>>> >> >> For more options, visit this group at
>>>>> >> >> http://groups.google.com/group/jquery-dev?hl=en.
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >
>>>>> >> > --
>>>>> >> >
>>>>> >> > You received this message because you are subscribed to the
>>>>> >> > Google
>>>>> >> > Groups
>>>>> >> > "jQuery Development" group.
>>>>> >> > To post to this group, send email to
[hidden email].
>>>>> >> > To unsubscribe from this group, send email to
>>>>> >> >
>>>>>
[hidden email]<jquery-dev%[hidden email]>
>>>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>>>>> >
>>>>> >> .
>>>>> >> > For more options, visit this group at
>>>>> >> > http://groups.google.com/group/jquery-dev?hl=en.
>>>>> >>
>>>>> >> --
>>>>> >>
>>>>> >> You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> >> "jQuery Development" group.
>>>>> >> To post to this group, send email to [hidden email].
>>>>> >> To unsubscribe from this group, send email to
>>>>> >>
>>>>>
[hidden email]<jquery-dev%[hidden email]>
>>>>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>>>>> >
>>>>> >> .
>>>>> >> For more options, visit this group at
>>>>> >> http://groups.google.com/group/jquery-dev?hl=en.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >
>>>>> > --
>>>>> >
>>>>> > You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> > "jQuery Development" group.
>>>>> > To post to this group, send email to [hidden email].
>>>>> > To unsubscribe from this group, send email to
>>>>> >
[hidden email]<jquery-dev%[hidden email]>

>>>>> .
>>>>> > For more options, visit this group at
>>>>> > http://groups.google.com/group/jquery-dev?hl=en.
>>>>>
>>>>> --
>>>>>
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "jQuery Development" group.
>>>>> To post to this group, send email to [hidden email].
>>>>> To unsubscribe from this group, send email to
>>>>>
[hidden email]<jquery-dev%[hidden email]>

>>>>> .
>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/jquery-dev?hl=en.
>>>>>
>>>>>
>>>>>
>>>>  --
>>>> You received this message because you are subscribed to the Google
>>>> Groups
>>>> "jQuery Development" group.
>>>> To post to this group, send email to [hidden email].
>>>> To unsubscribe from this group, send email to
>>>>
[hidden email]<jquery-dev%[hidden email]>

>>>> .
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/jquery-dev?hl=en.
>>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "jQuery Development" group.
>>> To post to this group, send email to [hidden email].
>>> To unsubscribe from this group, send email to
>>>
[hidden email]<jquery-dev%[hidden email]>

>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/jquery-dev?hl=en.
>>>
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

Tobias Hoffmann-2
In reply to this post by jaubourg
Catching up on my emails...

On Tue, Dec 29, 2009 at 9:27 AM, Julian Aubourg <[hidden email]> wrote:
If you're worried about your server sending malicious javascript, then only accept text/plain or text/xml (even dataType: 'html' isn't safe since it executes script blocks). 

Good point. 

IMO auto-eval of json really becomes a problem, when the request uri is taken/generated from an unsafe source (or the destination script will "unpredictably" change the content-type through query-parameters from an unsafe source).  For static uri/request parameters I do expect the web-developer to know what the server side scripts possibly responds.

For cross-domain ajax requests I would tend to consider it as bug, if the developer does not specify a dataType and get unintended results.

And with html and script blocks we already have the 'eval'-behavior (which I did not think of in my original post). So it looks to me that adding json would not change much, after all.

My intent was not to say "We need to change that", but to point to this issue and ask "Have you thought about that?" If we come to the conclusion that this won't happen / make things worse (i.e. apart from what the developer already has to take care of wrt. ajax requests) for real-world applications, and maybe add a note to the documentation: "Always specify a dataType for unknown/untrusted content, because of possible script execution [even for html!]" -- that's fine with me, too.

  Tobias

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

webbiedave-2
On Tue, 29 Dec 2009 22:52:45 +0100, Tobias Hoffmann
<[hidden email]> wrote:
[...]
> And with html and script blocks we already have the 'eval'-behavior
(which
> I
> did not think of in my original post).
[...]

But not until the moment the developer chooses to place it into the DOM
(when using $.ajax()). Granted, that's the whole point of retrieving the
html but the execution does occur at a different point than would the json
(httpData). Just throwin' this in here for completeness.



>
> My intent was not to say "We need to change that", but to point to this
> issue and ask "Have you thought about that?" If we come to the conclusion
> that this won't happen / make things worse (i.e. apart from what the
> developer already has to take care of wrt. ajax requests) for real-world
> applications, and maybe add a note to the documentation: "Always specify
a

> dataType for unknown/untrusted content, because of possible script
> execution
> [even for html!]" -- that's fine with me, too.
>
>   Tobias
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: GOALS? Feature Request: $.ajax(): Detect json via response header

jaubourg
In reply to this post by webbiedave-2
There's something significant behind the buzz, though. I really don't want
to read the announcement: "ATTN everyone using jQuery.ajax(). If you're
going to update your library or if you're linking to the latest on google
and it's updated FOR you without your knowledge, you MUST first go through
all of your existing code and explicitly choose a dataType. This is because
we have changed dataType's default behavior which now makes it possible
that javascript could be eval'd undesirably. Also, if you depended upon an
xml/html only guess in your app design, well then I guess you're out of
luck for now."

Obviously I'm no good at writing announcements but this is the gist of why
we need a new setting to allow guess-anything/auto-detect or whatever we
call it.

Well, let's take the original request here: it was about having ajax automatically fetch json data using the content-type header. Letting the server decide whether javascript code should be executed or not client-side is wrong no matter how you look at it. It should be a conscious decision from the developpers (just like it is when dealing with <script /> embedded into html or jsonp requests). So I'm clearly against auto-fetching scripts (sorry that I totally forgot to say so earlier).

Now we're left with pure json which is evald if there is no native JSON object client-side. Wouldn't it be feasible to regexp test the string before evaluation to avoid malicious code in that case? If so, there is strictly no reason not to allow auto-fetching feature for json dataType.

For instance, http://code.google.com/p/jquery-json/ provides a secureEvalJSON method that makes some tests before evaluating the string expression. Seems to me like a good way to start.

--

You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: REVISED GOALS - Feature Request: $.ajax(): Detect json via response header

webbiedave-2
In reply to this post by Rick Waldron
OK. Not sure where we're at on this but I'm hoping some sort of consensus
can be achieved. Here are the  approaches being bandied about to allow
auto-detect of json (and perhaps other dataTypes):


1) Allow $.ajax() to accept multiple expected data types, i.e., dataTypes:
['json', 'html']. jQuery will attempt to auto-detect only those types.

2) New setting/option to have $.ajax() auto-detect/translate via response
content-type. This will detect/translate any of the supported data types
(and future data types) via the response Content-Type header.

3) Change dataType:null's auto-detect (intelligent guess) to include json.

4) New setting/option to have $.ajax() auto-detect html, xml and json.


Be so kind as to re-vote in case these added details have changed your
minds.





On Tue, 29 Dec 2009 09:46:50 -0500, "Rick Waldron" <[hidden email]>
wrote:

> This is good. #2 has solid support.
>
> John, care to chime in this?
>
>
>
> -- Sent from my Palm Prē
> Julian Aubourg wrote:
>
> So it was pure #2 obviously, not #1.
>
> 2009/12/29 Julian Aubourg <[hidden email]>
>
> Again, why not do this with an Accept header?
> Client
> sends acceptable content types, server responds with a content type, if
> the server's response is one of the accepted types, jQuery processes
> accordingly, if not, jQuery returns data unprocessed.
> The dataType option should be for things that
> aren't necessarily well communicated via content-type alone, like
> JSONP, or anything else that modifies the nature of the request, not
> just the content type.
> If you're worried about your server sending
> malicious javascript, then only accept text/plain or text/xml (even
> dataType: 'html' isn't safe since it executes script blocks). If you
> don't care, then accept "*/*".
>
>
>
>
> There are a couple of reasons why an accept / content-type system is not
> that simple:
> 1) When not specifying a dataType, accept is */* (which makes sense since
> we don't expect a particular dataType) while current behaviour is to
> autodetect xml against text (or, maybe, in future extensions, to
autodetect
> any type). The only workaround if you're basing your tests around the
> accept header would be to associate all of the xx/yy possibilities known
to
> men with their corresponding dataType. The behaviour, as it is now, is to
> group correspondance from content-type to dataType using simple regexps
(ie

> /xml/, /json/) which I find much more efficient and not too configuration
> heavy.
>
>
> 2) It still doesn't address the issue of specifying a set of accepted
> dataTypes just with the dataType property (which is a much better
> abstraction than setting content-type headers in a beforeSend callback or
> globally adding accepted types in ajaxSettings).
>
>
>
> I'm beginning to wonder if we're not buzzing for nothing with this
> conversation. Actually, not specifying a dataType could very well behave
as
> a guess-anything system. In analogy to what you said with content-type,
> setting a dataType will prevent any automatic decision, so existing code
> that would be impacted by automatic json evaluation would just have to
add
> the dataType option, something I don't see as such an atrocious
maintenance

> task it would require some heavy-weight system in jQuery.
>
>
>
> So, the more I think about it, the more I'm in favor of #1.
>
> 2009/12/28 Erik Beeson <[hidden email]>
>
>
> Again, why not do this with an Accept header?
> Client sends acceptable content types, server responds with a content
type,

> if the server's response is one of the accepted types, jQuery processes
> accordingly, if not, jQuery returns data unprocessed.
>
>
>
> The dataType option should be for things that aren't necessarily well
> communicated via content-type alone, like JSONP, or anything else that
> modifies the nature of the request, not just the content type.
>
>
>
> If you're worried about your server sending malicious javascript, then
only

> accept text/plain or text/xml (even dataType: 'html' isn't safe since it
> executes script blocks). If you don't care, then accept "*/*".
>
>
>
> Or am I missing something?
> --Erik
>
> On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron <[hidden email]>
> wrote:
>
>
>
> I can compromise with your #2, and give them both my vote.
>
> Passing it on...
>
>
>
> 1. Allow $.ajax() to accept multiple expected dataTypes.
>
>
>
> 2. Setting to have $.ajax() auto-detect/translate via response
content-type

>
> header.
>
>
>
>
> Julian - your thoughts?
>
>
> On Mon, Dec 28, 2009 at 3:39 PM, webbiedave
> <[hidden email]> wrote:
>
>
>
>
>
> Rick, your 1 (which I too have suggested in the past) might bring about
>
> unease as folks would prefer any eval-ing to come through explicit
request.
>
> I also think it's imperative that the behavior of any dataType setting
>
> (including null) shouldn't change (especially to one that suddenly
evals!).

>
> But that's just my opinion. My 1, 2 would be:
>
>
>
> 1. Allow $.ajax() to accept multiple expected dataTypes.
>
>
>
> 2. Setting to have $.ajax() auto-detect/translate via response
content-type

>
> header.
>
>
>
>
>
>
>
> On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron
> <[hidden email]>
>
> wrote:
>
>>>
>
>>> We're struggling with the best way to inform .ajax() that we expect
>
>>> multiple data types. Either, with a setting like "auto" or by passing
an

>
>>> array of data types (or maybe allowing both).
>
>>>
>
>>
>
>> Perhaps it would help if we defined a list of goals. I'll start.
>
>>
>
>> 1. $.ajax() - if dataType has not been defined in the argument list,
>
>> $.ajax() should respect the returned Content-type header and translate
>
>> accordingly.
>
>>
>
>> 2. ....
>
>>
>
>>
>
>> Fill it in!
>
>>
>
>>
>
>>
>
>>
>
>> Rick
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>
>>
>
>>> We're struggling with the best way to inform .ajax() that we expect
>
>>> multiple data types. Either, with a setting like "auto" or by passing
an

>
>>> array of data types (or maybe allowing both).
>
>>>
>
>>>
>
>>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson
>>> <[hidden email]>
>
>>> wrote:
>
>>> > Seems like a lot of awkward wheel reinventing going on here. Content
>
>>> > type negotiation is a feature of HTTP; is there a reason we aren't
>
>>> > using it?
>
>>> >
>
>>> > --Erik
>
>>> >
>
>>> >
>
>>> > On Saturday, December 26, 2009, webbiedave
>
>>> > <[hidden email]>
>
>>> > wrote:
>
>>> >> "Following your idea that a library has to keep exactly the same
>
>>> >> behavior from versions to versions [...] then what happens if &
>>> >> when
>
>>> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>
>>> >>
>
>>> >> Things could break *without* the introduction of new auto-detectable
>
>>> >> types. If you use "auto" and are only handling json and html and
>
>>> >> suddenly javascript is returned, that javascript will be eval'd and
>
>>> >> things will will not turn out well. That's why you can't use "auto"
>
> on
>
>>> >> untrusted/incompetent servers. That's the whole point of "auto". You
>
>>> >> are trusting the server to return the correct data. Use at your own
>
>>> >> risk. But it's there if you need it.
>
>>> >>
>
>>> >> Having said that, #1 in my suggestions is passing an array
(dataType:

>
>>> >> ["json", html"]).
>
>>> >>
>
>>> >>
>
>>> >>
>
>>> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]>
>>> >> wrote:
>
>>> >>> > As I mentioned in my previous
>
>>> >>> > post, one of this approach's downside is "null vs auto" confusion
>
>>> >>> > as
>
>>> >>> > auto is like null plus more (json, script, future accepted
>
>>> dataTypes).
>
>>> >>> > The whole point is that "auto" means auto-detect type via
>
>>> content-type
>
>>> >>> > headers and null does not mean that (it means guess between html
>
> or
>
>>> >>> > xml)
>
>>> >>>
>
>>> >>> This is exactly where the solution is inconsistent.
>
>>> >>>
>
>>> >>> "auto", in your implementation, does not mean "null plus more
(json,

>
>>> >>> script,
>
>>> >>> *future accepted dataTypes*)" but it just means "null plus json
>>> >>> &
>
>>> >>> script"
>
>>> >>> and only that. Following your idea that a library has to keep
>
> exactly
>
>>> >>> the
>
>>> >>> same behavior from versions to versions (which jQuery broke btw
when
>
>>> >>> ditching the @ syntax for attributes in selectors) then what
happens

>
>>> >>> if
>
>>> >>> &
>
>>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You
>
>>> >>> create
>
>>> >>> an "auto2" dataType so that existing code running in 1.4 is
>
>>> >>> unaffected
>
>>> >>> (ie:
>
>>> >>> the new dataType is not auto-detected)? How would you document such
>
> a
>
>>> >>> behaviour? What happens when there's another auto-detectable
>
> dataType
>
>>> >>> introduced in 1.4.2?
>
>>> >>>
>
>>> >>> Giving programmers a way to specify exactly the dataTypes they
>
> expect
>
>>> to
>
>>> >>> be
>
>>> >>> auto-detected is the way to go (would it be with an array or an
>
>>> >>> expression).
>
>>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code
>
> and
>
>>> >>> you're
>
>>> >>> done: no backward compatibility issue... plus you're safe for
future

>
>>> >>> developments in the dataType auto-detection area.
>
>>> >>>
>
>>> >>> 2009/12/27 webbiedave <[hidden email]>
>
>>> >>>
>
>>> >>> > "Second, auto seems like the weirdest thing ever to me used like
>
> it
>
>>> is
>
>>> >>> > here. So dataType==null and dataType=="auto" act the same for xml
>
>>> >>> > but
>
>>> >>> > not for script & json? Seems completely inconsistant to me."
>
>>> >>>
>
>>> >>> > It's not that weird. I don't think that different settings
>
> yielding
>
>>> >>> > different results is necessarily inconsistent. There are two ways
>
>>> >>> > to
>
>>> >>> > get xml and now there'll be a third. As I mentioned in my
previous

>
>>> >>> > post, one of this approach's downside is "null vs auto" confusion
>
>>> >>> > as
>
>>> >>> > auto is like null plus more (json, script, future accepted
>
>>> dataTypes).
>
>>> >>> > The whole point is that "auto" means auto-detect type via
>
>>> content-type
>
>>> >>> > headers and null does not mean that (it means guess between html
>
> or
>
>>> >>> > xml). It is imperative that the behavior of dataType: null
remains
>
>>> the
>
>>> >>> > same so this is a way to do that while affording multiple
expected

>
>>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't break
>
>>> >>> > existing apps. Quite frankly, it usage makes simple sense to me
>
> and
>
>>> >>> > those who need it will know exactly what it means and how to use
>
> it
>
>>> >>> > (and will be relieved they can ditch their hacked libraries).
>
>>> >>>
>
>>> >>> > "If a coder does not want auto conversion, then he simply
>
> specifies
>
>>> >>> > a
>
>>> >>> > dataType (namely "text")."
>
>>> >>>
>
>>> >>> > But null does not mean auto convert. It means guess between html
>
> or
>
>>> >>> > xml and that cannot change.
>
>>> >>>
>
>>> >>> > "But, please, do not introduce a behavior that will act
>
> differently
>
>>> >>> > for xml than it does for any other dataType deduced from content
>
>>> >>> > type
>
>>> >>> > headers."
>
>>> >>>
>
>>> >>> > I admit I don't share your fear of such behavior and, in fact,
>
>>> greatly
>
>>> >>> > desire such a new setting. I'll know that my live apps that are
>
>>> >>> > using
>
>>> >>> > dataType: null will be unaffected and in the future I'd be able
to

>
>>> >>> > write ajax calls that can respond to various data types. Also,
>
> I've
>
>>> >>> > suggested several approaches and look forward to reading what
>
>>> >>> > others
>
>>> >>> > think of them.
>
>>> >>>
>
>>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>
>>> >>> > wrote:
>
>>> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach
as
>
>>> >>> > > it's easy to use/implement and affords enough control.
>
>>> >>>
>
>>> >>> > > Well, so, first, I translated the dataType to "auto" when it
was

>
>>> >>> > > null/undefined in my rewriting (because I hate messy/undefined
>
>>> >>> > > values).
>
>>> >>> > But
>
>>> >>> > > that's no biggy.
>
>>> >>>
>
>>> >>> > > Second, auto seems like the weirdest thing ever to me used like
>
>>> >>> > > it
>
>>> >>> > > is
>
>>> >>> > here.
>
>>> >>> > > So dataType==null and dataType=="auto" act the same for xml but
>
>>> >>> > > not
>
>>> >>> > > for
>
>>> >>> > > script & json? Seems completely inconsistant to me.
>
>>> >>>
>
>>> >>> > > If a coder does not want auto conversion, then he simply
>
>>> >>> > > specifies
>
>>> a
>
>>> >>> > > dataType (namely "text"). You just have to document it. But,
>
>>> please,
>
>>> >>> > > do
>
>>> >>> > not
>
>>> >>> > > introduce a behavior that will act differentely for xml than it
>
>>> does
>
>>> >>> > > for
>
>>> >>> > any
>
>>> >>> > > other dataType deduced from content type headers.
>
>>> >>>
>
>>> >>> > > 2009/12/26 webbiedave <[hidden email]>
>
>>> >>>
>
>>> >>> > > > I was referring solely to the "bitwise or" style. Regardless,
>
>>> >>> > > > I'm
>
>>> >>> > > > leaning towards the dataType: "auto" approach as it's easy to
>
>>> use/
>
>>> >>> > > > implement and affords enough control.
>
>>> >>>
>
>>> >>> > > > Julian Aubourg wrote:
>
>>> >>>
>
>>> >>> > > > > As for string expressions not being in the calling style of
>
>>> >>> > > > > jQuery...
>
>>> >>> > > > > well... I really disagree here, since jQuery has expression
>
>>> >>> > > > > parsed
>
>>> >>> > parsed
>
>>> >>> > > > > pretty much everywhere ;)
>
>>> >>>
>
>>> >>> > > > --
>
>>> >>>
>
>>> >>> > > > You received this message because you are subscribed to the
>
>>> Google
>
>>> >>> > Groups
>
>>> >>> > > > "jQuery Development" group.
>
>>> >>> > > > To post to this group, send email to
>
>>> >>> > > > [hidden email]
>
>>> .
>
>>> >>> > > > To unsubscribe from this group, send email to
>
>>> >>> > > > > >
>
>>>
>
>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>
>
>
>
>
>
>>>
>
>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>
>
>
>
>
>
>>> >
>
>>> >>>
>
>>> >>> > > > .
>
>>> >>> > > > For more options, visit this group at
>
>>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>
>>> >>>
>
>>> >>> > --
>
>>> >>>
>
>>> >>> > You received this message because you are subscribed to the
Google

>
>>> >>> > Groups
>
>>> >>> > "jQuery Development" group.
>
>>> >>> > To post to this group, send email to [hidden email].
>
>>> >>> > To unsubscribe from this group, send email to
>
>>> >>> >
>
>>>
>
>
[hidden email]<jquery-dev%[hidden email]>
>
>
>
>
>
>
>>>
>
>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>
>
>
>
>
>
>>> >
>
>>> >>> > .
>
>>> >>> > For more options, visit this group at
>
>>> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>
>>> >>
>
>>> >> --
>
>>> >>
>
>>> >> You received this message because you are subscribed to the Google
>
>>> Groups
>
>>> >> "jQuery Development" group.
>
>>> >> To post to this group, send email to [hidden email].
>
>>> >> To unsubscribe from this group, send email to
>
>>> >>
>
>
[hidden email]<jquery-dev%[hidden email]>

>
>
>
>
>
>
>>> .
>
>>> >> For more options, visit this group at
>
>>> >> http://groups.google.com/group/jquery-dev?hl=en.
>
>>> >>
>
>>> >>
>
>>> >>
>
>>> >
>
>>> > --
>
>>> >
>
>>> > You received this message because you are subscribed to the Google
>
>>> > Groups
>
>>> > "jQuery Development" group.
>
>>> > To post to this group, send email to [hidden email].
>
>>> > To unsubscribe from this group, send email to
>
>>> >
>
>
[hidden email]<jquery-dev%[hidden email]>

>
>
>
>
>
>
>>> .
>
>>> > For more options, visit this group at
>
>>> > http://groups.google.com/group/jquery-dev?hl=en.
>
>>>
>
>>> --
>
>>>
>
>>> You received this message because you are subscribed to the Google
>
> Groups
>
>>> "jQuery Development" group.
>
>>> To post to this group, send email to [hidden email].
>
>>> To unsubscribe from this group, send email to
>
>>>
>
>
[hidden email]<jquery-dev%[hidden email]>

>
>
>
>
>
>
>>> .
>
>>> For more options, visit this group at
>
>>> http://groups.google.com/group/jquery-dev?hl=en.
>
>>>
>
>>>
>
>>>
>
>>
>
>> --
>
>>
>
>> You received this message because you are subscribed to the Google
Groups

>
>> "jQuery Development" group.
>
>> To post to this group, send email to [hidden email].
>
>> To unsubscribe from this group, send email to
>
>> [hidden email].
>
>> For more options, visit this group at
>
>> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
> --
>
>
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
>
> To post to this group, send email to [hidden email].
>
> To unsubscribe from this group, send email to
> [hidden email].
>
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
>
>
> To post to this group, send email to [hidden email].
>
>
> To unsubscribe from this group, send email to
> [hidden email].
>
>
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
>
>
> To post to this group, send email to [hidden email].
>
>
> To unsubscribe from this group, send email to
> [hidden email].
>
>
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
>
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
>
>
> To post to this group, send email to [hidden email].
>
>
> To unsubscribe from this group, send email to
> [hidden email].
>
>
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: REVISED GOALS - Feature Request: $.ajax(): Detect json via response header

Rick Waldron
I vote YES on all of these.





On Tue, Jan 5, 2010 at 4:55 PM, webbiedave <[hidden email]> wrote:
OK. Not sure where we're at on this but I'm hoping some sort of consensus
can be achieved. Here are the  approaches being bandied about to allow
auto-detect of json (and perhaps other dataTypes):


1) Allow $.ajax() to accept multiple expected data types, i.e., dataTypes:
['json', 'html']. jQuery will attempt to auto-detect only those types.

2) New setting/option to have $.ajax() auto-detect/translate via response
content-type. This will detect/translate any of the supported data types
(and future data types) via the response Content-Type header.

3) Change dataType:null's auto-detect (intelligent guess) to include json.

4) New setting/option to have $.ajax() auto-detect html, xml and json.


Be so kind as to re-vote in case these added details have changed your
minds.





On Tue, 29 Dec 2009 09:46:50 -0500, "Rick Waldron" <[hidden email]>
wrote:
> This is good. #2 has solid support.
>
> John, care to chime in this?
>
>
>
> -- Sent from my Palm Prē
> Julian Aubourg wrote:
>
> So it was pure #2 obviously, not #1.
>
> 2009/12/29 Julian Aubourg <[hidden email]>
>
> Again, why not do this with an Accept header?
> Client
> sends acceptable content types, server responds with a content type, if
> the server's response is one of the accepted types, jQuery processes
> accordingly, if not, jQuery returns data unprocessed.
> The dataType option should be for things that
> aren't necessarily well communicated via content-type alone, like
> JSONP, or anything else that modifies the nature of the request, not
> just the content type.
> If you're worried about your server sending
> malicious javascript, then only accept text/plain or text/xml (even
> dataType: 'html' isn't safe since it executes script blocks). If you
> don't care, then accept "*/*".
>
>
>
>
> There are a couple of reasons why an accept / content-type system is not
> that simple:
> 1) When not specifying a dataType, accept is */* (which makes sense since
> we don't expect a particular dataType) while current behaviour is to
> autodetect xml against text (or, maybe, in future extensions, to
autodetect
> any type). The only workaround if you're basing your tests around the
> accept header would be to associate all of the xx/yy possibilities known
to
> men with their corresponding dataType. The behaviour, as it is now, is to
> group correspondance from content-type to dataType using simple regexps
(ie
> /xml/, /json/) which I find much more efficient and not too configuration
> heavy.
>
>
> 2) It still doesn't address the issue of specifying a set of accepted
> dataTypes just with the dataType property (which is a much better
> abstraction than setting content-type headers in a beforeSend callback or
> globally adding accepted types in ajaxSettings).
>
>
>
> I'm beginning to wonder if we're not buzzing for nothing with this
> conversation. Actually, not specifying a dataType could very well behave
as
> a guess-anything system. In analogy to what you said with content-type,
> setting a dataType will prevent any automatic decision, so existing code
> that would be impacted by automatic json evaluation would just have to
add
> the dataType option, something I don't see as such an atrocious
maintenance
> task it would require some heavy-weight system in jQuery.
>
>
>
> So, the more I think about it, the more I'm in favor of #1.
>
> 2009/12/28 Erik Beeson <[hidden email]>
>
>
> Again, why not do this with an Accept header?
> Client sends acceptable content types, server responds with a content
type,
> if the server's response is one of the accepted types, jQuery processes
> accordingly, if not, jQuery returns data unprocessed.
>
>
>
> The dataType option should be for things that aren't necessarily well
> communicated via content-type alone, like JSONP, or anything else that
> modifies the nature of the request, not just the content type.
>
>
>
> If you're worried about your server sending malicious javascript, then
only
> accept text/plain or text/xml (even dataType: 'html' isn't safe since it
> executes script blocks). If you don't care, then accept "*/*".
>
>
>
> Or am I missing something?
> --Erik
>
> On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron <[hidden email]>
> wrote:
>
>
>
> I can compromise with your #2, and give them both my vote.
>
> Passing it on...
>
>
>
> 1. Allow $.ajax() to accept multiple expected dataTypes.
>
>
>
> 2. Setting to have $.ajax() auto-detect/translate via response
content-type
>
> header.
>
>
>
>
> Julian - your thoughts?
>
>
> On Mon, Dec 28, 2009 at 3:39 PM, webbiedave
> <[hidden email]> wrote:
>
>
>
>
>
> Rick, your 1 (which I too have suggested in the past) might bring about
>
> unease as folks would prefer any eval-ing to come through explicit
request.
>
> I also think it's imperative that the behavior of any dataType setting
>
> (including null) shouldn't change (especially to one that suddenly
evals!).
>
> But that's just my opinion. My 1, 2 would be:
>
>
>
> 1. Allow $.ajax() to accept multiple expected dataTypes.
>
>
>
> 2. Setting to have $.ajax() auto-detect/translate via response
content-type
>
> header.
>
>
>
>
>
>
>
> On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron
> <[hidden email]>
>
> wrote:
>
>>>
>
>>> We're struggling with the best way to inform .ajax() that we expect
>
>>> multiple data types. Either, with a setting like "auto" or by passing
an
>
>>> array of data types (or maybe allowing both).
>
>>>
>
>>
>
>> Perhaps it would help if we defined a list of goals. I'll start.
>
>>
>
>> 1. $.ajax() - if dataType has not been defined in the argument list,
>
>> $.ajax() should respect the returned Content-type header and translate
>
>> accordingly.
>
>>
>
>> 2. ....
>
>>
>
>>
>
>> Fill it in!
>
>>
>
>>
>
>>
>
>>
>
>> Rick
>
>>
>
>>
>
>>
>
>>
>
>>
>
>> On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>
>>
>
>>> We're struggling with the best way to inform .ajax() that we expect
>
>>> multiple data types. Either, with a setting like "auto" or by passing
an
>
>>> array of data types (or maybe allowing both).
>
>>>
>
>>>
>
>>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson
>>> <[hidden email]>
>
>>> wrote:
>
>>> > Seems like a lot of awkward wheel reinventing going on here. Content
>
>>> > type negotiation is a feature of HTTP; is there a reason we aren't
>
>>> > using it?
>
>>> >
>
>>> > --Erik
>
>>> >
>
>>> >
>
>>> > On Saturday, December 26, 2009, webbiedave
>
>>> > <[hidden email]>
>
>>> > wrote:
>
>>> >> "Following your idea that a library has to keep exactly the same
>
>>> >> behavior from versions to versions [...] then what happens if &
>>> >> when
>
>>> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>
>>> >>
>
>>> >> Things could break *without* the introduction of new auto-detectable
>
>>> >> types. If you use "auto" and are only handling json and html and
>
>>> >> suddenly javascript is returned, that javascript will be eval'd and
>
>>> >> things will will not turn out well. That's why you can't use "auto"
>
> on
>
>>> >> untrusted/incompetent servers. That's the whole point of "auto". You
>
>>> >> are trusting the server to return the correct data. Use at your own
>
>>> >> risk. But it's there if you need it.
>
>>> >>
>
>>> >> Having said that, #1 in my suggestions is passing an array
(dataType:
>
>>> >> ["json", html"]).
>
>>> >>
>
>>> >>
>
>>> >>
>
>>> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]>
>>> >> wrote:
>
>>> >>> > As I mentioned in my previous
>
>>> >>> > post, one of this approach's downside is "null vs auto" confusion
>
>>> >>> > as
>
>>> >>> > auto is like null plus more (json, script, future accepted
>
>>> dataTypes).
>
>>> >>> > The whole point is that "auto" means auto-detect type via
>
>>> content-type
>
>>> >>> > headers and null does not mean that (it means guess between html
>
> or
>
>>> >>> > xml)
>
>>> >>>
>
>>> >>> This is exactly where the solution is inconsistent.
>
>>> >>>
>
>>> >>> "auto", in your implementation, does not mean "null plus more
(json,
>
>>> >>> script,
>
>>> >>> *future accepted dataTypes*)" but it just means "null plus json
>>> >>> &
>
>>> >>> script"
>
>>> >>> and only that. Following your idea that a library has to keep
>
> exactly
>
>>> >>> the
>
>>> >>> same behavior from versions to versions (which jQuery broke btw
when
>
>>> >>> ditching the @ syntax for attributes in selectors) then what
happens
>
>>> >>> if
>
>>> >>> &
>
>>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1? You
>
>>> >>> create
>
>>> >>> an "auto2" dataType so that existing code running in 1.4 is
>
>>> >>> unaffected
>
>>> >>> (ie:
>
>>> >>> the new dataType is not auto-detected)? How would you document such
>
> a
>
>>> >>> behaviour? What happens when there's another auto-detectable
>
> dataType
>
>>> >>> introduced in 1.4.2?
>
>>> >>>
>
>>> >>> Giving programmers a way to specify exactly the dataTypes they
>
> expect
>
>>> to
>
>>> >>> be
>
>>> >>> auto-detected is the way to go (would it be with an array or an
>
>>> >>> expression).
>
>>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax code
>
> and
>
>>> >>> you're
>
>>> >>> done: no backward compatibility issue... plus you're safe for
future
>
>>> >>> developments in the dataType auto-detection area.
>
>>> >>>
>
>>> >>> 2009/12/27 webbiedave <[hidden email]>
>
>>> >>>
>
>>> >>> > "Second, auto seems like the weirdest thing ever to me used like
>
> it
>
>>> is
>
>>> >>> > here. So dataType==null and dataType=="auto" act the same for xml
>
>>> >>> > but
>
>>> >>> > not for script & json? Seems completely inconsistant to me."
>
>>> >>>
>
>>> >>> > It's not that weird. I don't think that different settings
>
> yielding
>
>>> >>> > different results is necessarily inconsistent. There are two ways
>
>>> >>> > to
>
>>> >>> > get xml and now there'll be a third. As I mentioned in my
previous
>
>>> >>> > post, one of this approach's downside is "null vs auto" confusion
>
>>> >>> > as
>
>>> >>> > auto is like null plus more (json, script, future accepted
>
>>> dataTypes).
>
>>> >>> > The whole point is that "auto" means auto-detect type via
>
>>> content-type
>
>>> >>> > headers and null does not mean that (it means guess between html
>
> or
>
>>> >>> > xml). It is imperative that the behavior of dataType: null
remains
>
>>> the
>
>>> >>> > same so this is a way to do that while affording multiple
expected
>
>>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't break
>
>>> >>> > existing apps. Quite frankly, it usage makes simple sense to me
>
> and
>
>>> >>> > those who need it will know exactly what it means and how to use
>
> it
>
>>> >>> > (and will be relieved they can ditch their hacked libraries).
>
>>> >>>
>
>>> >>> > "If a coder does not want auto conversion, then he simply
>
> specifies
>
>>> >>> > a
>
>>> >>> > dataType (namely "text")."
>
>>> >>>
>
>>> >>> > But null does not mean auto convert. It means guess between html
>
> or
>
>>> >>> > xml and that cannot change.
>
>>> >>>
>
>>> >>> > "But, please, do not introduce a behavior that will act
>
> differently
>
>>> >>> > for xml than it does for any other dataType deduced from content
>
>>> >>> > type
>
>>> >>> > headers."
>
>>> >>>
>
>>> >>> > I admit I don't share your fear of such behavior and, in fact,
>
>>> greatly
>
>>> >>> > desire such a new setting. I'll know that my live apps that are
>
>>> >>> > using
>
>>> >>> > dataType: null will be unaffected and in the future I'd be able
to
>
>>> >>> > write ajax calls that can respond to various data types. Also,
>
> I've
>
>>> >>> > suggested several approaches and look forward to reading what
>
>>> >>> > others
>
>>> >>> > think of them.
>
>>> >>>
>
>>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>
>>> >>> > wrote:
>
>>> >>> > > Regardless, I'm leaning towards the dataType: "auto" approach
as
>
>>> >>> > > it's easy to use/implement and affords enough control.
>
>>> >>>
>
>>> >>> > > Well, so, first, I translated the dataType to "auto" when it
was
>
>>> >>> > > null/undefined in my rewriting (because I hate messy/undefined
>
>>> >>> > > values).
>
>>> >>> > But
>
>>> >>> > > that's no biggy.
>
>>> >>>
>
>>> >>> > > Second, auto seems like the weirdest thing ever to me used like
>
>>> >>> > > it
>
>>> >>> > > is
>
>>> >>> > here.
>
>>> >>> > > So dataType==null and dataType=="auto" act the same for xml but
>
>>> >>> > > not
>
>>> >>> > > for
>
>>> >>> > > script & json? Seems completely inconsistant to me.
>
>>> >>>
>
>>> >>> > > If a coder does not want auto conversion, then he simply
>
>>> >>> > > specifies
>
>>> a
>
>>> >>> > > dataType (namely "text"). You just have to document it. But,
>
>>> please,
>
>>> >>> > > do
>
>>> >>> > not
>
>>> >>> > > introduce a behavior that will act differentely for xml than it
>
>>> does
>
>>> >>> > > for
>
>>> >>> > any
>
>>> >>> > > other dataType deduced from content type headers.
>
>>> >>>
>
>>> >>> > > 2009/12/26 webbiedave <[hidden email]>
>
>>> >>>
>
>>> >>> > > > I was referring solely to the "bitwise or" style. Regardless,
>
>>> >>> > > > I'm
>
>>> >>> > > > leaning towards the dataType: "auto" approach as it's easy to
>
>>> use/
>
>>> >>> > > > implement and affords enough control.
>
>>> >>>
>
>>> >>> > > > Julian Aubourg wrote:
>
>>> >>>
>
>>> >>> > > > > As for string expressions not being in the calling style of
>
>>> >>> > > > > jQuery...
>
>>> >>> > > > > well... I really disagree here, since jQuery has expression
>
>>> >>> > > > > parsed
>
>>> >>> > parsed
>
>>> >>> > > > > pretty much everywhere ;)
>
>>> >>>
>
>>> >>> > > > --
>
>>> >>>
>
>>> >>> > > > You received this message because you are subscribed to the
>
>>> Google
>
>>> >>> > Groups
>
>>> >>> > > > "jQuery Development" group.
>
>>> >>> > > > To post to this group, send email to
>
>>> >>> > > > [hidden email]
>
>>> .
>
>>> >>> > > > To unsubscribe from this group, send email to
>
>>> >>> > > > > >
>
>>>
>
>
<[hidden email]<[hidden email]>
>
>
>
>
>
>
>>>
>
>
<[hidden email]<[hidden email]>
>
>
>
>
>
>
>>> >
>
>>> >>>
>
>>> >>> > > > .
>
>>> >>> > > > For more options, visit this group at
>
>>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>
>>> >>>
>
>>> >>> > --
>
>>> >>>
>
>>> >>> > You received this message because you are subscribed to the
Google
>
>>> >>> > Groups
>
>>> >>> > "jQuery Development" group.
>
>>> >>> > To post to this group, send email to [hidden email].
>
>>> >>> > To unsubscribe from this group, send email to
>
>>> >>> >
>
>>>
>
>
[hidden email]<[hidden email]>
>
>
>
>
>
>
>>>
>
>
<[hidden email]<[hidden email]>
>
>
>
>
>
>
>>> >
>
>>> >>> > .
>
>>> >>> > For more options, visit this group at
>
>>> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>
>>> >>
>
>>> >> --
>
>>> >>
>
>>> >> You received this message because you are subscribed to the Google
>
>>> Groups
>
>>> >> "jQuery Development" group.
>
>>> >> To post to this group, send email to [hidden email].
>
>>> >> To unsubscribe from this group, send email to
>
>>> >>
>
>
[hidden email]<[hidden email]>
>
>
>
>
>
>
>>> .
>
>>> >> For more options, visit this group at
>
>>> >> http://groups.google.com/group/jquery-dev?hl=en.
>
>>> >>
>
>>> >>
>
>>> >>
>
>>> >
>
>>> > --
>
>>> >
>
>>> > You received this message because you are subscribed to the Google
>
>>> > Groups
>
>>> > "jQuery Development" group.
>
>>> > To post to this group, send email to [hidden email].
>
>>> > To unsubscribe from this group, send email to
>
>>> >
>
>
[hidden email]<[hidden email]>
>
>
>
>
>
>
>>> .
>
>>> > For more options, visit this group at
>
>>> > http://groups.google.com/group/jquery-dev?hl=en.
>
>>>
>
>>> --
>
>>>
>
>>> You received this message because you are subscribed to the Google
>
> Groups
>
>>> "jQuery Development" group.
>
>>> To post to this group, send email to [hidden email].
>
>>> To unsubscribe from this group, send email to
>
>>>
>
>
[hidden email]<[hidden email]>
>
>
>
>
>
>
>>> .
>
>>> For more options, visit this group at
>
>>> http://groups.google.com/group/jquery-dev?hl=en.
>
>>>
>
>>>
>
>>>
>
>>
>
>> --
>
>>
>
>> You received this message because you are subscribed to the Google
Groups
>
>> "jQuery Development" group.
>
>> To post to this group, send email to [hidden email].
>
>> To unsubscribe from this group, send email to
>
>> [hidden email].
>
>> For more options, visit this group at
>
>> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
> --
>
>
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
>
> To post to this group, send email to [hidden email].
>
> To unsubscribe from this group, send email to
> [hidden email].
>
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
>
>
> To post to this group, send email to [hidden email].
>
>
> To unsubscribe from this group, send email to
> [hidden email].
>
>
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
>
>
> To post to this group, send email to [hidden email].
>
>
> To unsubscribe from this group, send email to
> [hidden email].
>
>
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
>
>
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
>
>
> To post to this group, send email to [hidden email].
>
>
> To unsubscribe from this group, send email to
> [hidden email].
>
>
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "jQuery Development" group.
> To post to this group, send email to [hidden email].
> To unsubscribe from this group, send email to
> [hidden email].
> For more options, visit this group at
> http://groups.google.com/group/jquery-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.





--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: REVISED GOALS - Feature Request: $.ajax(): Detect json via response header

webbiedave-2
My vote goes to #1 and #2. Anyone else care to vote or discuss?



On Tue, 5 Jan 2010 18:18:25 -0500, Rick Waldron <[hidden email]>
wrote:

> I vote *YES *on all of these.
>
>
>
>
>
> On Tue, Jan 5, 2010 at 4:55 PM, webbiedave
> <[hidden email]>wrote:
>
>> OK. Not sure where we're at on this but I'm hoping some sort of
consensus
>> can be achieved. Here are the  approaches being bandied about to allow
>> auto-detect of json (and perhaps other dataTypes):
>>
>>
>> 1) Allow $.ajax() to accept multiple expected data types, i.e.,
>> dataTypes:
>> ['json', 'html']. jQuery will attempt to auto-detect only those types.
>>
>> 2) New setting/option to have $.ajax() auto-detect/translate via
response

>> content-type. This will detect/translate any of the supported data types
>> (and future data types) via the response Content-Type header.
>>
>> 3) Change dataType:null's auto-detect (intelligent guess) to include
>> json.
>>
>> 4) New setting/option to have $.ajax() auto-detect html, xml and json.
>>
>>
>> Be so kind as to re-vote in case these added details have changed your
>> minds.
>>
>>
>>
>>
>>
>> On Tue, 29 Dec 2009 09:46:50 -0500, "Rick Waldron"
>> <[hidden email]
>> >
>> wrote:
>> > This is good. #2 has solid support.
>> >
>> > John, care to chime in this?
>> >
>> >
>> >
>> > -- Sent from my Palm Prē
>> > Julian Aubourg wrote:
>> >
>> > So it was pure #2 obviously, not #1.
>> >
>> > 2009/12/29 Julian Aubourg <[hidden email]>
>> >
>> > Again, why not do this with an Accept header?
>> > Client
>> > sends acceptable content types, server responds with a content type,
if

>> > the server's response is one of the accepted types, jQuery processes
>> > accordingly, if not, jQuery returns data unprocessed.
>> > The dataType option should be for things that
>> > aren't necessarily well communicated via content-type alone, like
>> > JSONP, or anything else that modifies the nature of the request, not
>> > just the content type.
>> > If you're worried about your server sending
>> > malicious javascript, then only accept text/plain or text/xml (even
>> > dataType: 'html' isn't safe since it executes script blocks). If you
>> > don't care, then accept "*/*".
>> >
>> >
>> >
>> >
>> > There are a couple of reasons why an accept / content-type system is
>> > not
>> > that simple:
>> > 1) When not specifying a dataType, accept is */* (which makes sense
>> > since
>> > we don't expect a particular dataType) while current behaviour is to
>> > autodetect xml against text (or, maybe, in future extensions, to
>> autodetect
>> > any type). The only workaround if you're basing your tests around the
>> > accept header would be to associate all of the xx/yy possibilities
>> > known
>> to
>> > men with their corresponding dataType. The behaviour, as it is now, is
>> > to
>> > group correspondance from content-type to dataType using simple
regexps

>> (ie
>> > /xml/, /json/) which I find much more efficient and not too
>> > configuration
>> > heavy.
>> >
>> >
>> > 2) It still doesn't address the issue of specifying a set of accepted
>> > dataTypes just with the dataType property (which is a much better
>> > abstraction than setting content-type headers in a beforeSend callback
>> > or
>> > globally adding accepted types in ajaxSettings).
>> >
>> >
>> >
>> > I'm beginning to wonder if we're not buzzing for nothing with this
>> > conversation. Actually, not specifying a dataType could very well
>> > behave
>> as
>> > a guess-anything system. In analogy to what you said with
content-type,

>> > setting a dataType will prevent any automatic decision, so existing
>> > code
>> > that would be impacted by automatic json evaluation would just have to
>> add
>> > the dataType option, something I don't see as such an atrocious
>> maintenance
>> > task it would require some heavy-weight system in jQuery.
>> >
>> >
>> >
>> > So, the more I think about it, the more I'm in favor of #1.
>> >
>> > 2009/12/28 Erik Beeson <[hidden email]>
>> >
>> >
>> > Again, why not do this with an Accept header?
>> > Client sends acceptable content types, server responds with a content
>> type,
>> > if the server's response is one of the accepted types, jQuery
processes

>> > accordingly, if not, jQuery returns data unprocessed.
>> >
>> >
>> >
>> > The dataType option should be for things that aren't necessarily well
>> > communicated via content-type alone, like JSONP, or anything else that
>> > modifies the nature of the request, not just the content type.
>> >
>> >
>> >
>> > If you're worried about your server sending malicious javascript, then
>> only
>> > accept text/plain or text/xml (even dataType: 'html' isn't safe since
>> > it
>> > executes script blocks). If you don't care, then accept "*/*".
>> >
>> >
>> >
>> > Or am I missing something?
>> > --Erik
>> >
>> > On Mon, Dec 28, 2009 at 12:51 PM, Rick Waldron
<[hidden email]>

>> > wrote:
>> >
>> >
>> >
>> > I can compromise with your #2, and give them both my vote.
>> >
>> > Passing it on...
>> >
>> >
>> >
>> > 1. Allow $.ajax() to accept multiple expected dataTypes.
>> >
>> >
>> >
>> > 2. Setting to have $.ajax() auto-detect/translate via response
>> content-type
>> >
>> > header.
>> >
>> >
>> >
>> >
>> > Julian - your thoughts?
>> >
>> >
>> > On Mon, Dec 28, 2009 at 3:39 PM, webbiedave
>> > <[hidden email]> wrote:
>> >
>> >
>> >
>> >
>> >
>> > Rick, your 1 (which I too have suggested in the past) might bring
about

>> >
>> > unease as folks would prefer any eval-ing to come through explicit
>> request.
>> >
>> > I also think it's imperative that the behavior of any dataType setting
>> >
>> > (including null) shouldn't change (especially to one that suddenly
>> evals!).
>> >
>> > But that's just my opinion. My 1, 2 would be:
>> >
>> >
>> >
>> > 1. Allow $.ajax() to accept multiple expected dataTypes.
>> >
>> >
>> >
>> > 2. Setting to have $.ajax() auto-detect/translate via response
>> content-type
>> >
>> > header.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Mon, 28 Dec 2009 15:03:22 -0500, Rick Waldron
>> > <[hidden email]>
>> >
>> > wrote:
>> >
>> >>>
>> >
>> >>> We're struggling with the best way to inform .ajax() that we expect
>> >
>> >>> multiple data types. Either, with a setting like "auto" or by
passing

>> an
>> >
>> >>> array of data types (or maybe allowing both).
>> >
>> >>>
>> >
>> >>
>> >
>> >> Perhaps it would help if we defined a list of goals. I'll start.
>> >
>> >>
>> >
>> >> 1. $.ajax() - if dataType has not been defined in the argument list,
>> >
>> >> $.ajax() should respect the returned Content-type header and
translate

>> >
>> >> accordingly.
>> >
>> >>
>> >
>> >> 2. ....
>> >
>> >>
>> >
>> >>
>> >
>> >> Fill it in!
>> >
>> >>
>> >
>> >>
>> >
>> >>
>> >
>> >>
>> >
>> >> Rick
>> >
>> >>
>> >
>> >>
>> >
>> >>
>> >
>> >>
>> >
>> >>
>> >
>> >> On Sun, Dec 27, 2009 at 7:41 PM, <[hidden email]> wrote:
>> >
>> >>
>> >
>> >>> We're struggling with the best way to inform .ajax() that we expect
>> >
>> >>> multiple data types. Either, with a setting like "auto" or by
passing

>> an
>> >
>> >>> array of data types (or maybe allowing both).
>> >
>> >>>
>> >
>> >>>
>> >
>> >>> On Sun, 27 Dec 2009 12:02:54 -0800, Erik Beeson
>> >>> <[hidden email]>
>> >
>> >>> wrote:
>> >
>> >>> > Seems like a lot of awkward wheel reinventing going on here.
>> >>> > Content
>> >
>> >>> > type negotiation is a feature of HTTP; is there a reason we aren't
>> >
>> >>> > using it?
>> >
>> >>> >
>> >
>> >>> > --Erik
>> >
>> >>> >
>> >
>> >>> >
>> >
>> >>> > On Saturday, December 26, 2009, webbiedave
>> >
>> >>> > <[hidden email]>
>> >
>> >>> > wrote:
>> >
>> >>> >> "Following your idea that a library has to keep exactly the same
>> >
>> >>> >> behavior from versions to versions [...] then what happens if &
>> >>> >> when
>> >
>> >>> >> jQuery introduces a new auto-detectable dataType in 1.4.1"
>> >
>> >>> >>
>> >
>> >>> >> Things could break *without* the introduction of new
>> >>> >> auto-detectable
>> >
>> >>> >> types. If you use "auto" and are only handling json and html and
>> >
>> >>> >> suddenly javascript is returned, that javascript will be eval'd
>> >>> >> and
>> >
>> >>> >> things will will not turn out well. That's why you can't use
>> >>> >> "auto"
>> >
>> > on
>> >
>> >>> >> untrusted/incompetent servers. That's the whole point of "auto".
>> >>> >> You
>> >
>> >>> >> are trusting the server to return the correct data. Use at your
>> >>> >> own
>> >
>> >>> >> risk. But it's there if you need it.
>> >
>> >>> >>
>> >
>> >>> >> Having said that, #1 in my suggestions is passing an array
>> (dataType:
>> >
>> >>> >> ["json", html"]).
>> >
>> >>> >>
>> >
>> >>> >>
>> >
>> >>> >>
>> >
>> >>> >> On Dec 26, 6:41 pm, Julian Aubourg <[hidden email]>
>> >>> >> wrote:
>> >
>> >>> >>> > As I mentioned in my previous
>> >
>> >>> >>> > post, one of this approach's downside is "null vs auto"
>> >>> >>> > confusion
>> >
>> >>> >>> > as
>> >
>> >>> >>> > auto is like null plus more (json, script, future accepted
>> >
>> >>> dataTypes).
>> >
>> >>> >>> > The whole point is that "auto" means auto-detect type via
>> >
>> >>> content-type
>> >
>> >>> >>> > headers and null does not mean that (it means guess between
>> >>> >>> > html
>> >
>> > or
>> >
>> >>> >>> > xml)
>> >
>> >>> >>>
>> >
>> >>> >>> This is exactly where the solution is inconsistent.
>> >
>> >>> >>>
>> >
>> >>> >>> "auto", in your implementation, does not mean "null plus more
>> (json,
>> >
>> >>> >>> script,
>> >
>> >>> >>> *future accepted dataTypes*)" but it just means "null plus json
>> >>> >>> &
>> >
>> >>> >>> script"
>> >
>> >>> >>> and only that. Following your idea that a library has to keep
>> >
>> > exactly
>> >
>> >>> >>> the
>> >
>> >>> >>> same behavior from versions to versions (which jQuery broke btw
>> when
>> >
>> >>> >>> ditching the @ syntax for attributes in selectors) then what
>> happens
>> >
>> >>> >>> if
>> >
>> >>> >>> &
>> >
>> >>> >>> when jQuery introduces a new auto-detectable dataType in 1.4.1?
>> >>> >>> You
>> >
>> >>> >>> create
>> >
>> >>> >>> an "auto2" dataType so that existing code running in 1.4 is
>> >
>> >>> >>> unaffected
>> >
>> >>> >>> (ie:
>> >
>> >>> >>> the new dataType is not auto-detected)? How would you document
>> >>> >>> such
>> >
>> > a
>> >
>> >>> >>> behaviour? What happens when there's another auto-detectable
>> >
>> > dataType
>> >
>> >>> >>> introduced in 1.4.2?
>> >
>> >>> >>>
>> >
>> >>> >>> Giving programmers a way to specify exactly the dataTypes they
>> >
>> > expect
>> >
>> >>> to
>> >
>> >>> >>> be
>> >
>> >>> >>> auto-detected is the way to go (would it be with an array or an
>> >
>> >>> >>> expression).
>> >
>> >>> >>> Just add a s.dataType = s.dataType || [text,xml] in the ajax
code

>> >
>> > and
>> >
>> >>> >>> you're
>> >
>> >>> >>> done: no backward compatibility issue... plus you're safe for
>> future
>> >
>> >>> >>> developments in the dataType auto-detection area.
>> >
>> >>> >>>
>> >
>> >>> >>> 2009/12/27 webbiedave <[hidden email]>
>> >
>> >>> >>>
>> >
>> >>> >>> > "Second, auto seems like the weirdest thing ever to me used
>> >>> >>> > like
>> >
>> > it
>> >
>> >>> is
>> >
>> >>> >>> > here. So dataType==null and dataType=="auto" act the same for
>> >>> >>> > xml
>> >
>> >>> >>> > but
>> >
>> >>> >>> > not for script & json? Seems completely inconsistant to me."
>> >
>> >>> >>>
>> >
>> >>> >>> > It's not that weird. I don't think that different settings
>> >
>> > yielding
>> >
>> >>> >>> > different results is necessarily inconsistent. There are two
>> >>> >>> > ways
>> >
>> >>> >>> > to
>> >
>> >>> >>> > get xml and now there'll be a third. As I mentioned in my
>> previous
>> >
>> >>> >>> > post, one of this approach's downside is "null vs auto"
>> >>> >>> > confusion
>> >
>> >>> >>> > as
>> >
>> >>> >>> > auto is like null plus more (json, script, future accepted
>> >
>> >>> dataTypes).
>> >
>> >>> >>> > The whole point is that "auto" means auto-detect type via
>> >
>> >>> content-type
>> >
>> >>> >>> > headers and null does not mean that (it means guess between
>> >>> >>> > html
>> >
>> > or
>> >
>> >>> >>> > xml). It is imperative that the behavior of dataType: null
>> remains
>> >
>> >>> the
>> >
>> >>> >>> > same so this is a way to do that while affording multiple
>> expected
>> >
>> >>> >>> > dataTypes in a way that's secure, doesn't bloat and doesn't
>> >>> >>> > break
>> >
>> >>> >>> > existing apps. Quite frankly, it usage makes simple sense to
me

>> >
>> > and
>> >
>> >>> >>> > those who need it will know exactly what it means and how to
>> >>> >>> > use
>> >
>> > it
>> >
>> >>> >>> > (and will be relieved they can ditch their hacked libraries).
>> >
>> >>> >>>
>> >
>> >>> >>> > "If a coder does not want auto conversion, then he simply
>> >
>> > specifies
>> >
>> >>> >>> > a
>> >
>> >>> >>> > dataType (namely "text")."
>> >
>> >>> >>>
>> >
>> >>> >>> > But null does not mean auto convert. It means guess between
>> >>> >>> > html
>> >
>> > or
>> >
>> >>> >>> > xml and that cannot change.
>> >
>> >>> >>>
>> >
>> >>> >>> > "But, please, do not introduce a behavior that will act
>> >
>> > differently
>> >
>> >>> >>> > for xml than it does for any other dataType deduced from
>> >>> >>> > content
>> >
>> >>> >>> > type
>> >
>> >>> >>> > headers."
>> >
>> >>> >>>
>> >
>> >>> >>> > I admit I don't share your fear of such behavior and, in fact,
>> >
>> >>> greatly
>> >
>> >>> >>> > desire such a new setting. I'll know that my live apps that
are
>> >
>> >>> >>> > using
>> >
>> >>> >>> > dataType: null will be unaffected and in the future I'd be
able

>> to
>> >
>> >>> >>> > write ajax calls that can respond to various data types. Also,
>> >
>> > I've
>> >
>> >>> >>> > suggested several approaches and look forward to reading what
>> >
>> >>> >>> > others
>> >
>> >>> >>> > think of them.
>> >
>> >>> >>>
>> >
>> >>> >>> > On Dec 26, 3:47 pm, Julian Aubourg <[hidden email]>
>> >
>> >>> >>> > wrote:
>> >
>> >>> >>> > > Regardless, I'm leaning towards the dataType: "auto"
approach

>> as
>> >
>> >>> >>> > > it's easy to use/implement and affords enough control.
>> >
>> >>> >>>
>> >
>> >>> >>> > > Well, so, first, I translated the dataType to "auto" when it
>> was
>> >
>> >>> >>> > > null/undefined in my rewriting (because I hate
>> >>> >>> > > messy/undefined
>> >
>> >>> >>> > > values).
>> >
>> >>> >>> > But
>> >
>> >>> >>> > > that's no biggy.
>> >
>> >>> >>>
>> >
>> >>> >>> > > Second, auto seems like the weirdest thing ever to me used
>> >>> >>> > > like
>> >
>> >>> >>> > > it
>> >
>> >>> >>> > > is
>> >
>> >>> >>> > here.
>> >
>> >>> >>> > > So dataType==null and dataType=="auto" act the same for xml
>> >>> >>> > > but
>> >
>> >>> >>> > > not
>> >
>> >>> >>> > > for
>> >
>> >>> >>> > > script & json? Seems completely inconsistant to me.
>> >
>> >>> >>>
>> >
>> >>> >>> > > If a coder does not want auto conversion, then he simply
>> >
>> >>> >>> > > specifies
>> >
>> >>> a
>> >
>> >>> >>> > > dataType (namely "text"). You just have to document it. But,
>> >
>> >>> please,
>> >
>> >>> >>> > > do
>> >
>> >>> >>> > not
>> >
>> >>> >>> > > introduce a behavior that will act differentely for xml than
>> >>> >>> > > it
>> >
>> >>> does
>> >
>> >>> >>> > > for
>> >
>> >>> >>> > any
>> >
>> >>> >>> > > other dataType deduced from content type headers.
>> >
>> >>> >>>
>> >
>> >>> >>> > > 2009/12/26 webbiedave <[hidden email]>
>> >
>> >>> >>>
>> >
>> >>> >>> > > > I was referring solely to the "bitwise or" style.
>> >>> >>> > > > Regardless,
>> >
>> >>> >>> > > > I'm
>> >
>> >>> >>> > > > leaning towards the dataType: "auto" approach as it's easy
>> >>> >>> > > > to
>> >
>> >>> use/
>> >
>> >>> >>> > > > implement and affords enough control.
>> >
>> >>> >>>
>> >
>> >>> >>> > > > Julian Aubourg wrote:
>> >
>> >>> >>>
>> >
>> >>> >>> > > > > As for string expressions not being in the calling style
>> >>> >>> > > > > of
>> >
>> >>> >>> > > > > jQuery...
>> >
>> >>> >>> > > > > well... I really disagree here, since jQuery has
>> >>> >>> > > > > expression
>> >
>> >>> >>> > > > > parsed
>> >
>> >>> >>> > parsed
>> >
>> >>> >>> > > > > pretty much everywhere ;)
>> >
>> >>> >>>
>> >
>> >>> >>> > > > --
>> >
>> >>> >>>
>> >
>> >>> >>> > > > You received this message because you are subscribed to
the

>> >
>> >>> Google
>> >
>> >>> >>> > Groups
>> >
>> >>> >>> > > > "jQuery Development" group.
>> >
>> >>> >>> > > > To post to this group, send email to
>> >
>> >>> >>> > > > [hidden email]
>> >
>> >>> .
>> >
>> >>> >>> > > > To unsubscribe from this group, send email to
>> >
>> >>> >>> > > > > >
>> >
>> >>>
>> >
>> >
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >>>
>> >
>> >
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >>> >
>> >
>> >>> >>>
>> >
>> >>> >>> > > > .
>> >
>> >>> >>> > > > For more options, visit this group at
>> >
>> >>> >>> > > >http://groups.google.com/group/jquery-dev?hl=en.
>> >
>> >>> >>>
>> >
>> >>> >>> > --
>> >
>> >>> >>>
>> >
>> >>> >>> > You received this message because you are subscribed to the
>> Google
>> >
>> >>> >>> > Groups
>> >
>> >>> >>> > "jQuery Development" group.
>> >
>> >>> >>> > To post to this group, send email to
>> >>> >>> > [hidden email]
>> .
>> >
>> >>> >>> > To unsubscribe from this group, send email to
>> >
>> >>> >>> >
>> >
>> >>>
>> >
>> >
>>
[hidden email]<jquery-dev%[hidden email]>
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >>>
>> >
>> >
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >>> >
>> >
>> >>> >>> > .
>> >
>> >>> >>> > For more options, visit this group at
>> >
>> >>> >>> >http://groups.google.com/group/jquery-dev?hl=en.
>> >
>> >>> >>
>> >
>> >>> >> --
>> >
>> >>> >>
>> >
>> >>> >> You received this message because you are subscribed to the
Google

>> >
>> >>> Groups
>> >
>> >>> >> "jQuery Development" group.
>> >
>> >>> >> To post to this group, send email to [hidden email].
>> >
>> >>> >> To unsubscribe from this group, send email to
>> >
>> >>> >>
>> >
>> >
>>
[hidden email]<jquery-dev%[hidden email]>
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >>> .
>> >
>> >>> >> For more options, visit this group at
>> >
>> >>> >> http://groups.google.com/group/jquery-dev?hl=en.
>> >
>> >>> >>
>> >
>> >>> >>
>> >
>> >>> >>
>> >
>> >>> >
>> >
>> >>> > --
>> >
>> >>> >
>> >
>> >>> > You received this message because you are subscribed to the Google
>> >
>> >>> > Groups
>> >
>> >>> > "jQuery Development" group.
>> >
>> >>> > To post to this group, send email to [hidden email].
>> >
>> >>> > To unsubscribe from this group, send email to
>> >
>> >>> >
>> >
>> >
>>
[hidden email]<jquery-dev%[hidden email]>
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >>> .
>> >
>> >>> > For more options, visit this group at
>> >
>> >>> > http://groups.google.com/group/jquery-dev?hl=en.
>> >
>> >>>
>> >
>> >>> --
>> >
>> >>>
>> >
>> >>> You received this message because you are subscribed to the Google
>> >
>> > Groups
>> >
>> >>> "jQuery Development" group.
>> >
>> >>> To post to this group, send email to [hidden email].
>> >
>> >>> To unsubscribe from this group, send email to
>> >
>> >>>
>> >
>> >
>>
[hidden email]<jquery-dev%[hidden email]>
>>
<jquery-dev%[hidden email]<jquery-dev%[hidden email]>

>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >>> .
>> >
>> >>> For more options, visit this group at
>> >
>> >>> http://groups.google.com/group/jquery-dev?hl=en.
>> >
>> >>>
>> >
>> >>>
>> >
>> >>>
>> >
>> >>
>> >
>> >> --
>> >
>> >>
>> >
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >
>> >> "jQuery Development" group.
>> >
>> >> To post to this group, send email to [hidden email].
>> >
>> >> To unsubscribe from this group, send email to
>> >
>> >>
[hidden email]<jquery-dev%[hidden email]>

>> .
>> >
>> >> For more options, visit this group at
>> >
>> >> http://groups.google.com/group/jquery-dev?hl=en.
>> >
>> >
>> >
>> > --
>> >
>> >
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> >
>> > To post to this group, send email to [hidden email].
>> >
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<jquery-dev%[hidden email]>

>> .
>> >
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> >
>> >
>> > To post to this group, send email to [hidden email].
>> >
>> >
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<jquery-dev%[hidden email]>

>> .
>> >
>> >
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> >
>> >
>> > To post to this group, send email to [hidden email].
>> >
>> >
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<jquery-dev%[hidden email]>

>> .
>> >
>> >
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> >
>> >
>> > To post to this group, send email to [hidden email].
>> >
>> >
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<jquery-dev%[hidden email]>

>> .
>> >
>> >
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>> >
>> >
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "jQuery Development" group.
>> > To post to this group, send email to [hidden email].
>> > To unsubscribe from this group, send email to
>> >
[hidden email]<jquery-dev%[hidden email]>
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/jquery-dev?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "jQuery Development" group.
>> To post to this group, send email to [hidden email].
>> To unsubscribe from this group, send email to
>>
[hidden email]<jquery-dev%[hidden email]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/jquery-dev?hl=en.
>>
>>
>>
>>

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.


Reply | Threaded
Open this post in threaded view
|

Re: REVISED GOALS - Feature Request: $.ajax(): Detect json via response header

Rick Waldron
Just wanted to chime in so you know I'm not ignoring the topic and still interested in the enhancement's progress. I still support all four points.


Rick 


--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: REVISED GOALS - Feature Request: $.ajax(): Detect json via response header

webbiedave-2
Rick,

John landed a combination of #2 and #3. httpData will detect/translate data
types (including json and script)
via the response Content-Type header when type is not specified. Thanks for
your input and contributions as well as those from Julian, Tobias and John.

- Dave



On Mon, 11 Jan 2010 16:10:17 -0500, Rick Waldron <[hidden email]>
wrote:
> Just wanted to chime in so you know I'm not ignoring the topic and still
> interested in the enhancement's progress. I still support all four
points.
>
>
> Rick

--
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.