I've created a new ticket on this:
http://dev.jquery.com/ticket/5718
I also commented on the two existing tickets that deal with detection/
parsing via content-type header (#4515, #5709).
On Dec 26, 2:23 pm, webbiedave <webbied...@websiteguard.com> wrote:
> Here's the code for dataType: "auto". I'm now using it in a content
> management app and it works well. Previous dataType behavior remains
> exactly the same so the change will be invisible to existing apps:
>
> httpData: function( xhr, type, s ) {
> var ct = xhr.getResponseHeader("content-type"),
> xml = type == "xml" || (!type || type == "auto") && ct &&
> ct.indexOf
> ("xml") >= 0,
> data = xml ? xhr.responseXML : xhr.responseText;
>
> if ( xml && data.documentElement.tagName == "parsererror" )
> throw "parsererror";
>
> // Allow a pre-filtering function to sanitize the response
> // s != null is checked to keep backwards compatibility
> if( s && s.dataFilter )
> data = s.dataFilter( data, type );
>
> // The filter can actually parse the response
> if( typeof data === "string" ){
>
> // If the type is "script", eval it in global context
> if ( type == "script" || (type == "auto" && ct && ct.indexOf
> ("javascript") >= 0) )
> jQuery.globalEval( data );
>
> // Get the JavaScript object, if JSON is used.
> if ( type == "json" || (type == "auto" && ct &&
> ct.indexOf("json")>= 0) )
>
> data = window["eval"]("(" + data + ")");
> }
>
> return data;
>
> }
>
> On Dec 24, 1:49 pm, webbiedave <webbied...@websiteguard.com> wrote:
>
> > I'm also a bit curious as to how I'm going to implement this as I
> > wasn't aware there was already an effort underway to have dataTypes
> > accept an array for a different purpose.
>
> > The "why" is that I don't want to have to limit my returned data to be
> > exclusively either html or json. Much of this can be taken care of on
> > a case-by-case basis in the complete callback but that requires
> > duplicating much of what httpData does.
>
> > So, if my original suggested code (similar to Rick's) is fine with
> > everyone, then great! But Tobias then brought up the issue of server
> > competence when auto-evaling json so I began looking for a way to
> > explicitly specify multiple datatypes.
>
> > Below are some approaches for allowing varying datatypes (you can skip
> > to the conclusion below if you want the short story):
>
> > 1) Create some way to pass multiple expected dataTypes and httpData
> > will do its best to detect which was received.
>
> > This affords the most control but may be difficult to implement
> > elegantly as the obvious choice of an array has already been taken by
> > other functionality. Julian suggested an "or" like string but I'm of
> > the opinion that such a calling style is not cohesive enough with the
> > rest of jquery usage.
>
> > 2) Detect and parse data as json when:
> > content-type == "application/json"
> > && !dataType
>
> > This was my original suggestion. It could -- and has already-- brought
> > about some unease from developers as it isn't out of the realm of
> > possibility that scripts could be eval'd when dataType isn't
> > specified.
>
> > 3) Detect and parse data as json when:
> > content-type == "application/json"
> > && !dataType
> > && parser is available
>
> > This approach deserves a scolding as it alters application behavior
> > depending on whether or not a json parser is present.
>
> > 4) Detect and parse data as json when:
> > content-type == "application/json"
> > && !dataType
> > && autoEval (some new option that will parse script/json if received)
>
> > Yields documentation like "autoEval will only parse the returned
> > content when set to true and dataType has not been specified." Its
> > usage is strange.
>
> > 5) Detect and parse data as json when:
> > content-type == "application/json"
> > && autoEval
>
> > Completely ignores datatype and will eval with code like: dataType:
> > "html", autoEval: true. That just doesn't look great.
>
> > 6) dataType: "auto". httpData will detect xml, html, text, script or
> > json via content-type header.
>
> > This could cause some confusion for developers when they're initially
> > learning the difference between "auto" and dataType's default behavior
> > (xml/html). Obviously, people using this setting should ensure they
> > are calling trusted, competent servers.
>
> > 7) dataType: "auto" and autoEval (defaults to true). Setting autoEval
> > to false returns script/json as text.
>
> > In practice, with the currently allowed dataTypes, you'll just be
> > using dataType's default behavior instead of typing dataType: "auto",
> > autoEval: false.
>
> > CONCLUSION:
>
> > There's something to hate about all of them. I like #6. When you use
> > it, you know exactly what kind of trouble you're getting yourself
> > into.
>
> > On Dec 23, 5:28 pm, Julian Aubourg <aubourg.jul...@gmail.com> wrote:
>
> > > I'm a bit curious as to how (and why) you intend to implement this, seeing
> > > as the ajax revamping I've been working on uses an array of dataTypes.
>
> > > For example s.datTypes = ["jsonp","xml"] means: get an object (a string in
> > > that case) over jsonp that'll get parsed as xml (and this is actually
> > > working and being unit tested ;))
>
> > > If your intention is to give a list of accepted dataTypes, I'd rather go
> > > for
> > > a string of the form "json | xml" if you get my idea.
>
> > > 2009/12/23 webbiedave <webbied...@websiteguard.com>
>
> > > > I'll rewrite so dataType can also accept an array. That way there's
> > > > explicitness. I'll report back after some real world usage.
>
> > > > On Dec 23, 3:56 am, Tobias Hoffmann <smilingt...@googlemail.com>
> > > > wrote:
> > > > > On Wed, Dec 23, 2009 at 5:16 AM, John Resig <jere...@gmail.com> wrote:
> > > > > > Is there an open ticket on this? If so I don't see a reason not to
> > > > > > land
> > > > it.
>
> > > > > Well, if there is no safe json decoder (i.e. just eval()) it's not
> > > > > immediatly clear to me, that I really want this.
> > > > > Yes, all the other jscripts also come from the server and are thus
> > > > somehow
> > > > > equally trustworthy.
> > > > > And the Content-Type on the HTTP header can not easily be spoofed.
> > > > > But I
> > > > > don't want jquery to evaluate some
> > > > > unsafe user content (e.g. CMS, Guestbook, ... ) that wasn't ever
> > > > > meant to
> > > > be
> > > > > json ...
>
> > > > > Tobias
>
> > > > > > Could we change the $.ajax() function to treat the server's response
> > > > > > > as json if dataType is unspecified and the response content-type
> > > > > > > is
> > > > > > > "application/json"?
>
> > > > > > > Thanks,
> > > > > > > Dave
>
> > > > --
>
> > > > 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.
