Pass statusText through instead of "normalizing" it

[Peter Kline <[email protected]…>]

This enhancement request refers to ticket #8987 and #8534.

When creating an ajax request, jQuery normalizes the server response text (statusText) to "success", "error", etc. This hasn't always been the case - in a 1.4.x version we used, it passed this through.

I understand the normalization rationale, but I think it's short-sighted. Rather than returning basic error messages in an HTML/XML/JSON body (and then having to parse it), it's a lot easier to return small messages in the HTTP header than creating content (HTTP/1.0 406 Subject Cannot Be Blank, HTTP/1.0 204 No Search Results Found). In our specific case, these are often validation messages for the user.

I could return text/plain error messages, but again - that's more work and code on the server and traffic on the wire where not necessary.

On the flip side, jQuery already allows you to pass functions for error and success, as well as per status code, and it preserves the code itself.

If you wish to preserve the normalized text, I'd be happy to convert my code to access to differently named property (httpHeaderText?) with the preserved text (though I'd prefer to keep my code the way it is).

Thanks.

[[email protected]…]

Thank you bug....

[jaubourg]

I honestly think using an HTTP statusText as some kind of parsable error data (how soon before it's in json to boot ;)) to be a very bad idea and some kind of hijacking of the protocol but heh, I can bite no matter how short-sighted I am :P

The question is, would it make sense to keep the normalized statusText in the callbacks and only provide the original statusText on the jqXHR object?

[jaubourg]

#8534 is a duplicate of this ticket.

[jaubourg]

#8987 is a duplicate of this ticket.

[[email protected]…]

At some level I agree with you - I don't suspect the designers of the HTTP protocol meant for the status text to be more than a textual description of the status, so passing parsable data would be a misuse (and bad design: the size and character set is limited). But, for simple textual elaboration of the specific status code, I think it is more than appropriate (and useful). If a submission was rejected and the server sends brief elaboration text it makes sense (at least to me) as opposed to the overhead of a full XML or JSON reply.

I suppose rope has many uses, but you shouldn't take it off the market because people do dumb things with it.

As for where in jQuery: I would like it returned to the 1.4.x behavior of keeping the original text in the property. You already provide a callback for error, success, etc - and people moving to jQuery have a consistent interface. Keeping the original text also restores backward compatibility. Perhaps the normalized text could become a new property (.requestOutcome) or a set of booleans (.isSuccess)?

Either way I sincerely appreciate you looking at this.

[jaubourg]

Fixes #9854: propagates native statusText onto jqXHR.statusText. statusText in callbacks is still normalized. Unit test added.

Changeset: 0ed99097bda3bb6e302c3d93331f0e7312e42077