Side navigation
#9854 closed enhancement (fixed)
Opened July 18, 2011 03:31PM UTC
Closed July 23, 2011 12:39AM UTC
Last modified July 23, 2011 12:40AM UTC
Pass statusText through instead of "normalizing" it
| Reported by: | Peter Kline <pkline@cdrnys.org> | Owned by: | jaubourg |
|---|---|---|---|
| Priority: | low | Milestone: | 1.6.3 |
| Component: | ajax | Version: | 1.6.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
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.
Attachments (0)
Change History (7)
Changed July 19, 2011 04:21AM UTC by comment:1
Changed July 21, 2011 11:42PM UTC by comment:2
| component: | unfiled → ajax |
|---|---|
| milestone: | None → 1.next |
| owner: | → jaubourg |
| priority: | undecided → low |
| status: | new → assigned |
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?
Changed July 22, 2011 01:11AM UTC by comment:5
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.
Changed July 23, 2011 12:39AM UTC by comment:6
| resolution: | → fixed |
|---|---|
| status: | assigned → closed |
Fixes #9854: propagates native statusText onto jqXHR.statusText. statusText in callbacks is still normalized. Unit test added.
Changeset: 0ed99097bda3bb6e302c3d93331f0e7312e42077
Changed July 23, 2011 12:40AM UTC by comment:7
| milestone: | 1.next → 1.6.3 |
|---|
Thank you bug....