Bug Tracker

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#8534 closed bug (duplicate)

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

Change History (9)

comment:1 Changed 9 years ago by jaubourg

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.

comment:2 in reply to:  1 Changed 9 years ago by arib

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.

comment:3 Changed 9 years ago by jaubourg

#8987 is a duplicate of this ticket.

comment:4 Changed 9 years ago by Tony

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.

comment:5 Changed 8 years ago by anonymous

+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!

comment:6 Changed 8 years ago by bruno@…

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;
  }
});

comment:7 Changed 8 years ago by jaubourg

Resolution: invalid
Status: closedreopened

comment:8 Changed 8 years ago by jaubourg

Resolution: duplicate
Status: reopenedclosed

comment:9 Changed 8 years ago by jaubourg

Duplicate of #9854.

Note: See TracTickets for help on using tickets.