Skip to main content

Bug Tracker

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:
Component: ajax Version: 1.5.1
Keywords: Cc:
Blocked by: Blocking:

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 jaubourg comment:1

component: unfiledajax
resolution: → invalid
status: newclosed

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.

Changed March 16, 2011 12:26PM UTC by arib 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 April 27, 2011 10:42AM UTC by jaubourg comment:3

#8987 is a duplicate of this ticket.

Changed May 14, 2011 07:13PM UTC by Tony 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 anonymous 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)

  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 jaubourg comment:7

resolution: invalid
status: closedreopened

Changed July 21, 2011 11:46PM UTC by jaubourg comment:8

resolution: → duplicate
status: reopenedclosed

Changed July 21, 2011 11:46PM UTC by jaubourg comment:9

Duplicate of #9854.