Side navigation
#8534 closed bug (duplicate)
Opened March 15, 2011 04:51PM UTC
Closed July 21, 2011 11:46PM UTC
Last modified July 21, 2011 11:46PM UTC
ajax bug with successful http statusText
Reported by: | arib | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | 1.next |
Component: | ajax | Version: | 1.5.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
on a successful ajax request the jqXHR.statusText and the textStatus both show the text "success" when at least one should show "OK" for 200, "Created" 201 etc
Attachments (0)
Change History (9)
Changed March 15, 2011 08:28PM UTC by comment:1
component: | unfiled → ajax |
---|---|
resolution: | → invalid |
status: | new → closed |
Changed March 16, 2011 12:26PM UTC by comment:2
I want the "non-standardized" text to show to the user (i.e. API calls) so that they know the number and the browser specific text associated with that status.
Changed May 14, 2011 07:13PM UTC by comment:4
I don't understand why the statusText needs to be normalized. The programmer is supposed to be using the status code anyways - the statusText is just a descriptor (which can be set by either the browser or the server). So why normalize?
Why not give the programmer the flexibility to use their server's ability to respond with a custom status text?
Like you said, the statusText is not standardized (which is the way it should be) so we're supposed to have that ability to set and read any returned statusText.
Besides, the ajax.js code doesn't even look at the statusText in any logic code.
I just don't get why/when this normalization is necessary.
Changed July 21, 2011 02:10AM UTC by comment:5
+1 for providing the actual statusText returned by the server. I understand you're trying to make things cleaner by normalizing something which isn't but at least give some way to access the actual value returned by the server!
Changed July 21, 2011 02:42AM UTC by comment:6
Just found this workaround to expose the native browser xhr object to ajax callbacks. The trick is to extend the xhr instantiation to expose the object as an ajaxSettings property. (Only tested on Chrome yet)
$.ajax({ xhr: function () { this.realXHR = jQuery.ajaxSettings.xhr(); return this.realXHR; }, success: function (response, status, jqXHR) { // statusText should now contain the actual value returned by the server. // It will fallback to the "normalized" value given by the jqXHR object var statusText = (this.realXHR && 'statusText' in this.realXHR) ? this.realXHR.statusText : jqXHR.statusText; } });
Changed July 21, 2011 11:46PM UTC by comment:7
resolution: | invalid |
---|---|
status: | closed → reopened |
Changed July 21, 2011 11:46PM UTC by comment:8
resolution: | → duplicate |
---|---|
status: | reopened → closed |
No, the statusText is normalized just as it should: "success" or "notmodified".
Native status texts are not standardized (strings provided in the standard are just recommendations) so relying on them to have a specific value is wrong.
To take specific actions based on the response status, use jqXHR.status or, better yet, bind a specific callback using the statusCode option introduced in 1.5.