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

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
Committed: https://crrev.com/7e8584afcaa263a69c49a36e9380bc7a715e2284
Cr-Commit-Position: refs/heads/master@{#416586}

[tyoshino (SeeGerritForStatus), 2016-09-05 09:01:37]

Description was changed from

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

BUG=642346
==========

to

==========
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 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

BUG=642346
==========

[tyoshino (SeeGerritForStatus), 2016-09-05 09:02:15]

The CQ bit was checked by tyoshino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-05 09:02:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-05 10:29:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-05 10:29:21]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[tyoshino (SeeGerritForStatus), 2016-09-05 10:45:29]

tyoshino@chromium.org changed reviewers:
+ mkwst@chromium.org

[tyoshino (SeeGerritForStatus), 2016-09-05 10:45:30]

BTW, Mike, again you still have OOO message in your name :)

https://codereview.chromium.org/2310783003/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/network/HTTPParsers.cpp (right):

https://codereview.chromium.org/2310783003/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/network/HTTPParsers.cpp:376: return
AtomicString(mediaType.getString().substring(typeStart, typeEnd - typeStart));
We can reduce creation of sub String here, but didn't for simplicity.

[Mike West, 2016-09-05 12:00:12]

LGTM. Thanks for addressing this!

[tyoshino (SeeGerritForStatus), 2016-09-06 03:53:21]

Description was changed from

==========
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 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

BUG=642346
==========

to

==========
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
==========

[tyoshino (SeeGerritForStatus), 2016-09-06 03:53:48]

The CQ bit was checked by tyoshino@chromium.org

[tyoshino (SeeGerritForStatus), 2016-09-06 03:53:48]

The patchset sent to the CQ was uploaded after l-g-t-m from mkwst@chromium.org
Link to the patchset: https://codereview.chromium.org/2310783003/#ps60001
(title: "Rebase")

[commit-bot: I haz the power, 2016-09-06 03:53:53]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-06 05:27:42]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-09-06 05:29:39]

Description was changed from

==========
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
==========

to

==========
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

Committed: https://crrev.com/7e8584afcaa263a69c49a36e9380bc7a715e2284
Cr-Commit-Position: refs/heads/master@{#416586}
==========

[commit-bot: I haz the power, 2016-09-06 05:29:40]

Patchset 4 (id:??) landed as
https://crrev.com/7e8584afcaa263a69c49a36e9380bc7a715e2284
Cr-Commit-Position: refs/heads/master@{#416586}