Ticket #2733 (closed feature: fixed)
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 | |
| Blocking: | Blocked by: |
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
Change History
comment:1 Changed 5 years ago by flesler
- Type changed from enhancement to feature
- Component changed from core to ajax
Changed 5 years ago by derencius
-
attachment
patch_httpData.txt
added
a simple patch. tests are needed
comment:2 Changed 5 years ago by derencius
I'm using the httpData.txt patch with a rails application and it's working fine with javascript content.
comment:3 Changed 5 years ago by derencius
Packaged my patch as a plugin: http://plugins.jquery.com/project/apcth
comment:4 follow-up: ↓ 5 Changed 5 years ago by flesler
- Cc jelly-bean added
- Milestone changed from 1.2.4 to 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.
comment:5 in reply to: ↑ 4 Changed 5 years ago by mnichols
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.
comment:6 Changed 3 years ago by webbiedave
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:
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.
