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.

#9324 is a duplicate of this ticket.

#10365 is a duplicate of this ticket.

Bulk change from enhancement to feature.

Do progress callbacks make this easy now?

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.

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

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

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.

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. :)

Replying to [comment:12 dmethvin]:

Just do it. If anything adding this support will introduce a lot of people to progress(), which I have always thought was such a clever part of $.Deferred.

https://github.com/jquery/jquery/pull/1541

Migrated to https://github.com/jquery/jquery/issues/1725