JSFiddle for the issue here: http://jsfiddle.net/K4GQa/

Works in IE9, FF, Chrome, etc...but in IE8 it fails.

This is too much of a rare corner case for us to deal with. As a workaround you can override the xhr factory in your ajax options for this one situation and still use $.ajax.

Whoa there guys -- this isn't a rare corner case, and it really should be dealt with in jQuery. If the PATCH method is to be used at all, it needs to work even if your customer is using IE8 to browse your website. Failing that, PATCH should be forbidden entirely in jQuery.ajax, so that folks don't try to use it, and assume that it will work because it happens to in their development browser.

Fortunately, the fix should be easy enough, if the method is PATCH, and the browser is LTE IE8, use the ol' ActiveXHTTP object, as you would in other old IEs.

I would echo @jashkenas' comment. Interest in PATCH has been gaining steam the last few years, and people will try to use it. jQuery should IMO have a specified behavior: supported, unsupported, or supported behind a flag.

For IE7-8 only these methods are allowed in native xhr, therefore this problem is a general one, i.e. this –

xhr.open('connect', /item/1, true);

xhr.open('never-existed', /item/1, true);

Fortunately, the fix should be easy enough, if the method is PATCH, and the browser is LTE IE8, use the ol' ActiveXHTTP object, as you would in other old IEs.

We don't do UA-sniffing and i hope we never will, but this bug could be exposed through feature detection and fixed through whitelist of allowed HTTP-methods, without always succumbing to activeX way in IE7-8. But, again, if this is a rare case i don't know if we should.

@jabourg?

Seems pretty rare to me. The user or a plugin writer can fix it by changing xhr in $.ajaxSetup() or in the $.ajax() call itself if they know they'll encounter the issue. Due to PTSD I have forgotten the other important edge-case differences between the native XMLHttpRequest object and the ActiveX one in IE7/8, but it seems like a bad idea to switch IE8 to ActiveX full time.

It's rare at the moment because PATCH hasn't been started to be used widely yet ... now that new versions of Rails are starting to support it by default, and libraries like Backbone and Ember want to follow suit as soon as possible, it will become extremely common. Basically any situation that used to use a (technically-invalid) partial PUT via Ajax may desire to use PATCH going forwards.

I'm not suggesting that jQuery on IE8 go ActiveX full time ... just if you're sending a non-whitelisted method over XHR. It also has the benefit of fixing jQuery.ajax for other (perhaps future) HTTP methods on IE8.

In the end, having end-users of jQuery version- or feature- detect IE8 to effectively monkey-patch jQuery.ajax seems like the exact opposite in spirit to the usual reason why we rely on jQuery in the first place -- because its core methods can be relied on to support the same features cross-browser. If you leave this wontfix, you're telling a whole lotta different downstream libraries to all implement the same monkey-patch in the same way for the same situation.

Sorry for beating on my drum (I hate it when people do it to me) -- but I'm really eager to land PATCH support, and proper partial data updates, and want to do it right.

This can be fixed outside jQuery. Write up your fix and start using it. Let's see how big it is and what else it breaks. That way you also don't need to tell everyone to upgrade to jQuery 1.11 or wherever it lands.

I saw you mentioned monkey patching, none of that is required. Just add xhr: function(){ return new window.ActiveXObject("Microsoft.XMLHTTP"); } to the list of $.ajax arguments when appropriate.

Moving this to patchwelcome pending the outcome of your experiment.

You have two solutions to fix this in your code:

Change the xhr creation code globally (always use ActiveX if present):

if ( window.ActiveXObject ) {
  $.ajaxSetup({
    xhr: function() {
      return new window.ActiveXObject("Microsoft.XMLHTTP");
    }
  });
}

A more subtle approach is to create a prefilter for this that changes the xhr creation code dynamically given the type:

if ( window.ActiveXObject ) {
  $.ajaxPrefilter(function( options ) {
    if ( /^patch$/i.test( options.type ) ) {
      options.xhr = function() {
        return new window.ActiveXObject("Microsoft.XMLHTTP");
      };
    }
  });
}

The ajax architecture has been revamped/reworked in 1.5 for this kind of situations. It is now very easy to fix "temporary" problems without having to wait for a full version of jQuery and, even, without the need for jQuery core to handle the problem.

By temporary, I mean peculiarities in older but still supported platforms when using "new stuff".

Alright -- I'll play along. Here's the (uh, ahem) patch that I'm using:

https://github.com/documentcloud/backbone/commit/f495c3615b5484ed7647cfc4f4ad3e276327e136

... and here's the ticket, so you can follow along with the results:

https://github.com/documentcloud/backbone/issues/2152

The check for old IE in @jashkenas' patch is insufficient as it will be used even if ActiveX is disabled and will be used in IE9+.

Fixed via https://github.com/jquery/jquery/commit/06ee2c16f1c466a77fb25e07991e5adaa3385656