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" <waldron.r...@gmail.com> 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 <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> > > > > > > >>> > > >>> >>> > >>> >>> > > > . > >>> >>> > > > 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. > >> 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. > > > > > > > > > > > > > -- > > 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. > > > > > > > > > > -- > > 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. > > > > > > > > > > > > -- > > 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. > > > > -- > > 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.
-- 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.
