Open Bug 918731 Opened 7 years ago Updated 3 years ago

XMLHttpRequest's overrideMimeType() does not follow the standard

Categories

(Core :: DOM: Core & HTML, defect)

x86
Linux
defect
Not set

Tracking

()

People

(Reporter: hsteen, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed)

Anne, is this still something we want to add to XHRs? Chrome, Edge and WebKit also don't support it.
Flags: needinfo?(annevk)
So instead of throwing for invalid MIME types, we'd just return early and cause it to have any effect? Or what is the processing model we'd change the specification to?
Flags: needinfo?(annevk)
Based on them failing this test, they simply don't perform this check at all (that is, they allow overriding to an invalid MIME type). Reading the spec, that would seem to be step 2 for the method: https://xhr.spec.whatwg.org/#dom-xmlhttprequest-overridemimetype
Flags: needinfo?(annevk)
I see, so

  Content-Type: text/xml

  overrideMimeType("bogus")

results in responseXML not working.

I filed https://github.com/whatwg/xhr/issues/82 to fix this in the standard.
Flags: needinfo?(annevk)
Heh. If it makes you feel better, I'd personally also prefer having the MIME type validation check :)
I updated the test in https://github.com/w3c/web-platform-tests/pull/4955 and added more in https://github.com/w3c/web-platform-tests/pull/4993. The standard was updated as well. There's a couple things here we could clean up to get better convergence and not end up breaking things by throwing as previously required.
Summary: [XHR2] overrideMimeType() doesn't throw for invalid argument → XMLHttpRequest's overrideMimeType() does not follow the standard
Blocks: xhr
No longer blocks: xhr2pass
You need to log in before you can comment on or make changes to this bug.