Side navigation
#2733 closed feature (fixed)
Opened April 22, 2008 11:17PM UTC
Closed June 15, 2010 02:22AM UTC
Last modified March 14, 2012 06:13PM UTC
jQuery.ajax should auto-parse response based on Content-Type, if dataType is not specified
| Reported by: | jelly-bean | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 1.3 |
| Component: | ajax | Version: | 1.2.3 |
| Keywords: | Cc: | jelly-bean | |
| Blocked by: | Blocking: |
Description
i have a feature request that when jQuery.ajax({ dataType: is not specified, that instead of only determining whether to returnStatus or returnText or whatever--that it actually looks at the server's reply in the Content-Type header, and uses that instead to parse XML (text/xml), JSON (application/json), JavaScript (text/javascript), Plain-Text/error (e.g. anything else), etc.
this is because often times i will change the content-type based on the response--i like to send errors in plain text because they trigger a parser error which will fire the jQuery.ajax.error(), while any type of SGML seems to work best passed in XML wrapped as CDATA because it requires less escaped characters vs. JSON which is best for any type of objects or data response, and of course JavaScript for letting the server generate the .js and have the script execute whatever it receives.
Attachments (1)
Change History (7)
Changed May 11, 2008 11:22PM UTC by comment:1
| component: | core → ajax |
|---|---|
| type: | enhancement → feature |
Changed May 30, 2008 02:29PM UTC by comment:2
I'm using the httpData.txt patch with a rails application and it's working fine with javascript content.
Changed August 14, 2008 02:31PM UTC by comment:3
Packaged my patch as a plugin:
Changed August 14, 2008 03:15PM UTC by comment:4
| cc: | → jelly-bean |
|---|---|
| milestone: | 1.2.4 → 1.3 |
Note that the code you took from httpData is not up to date.
Check the trunk for the latest version.
Instead of rewriting httpData, you could actually use the new feature (for 1.3). The dataFilter setting of Ajax requests.
Your code could subscribe to the following AjaxFilter plugin that is sort of a manager and parse the data inside.
Changed September 01, 2008 05:51PM UTC by comment:5
The only problem with this approach is that dataFilter doesn't pass the xhr so we can't read the response header and so are forced to horrible string parsing methods to interpolate the response. Since xml has special treatment based on the content-header in the current httpData function I am not sure why other data types are not given the same treatment or why we need to write plugins to handle directives given by the response header.
Changed December 26, 2009 09:41PM UTC by comment:6
I think it's a more secure approach to require an explicit request for auto-detection/parsing. Otherwise, it wouldn't be out of the realm of possibility that scripts could be evaluated simply by leaving dataType unspecified (which many existing apps do).
I've created a ticket for a new dataType setting "auto" which provides this functionality: