Bug Tracker

Modify

Ticket #9854 (closed enhancement: fixed)

Opened 3 years ago

Last modified 3 years ago

Pass statusText through instead of "normalizing" it

Reported by: Peter Kline <pkline@…> Owned by: jaubourg
Priority: low Milestone: 1.6.3
Component: ajax Version: 1.6.2
Keywords: Cc:
Blocking: Blocked by:

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.

Change History

comment:1 Changed 3 years ago by knson99@…

Thank you bug....

comment:2 Changed 3 years ago by jaubourg

  • Owner set to jaubourg
  • Priority changed from undecided to low
  • Status changed from new to assigned
  • Component changed from unfiled to ajax
  • Milestone changed from None to 1.next

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?

comment:3 Changed 3 years ago by jaubourg

#8534 is a duplicate of this ticket.

comment:4 Changed 3 years ago by jaubourg

#8987 is a duplicate of this ticket.

comment:5 Changed 3 years ago by pkline@…

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.

comment:6 Changed 3 years ago by jaubourg

  • Status changed from assigned to closed
  • Resolution set to fixed

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

Changeset: 0ed99097bda3bb6e302c3d93331f0e7312e42077

comment:7 Changed 3 years ago by jaubourg

  • Milestone changed from 1.next to 1.6.3

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.