I'm not an expert on CORS, but aren't preflights only sent before requests are issued?  (i.e., not after we've sent the request and gotten the mime type).

Skimming over the code, does not look to me like out mime sniffy should trigger on this case.

It's about the media type on the *request* (set through XHR), not the *response*. See example in <https://issues.apache.org/jira/browse/JCR-4002?focusedCommentId=15418909&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15418909>.

Yeah, this looks like an issue in our XHR implementation. I agree that `xhr.setRequestHeader("Content-Type", "text/p laiN");` should force a preflight, as the content type is no longer simple.

tyoshino@, would you mind either taking a look at this yourself, or delegating to someone to poke at it? It looks like it's failing in 52 as well, so this has probably been around for a while.

This is a long-lived bug in extractMIMETypeFromMediaType(). Reading https://bugs.webkit.org/show_bug.cgi?id=8644, I think it's not at all controversial but just didn't get change to get fixed.

I'll fix it.

https://codereview.chromium.org/2310783003/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7e8584afcaa263a69c49a36e9380bc7a715e2284

commit 7e8584afcaa263a69c49a36e9380bc7a715e2284
Author: tyoshino <tyoshino@chromium.org>
Date: Tue Sep 06 05:27:22 2016

Stop ignoring whitespaces in the middle of MIME type in a Content-Type header

extractMIMETypeFromMediaType() has been treating \n (0x0a), \v (0x0b),
\f (0x0c), \r (0x0d) and Unicode characters with BIDI property WS as
white space in addition to the OWS characters SP (0x20) and HTAB (0x09).
These characters were trimmed not only from the head and tail of the
type/subtype part but also from the middle of the value, i.e. when
"te xt/ht ml" is received it's automatically normalized into
"text/html".

This CL fixes this spec violation partially by:
- limiting characters which are dealt with as whitespaces to only SP
  and HTAB as specified in the RFC 7230
- stop trimming white space characters (including SP and HTAB) from the
  middle of type/subtype value

We don't add full ABNF validation to drop everything that doesn't
conform to the media-type ABNF as we're not sure how much the result
of such strict fixing would be.

See also https://bugs.webkit.org/show_bug.cgi?id=8644

R=mkwst@chromium.org
BUG= 642346 

Review-Url: https://codereview.chromium.org/2310783003
Cr-Commit-Position: refs/heads/master@{#416586}

[modify] https://crrev.com/7e8584afcaa263a69c49a36e9380bc7a715e2284/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/supported-xml-content-types-invalid-1-expected.txt
[modify] https://crrev.com/7e8584afcaa263a69c49a36e9380bc7a715e2284/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/supported-xml-content-types-invalid-1.html
[modify] https://crrev.com/7e8584afcaa263a69c49a36e9380bc7a715e2284/third_party/WebKit/Source/platform/network/HTTPParsers.cpp
[modify] https://crrev.com/7e8584afcaa263a69c49a36e9380bc7a715e2284/third_party/WebKit/Source/platform/network/HTTPParsers.h
[modify] https://crrev.com/7e8584afcaa263a69c49a36e9380bc7a715e2284/third_party/WebKit/Source/platform/network/HTTPParsersTest.cpp