In a REST context, response content availability should not depend on status codes

[f.verry]

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 is false
• if the ajax request successes and the status code is 2xx or 304, isSuccess is true
• if the ajax request successes and the status code is otherwise, isSuccess is false

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.

[dmethvin]

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.