So it was pure #2 obviously, not #1. 2009/12/29 Julian Aubourg <aubourg.jul...@gmail.com>
> 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 <erik.bee...@gmail.com> > > 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 <waldron.r...@gmail.com>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 <webbied...@websiteguard.com >>> > 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 < >>>> waldron.r...@gmail.com> >>>> 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, <webbied...@websiteguard.com> 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 < >>>> erik.bee...@gmail.com> >>>> >> 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 >>>> >> > <webbied...@websiteguard.com> >>>> >> > 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 <aubourg.jul...@gmail.com> >>>> 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 <webbied...@websiteguard.com> >>>> >> >>> >>>> >> >>> > "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 <aubourg.jul...@gmail.com> >>>> >> >>> > 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 <webbied...@websiteguard.com> >>>> >> >>> >>>> >> >>> > > > 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 >>>> >> >>> > > > jquery-dev@googlegroups.com >>>> >> . >>>> >> >>> > > > To unsubscribe from this group, send email to >>>> >> >>> > > > > > >>>> >> >>>> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >>>> <jquery-dev%252bunsubscr...@googlegroups.com<jquery-dev%25252bunsubscr...@googlegroups.com> >>>> > >>>> >> >>>> <jquery-dev%252bunsubscr...@googlegroups.com<jquery-dev%25252bunsubscr...@googlegroups.com> >>>> <jquery-dev%25252bunsubscr...@googlegroups.com<jquery-dev%2525252bunsubscr...@googlegroups.com> >>>> > >>>> >> > >>>> >> >>> >>>> >> >>> > > > . >>>> >> >>> > > > 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 >>>> jquery-...@googlegroups.com. >>>> >> >>> > To unsubscribe from this group, send email to >>>> >> >>> > >>>> >> >>>> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >>>> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >>>> > >>>> >> >>>> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >>>> <jquery-dev%252bunsubscr...@googlegroups.com<jquery-dev%25252bunsubscr...@googlegroups.com> >>>> > >>>> >> > >>>> >> >>> > . >>>> >> >>> > 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 jquery-...@googlegroups.com. >>>> >> >> To unsubscribe from this group, send email to >>>> >> >> >>>> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >>>> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >>>> > >>>> >> . >>>> >> >> 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 jquery-...@googlegroups.com. >>>> >> > To unsubscribe from this group, send email to >>>> >> > >>>> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >>>> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >>>> > >>>> >> . >>>> >> > 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 jquery-...@googlegroups.com. >>>> >> To unsubscribe from this group, send email to >>>> >> >>>> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >>>> <jquery-dev%2bunsubscr...@googlegroups.com<jquery-dev%252bunsubscr...@googlegroups.com> >>>> > >>>> >> . >>>> >> 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 jquery-...@googlegroups.com. >>>> > To unsubscribe from this group, send email to >>>> > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >>>> . >>>> > 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 jquery-...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >>>> . >>>> 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 jquery-...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >>> . >>> 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 jquery-...@googlegroups.com. >> To unsubscribe from this group, send email to >> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com> >> . >> 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 jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
