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.
