Allow users to respond to other ajax event states.

[hungerandthirst@…]

The jQuery docs explicitly state that "No onreadystatechange mechanism is provided, however, since success, error, complete and statusCode cover all conceivable requirements."

Frankly I think that's limiting users unnecessarily. What if I want to respond to something when I get headers back? What if I want to know when I start receiving content back from the server?

An excellent example of this is using jQuery for bandwidth testing. Without a way to detect when I initially receive content back from the server (not just beforeSend), I will also include any delay spent waiting for the server to respond.

I've added support for the RECEIVE_HEADER and LOADING event as per the XMLHttpRequest specs in  this pull request.

I would also like to see support for onreadystatechange as well since those are valuable states that we are only limiting ourselves and losing value by not tracking.

[jaubourg]

First of all, onreadystatechange and xhr events support was removed from the original rewrite because:

• size was beginning to be a real, blocking, issue
• they're not used as much as one may think (there are use cases for them, but they do not represent a need widespread enough to justify the quite substantial bump in size, especially if you already have success, error and complete callbacks).

The jqXHR object doesn't strive to implement the whole xhr API. It's as complete an xhr-compatible wrapper as it makes sense relatively to the diversity of transports under the hood.

Your bandwidth detection example is clearly not a typical use-case for a web app (and that's putting it mildly). Beside, if you wanted to have full control over the xhr, you can still use jQuery.ajaxSettings.xhr() to create a native xhr (because, in the end, given the level of control you require, you don't need ajax to intervene on top of the native xhr -- by setting headers automagically without your knowledge for instance).

As to the patch itself, what I really don't like about it, is that you create specific options that only make sense for the xhr transport.

If you really want those right now and insist on using ajax for low-level control over the xhr, you can easily copy the code of  https://github.com/jquery/jquery/blob/master/src/ajax/xhr.js, apply your patch and change line 52 into:

jQuery.ajaxTransport( "+*", function( s ) {

Drop the file as is in your application: it'll override the default xhr transport and you'll be able to do whatever you need to.

That being said, I know we need some progress notification system but, guess what? We'll have progress callbacks on Deferreds/Promises in 1.7 which would be a perfect fit for this kind of things :)

Given Deferreds' progress is transport agnostic, each transport will be able to provide its own progress notification protocol.

I leave this as opened for now, given that I'd love to see something to notify readyState changes using Deferreds' progress make it as soon as 1.7. But, since this wasn't brought when proposals for new features in 1.7 were in order, I doubt we'd see this before 1.8. On the other hand, the addition would be pretty neutral since progress callbacks didn't exist earlier (no code breakage since existing behaviour stays unchanged).

Anyway:

• yes, we need some kind of a progress notification system for transports,
• no, adding options specific to a given transport is not an acceptable approach,
• let's use Deferreds' progress introduced in 1.7 for this so that all transports can notify their own "events".

I'll try and take this conversation forward in the next jQuery meeting.

[jaubourg]

#9324 is a duplicate of this ticket.

[jaubourg]

#10365 is a duplicate of this ticket.

[dmethvin]

Bulk change from enhancement to feature.

[dmethvin]

Do progress callbacks make this easy now?

[hungerandthirst@…]

Don't know off the top. I will need to investigate and get back to you. Have not had a chance to look into the new callbacks yet.

[mikesherov]

+0, I'm not informed enough to choose.

[gnarf]

+1, I think we should at least look at using .notify to send something about this state change - Measure the size, and then decide

[jaubourg]

FYI, preliminary study indicates adding a minimal implementation of a progress callback which the xhr transport would call at each readystate with the native xhr instance as sole parameter (so that it can be inspected and used) is in the vicinity of 30bytes min/gzipped. Any attempt to make it more secure (not expose the native xhr directly) or more useful (call the progress handlers with meaningful parameters) can only make it much bigger and is actually the desirable approach.

I'm quite torn here, because I know how useful it would be yet I feel like it will be too much weight at this point. Since I know the xhr transport will be extremely simplified for 2.x, I'd like to postpone this.

[dmethvin]

I'm fine with moving this to a later date. We'll have plenty of other things to keep us busy in the next couple of months. :)