19831 2012-11-02 15:14:14 +0000 Investigate overrideMimeType() 2013-05-23 10:33:26 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified PC Windows 3.1 RESOLVED WONTFIX P2 normal --- 1 annevk annevk hsteen j mike public-webapps public-webapps-bugzilla oldest_to_newest 77752 0 annevk 2012-11-02 15:14:14 +0000 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. 77753 1 hsteen 2012-11-02 15:56:55 +0000 I'm about to write a couple of tests for overrideMimeType(), will report back on the behaviours.. 77755 2 hsteen 2012-11-02 16:17:43 +0000 (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.) 77757 3 annevk 2012-11-02 16:34:18 +0000 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. 77758 4 annevk 2012-11-02 16:34:43 +0000 stops working* 77761 5 hsteen 2012-11-02 17:04:20 +0000 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 77762 6 hsteen 2012-11-02 17:06:58 +0000 (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) 77763 7 hsteen 2012-11-02 17:22:50 +0000 Anne: Firefox, Opera and Chrome agree that calling overrideMimeType() in HEADERS_RECEIVED state is a no-op. 77764 8 hsteen 2012-11-02 17:23:18 +0000 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 77814 9 j 2012-11-03 22:31:07 +0000 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. 77979 10 hsteen 2012-11-06 22:10:19 +0000 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? 77992 11 j 2012-11-07 13:08:35 +0000 > 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. 78097 12 hsteen 2012-11-09 12:02:44 +0000 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 :-)) 78098 13 hsteen 2012-11-09 12:08:38 +0000 > 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. 88121 14 hsteen 2013-05-23 10:33:26 +0000 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..