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 <erik.bee...@gmail.com> 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 <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.
