Opened 9 years ago
Closed 9 years ago
#15053 closed feature (duplicate)
In a REST context, response content availability should not depend on status codes
Reported by: | f.verry | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | unfiled | Version: | 1.11.0 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
In jQuery.ajax
, the function done()
is executed when the ajax request is completed (successfully or not).
done()
function always evaluates the content received from the xhr call into the variable response
(line 9260).
That response
is only accessible to high-level callbacks when isSuccess
variable evaluates to true
(line 9309).
isSuccess
is set according to the following rules (line 9252) :
- if the ajax request is aborted or fails,
isSuccess
isfalse
- if the ajax request successes and the status code is
2xx
or304
,isSuccess
istrue
- if the ajax request successes and the status code is otherwise,
isSuccess
isfalse
Additionnaly, isSuccess
reverts to false
if parsing the response content failed (line 9290).
This poses a problem when one tries to use $.ajax()
for REST requests. A REST response may provide useful content with many status codes, including 301, 404, 500, etc.
There are multiple ways to interpret the problem, however I suggest a really simple and retro-compatible solution.
The following will escape the status check with an additionnal option inclusiveSuccess
:
line 8928 :
--- context: true +++ context: true, +++ inclusiveSuccess: false
line 9252 :
--- isSuccess = status >= 200 && status < 300 || status === 304; +++ isSuccess = status >= 200 && status < 300 || status === 304 || status > 0 && s.inclusiveSuccess;
The consequences of this solution are extensive :
- {{{success}} callback will be called for every status code, given that the ajax request succeeded and the content is parsed successfully.
- all
statusCode
callbacks will be called with the first argument representing parsed content (not just 2xx and 304 callbacks)
Another solution is to give access to ajaxHandleResponses()
and ajaxConvert()
functions, which currently are not accessible outside the jQuery definition. With this workaround, it would be possible to manage the response through the complete
callback and its jqXHR
argument.
A third solution would be to develop a specific $.rest()
client interface, with a dedicated behavior.
Duplicate of #14509.
It's a consequence of trying to read intent for the most common cases, which the
$.ajax()
interface generally does well. It just falls apart horribly for the edge cases like this.We're working on a much thinner
$.xhr()
interface for XHR which would not apply magic, but given the widespread use of$.ajax()
we really can't change what it does without breaking a lot of code.