I'm about to write a couple of tests for overrideMimeType(), will report back on the behaviours..

(In any case spec is a bit inconsistent since it doesn't say anything about how overrideMimeType() behaves when send() flag is set in OPENED state - or for what's worth in HEADERS_RECEIVED state, this should be added.)

It's not inconsistent. The send() flag does not matter, the method just works. The method works working after all headers are in, because at that point you want to start using the MIME type.

stops working*

For test calling overrideMimeType() at readyState=4, trying to make the browser handle a text/plain;charset=iso-8859-1 as if it were sent with application/xml;charset=UTF-8 :

IE 8 throws. End of story.

Firefox/Opera: don't throw. The call seems to have no effect whatsoever, neither on decoding nor on responseXML.

Chrome: oddly enough, Chrome does something inbetween. The new MIME type is applied, so request.responseXML is defined. The charset parameter has however no effect, so we get a well-formed XML DOM full of mojibake. :-p

(Test description should be: "handle a text/plain;charset=iso-8859-1 as if it were application/xml;charset=Shift-JIS", I changed the test to better understand what was going on because Firefox seemed to do some encoding detection or normalisation somewhere)

Anne: Firefox, Opera and Chrome agree that calling overrideMimeType() in HEADERS_RECEIVED state is a no-op.

My preference would be to keep the exception throwing in the spec as-is. 

Reasons:

* calling a method when it has no effect is probably an author mistake, throwing is a better way to warn against it

* since IE does it, we will hopefully escape compat problems (and the method isn't much used in the first place)

* as implementations disagree, there is no clear, consistent and useful alternative behaviour to consistently throwing

I guess this E-mail caused the spec change to make it throw:
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0022.html

I think the wording in the spec is clear enough and that throwing an InvalidStateError makes perfect sense here.

As for the operation being a no-op in HEADERS_RECEIVED state, it's definitely a bug in FF, Opera and Chrome: inspecting headers then decide if overriding is needed/desired or not, and, more importantly, with which value seems like a very useful feature to me.

D'oh - IE (8) throws because this method isn't supported in IE at all.

I also note that no browser currently throws the prescribed SYNTAX_ERR for invalid MIME types. I hope we'll get away with it compat-wise, but we might not.

Julian, I think you said the method was more used than I thought - in among others jQuery. Any idea what the most commonly used argument strings are? Does jQuery's AJAX logic use overrideMimeType() internally?

> D'oh - IE (8) throws because this method isn't supported in IE at all.

Hahaha ;)

> I also note that no browser currently throws the prescribed SYNTAX_ERR
> for invalid MIME types. I hope we'll get away with it compat-wise, but
> we might not.

They should :/

> Julian, I think you said the method was more used than I thought - in
> among others jQuery.

No, not quite. But we've been asked to support it on our jqXHR abstraction so I know for a fact that our users have a need for it. That being said our implementation puts the new mimeType in an internal option and calls the native overrideMimeType before sending (see https://github.com/jquery/jquery/blob/master/src/ajax/xhr.js#L78). We never had any complain about this... so I'm not sure people are clamoring about what I'm talking about in my previous comment (inspect response headers before deciding on the mimeType to override with if any).

> Any idea what the most commonly used argument strings are?

No idea. I dunno if it is used to disable native XHR xml parsing or enable it or any other reason.

> Does jQuery's AJAX logic use overrideMimeType() internally?

No, because it's not supported by all browsers we target as of today. This may change in jQuery 2.0. I'd love to just force all requests in text/plain and have jQuery's own internal conversion logic handle parsing... would make our code that much simpler.

Some new test cases now submitted and live:

http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/overridemimetype-done-state.htm
http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/overridemimetype-headers-received-state-force-shiftjis.htm
http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/overridemimetype-invalid-mime-type.htm
http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/overridemimetype-loading-state.htm
http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/overridemimetype-open-state-force-utf-8.htm
http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/overridemimetype-open-state-force-xml.htm
http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/overridemimetype-unsent-state-force-shiftjis.htm

They generally assert that the spec is correct as of now, including the headers-received state test (an assertation no browser actually passes, test added because Julian wants it to work :-))

> I'm not sure people are clamoring about
> what I'm talking about in my previous comment (inspect response headers
> before deciding on the mimeType to override with if any).

Well, I've never seen it done but the reason for that might of course be that it's generally not supported at all ;-)

I'd like some implementor comments here, if possible.. The cost for implementors may not be worth the small extra benefit.

> I'd love to just force all requests in text/plain
> and have jQuery's own internal conversion logic handle parsing...

Now, now.. usually JS authors want the browser to work harder and do more of the heavy lifting, so be careful what you ask for ;-)

Finally, overrideMimeType() is sort of obsolete with the responseType/response approach. The only remaining use case is to fix decoding of content with a misleading charset in content-type. Therefore, overrideMimeType() will hopefully be less and less used, so the details we're working on here aren't worth a lot more of our time IMO.

As we largely agree that what the spec says is a reasonable idea, I'll WONTFIX this and we'll cross our fingers that there won't be much compat fallout..