Loading...

jquery-dev@googlegroups.com

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [jquery-dev] GOALS? Feature Request: $.ajax(): Detect json via response header webbiedave Tue Dec 29 09:00:07 2009

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
>>> <[EMAIL PROTECTED]>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
>>>> <[EMAIL PROTECTED]
>>>> > 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 <
>>>>> [EMAIL PROTECTED]>
>>>>> 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, <[EMAIL PROTECTED]>
>>>>> > 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 <
>>>>> [EMAIL PROTECTED]>
>>>>> >> 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
>>>>> >> > <[EMAIL PROTECTED]>
>>>>> >> > 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 <[EMAIL PROTECTED]>
>>>>> 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 <[EMAIL PROTECTED]>
>>>>> >> >>>
>>>>> >> >>> > "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
<[EMAIL PROTECTED]>
>>>>> >> >>> > 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 <[EMAIL PROTECTED]>
>>>>> >> >>>
>>>>> >> >>> > > > 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
>>>>> >> >>> > > > [EMAIL PROTECTED]
>>>>> >> .
>>>>> >> >>> > > > To unsubscribe from this group, send email to
>>>>> >> >>> > > > > >
>>>>> >>
>>>>>
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>>
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>> >
>>>>> >>
>>>>>
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>>
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>> >
>>>>> >> >
>>>>> >> >>>
>>>>> >> >>> > > > .
>>>>> >> >>> > > > 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
>>>>> [EMAIL PROTECTED]
>>>>> >> >>> > To unsubscribe from this group, send email to
>>>>> >> >>> >
>>>>> >>
>>>>>
[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>>
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>> >
>>>>> >>
>>>>>
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>>
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>> >
>>>>> >> >
>>>>> >> >>> > .
>>>>> >> >>> > 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
>>>>> >> >> [EMAIL PROTECTED]
>>>>> >> >> To unsubscribe from this group, send email to
>>>>> >> >>
>>>>>
[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>>
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>> >
>>>>> >> .
>>>>> >> >> 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
[EMAIL PROTECTED]
>>>>> >> > To unsubscribe from this group, send email to
>>>>> >> >
>>>>>
[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>>
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>> >
>>>>> >> .
>>>>> >> > 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 [EMAIL PROTECTED]
>>>>> >> To unsubscribe from this group, send email to
>>>>> >>
>>>>>
[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>>
<[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>> >
>>>>> >> .
>>>>> >> 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 [EMAIL PROTECTED]
>>>>> > To unsubscribe from this group, send email to
>>>>> >
[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>> .
>>>>> > 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 [EMAIL PROTECTED]
>>>>> To unsubscribe from this group, send email to
>>>>>
[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>>> .
>>>>> 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 [EMAIL PROTECTED]
>>>> To unsubscribe from this group, send email to
>>>>
[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>>> .
>>>> 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 [EMAIL PROTECTED]
>>> To unsubscribe from this group, send email to
>>>
[EMAIL PROTECTED]<[EMAIL PROTECTED]>
>>> .
>>> 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 [EMAIL PROTECTED]
> To unsubscribe from this group, send email to
> [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en.