Bug 19831 - Investigate overrideMimeType()
Investigate overrideMimeType()
Status: RESOLVED WONTFIX
Product: WebAppsWG
Classification: Unclassified
Component: XHR
unspecified
PC Windows 3.1
: P2 normal
: ---
Assigned To: Anne
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-02 15:14 UTC by Anne
Modified: 2013-05-23 10:33 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anne 2012-11-02 15:14:14 UTC
Christophe Dumez informed me of https://bugs.webkit.org/show_bug.cgi?id=95728 which probably requires an answer and maybe a change in behavior.
Comment 1 Hallvord R. M. Steen 2012-11-02 15:56:55 UTC
I'm about to write a couple of tests for overrideMimeType(), will report back on the behaviours..
Comment 2 Hallvord R. M. Steen 2012-11-02 16:17:43 UTC
(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.)
Comment 3 Anne 2012-11-02 16:34:18 UTC
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.
Comment 4 Anne 2012-11-02 16:34:43 UTC
stops working*
Comment 5 Hallvord R. M. Steen 2012-11-02 17:04:20 UTC
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
Comment 6 Hallvord R. M. Steen 2012-11-02 17:06:58 UTC
(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)
Comment 7 Hallvord R. M. Steen 2012-11-02 17:22:50 UTC
Anne: Firefox, Opera and Chrome agree that calling overrideMimeType() in HEADERS_RECEIVED state is a no-op.
Comment 8 Hallvord R. M. Steen 2012-11-02 17:23:18 UTC
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
Comment 9 Julian Aubourg 2012-11-03 22:31:07 UTC
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.
Comment 10 Hallvord R. M. Steen 2012-11-06 22:10:19 UTC
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?
Comment 11 Julian Aubourg 2012-11-07 13:08:35 UTC
> 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.
Comment 13 Hallvord R. M. Steen 2012-11-09 12:08:38 UTC
> 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.
Comment 14 Hallvord R. M. Steen 2013-05-23 10:33:26 UTC
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..