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