Define parsing for X-Content-Type-Options in detail #818

annevk · 2018-10-17T12:47:00Z

And add some of the infrastructure needed to define parsing better for all headers going forward (needed for #814). Fixes #752.

This also fixes an issue with CORB as it simply assumed an X-Content-Type-Options was present.

Tests: web-platform-tests/wpt#13559.

Preview | Diff

And add some of the infrastructure needed to define parsing better for all headers going forward (needed for #814). Fixes #752. This also fixes an issue with CORB as it simply assumed an X-Content-Type-Options was present. Tests: web-platform-tests/wpt#13559.

annevk · 2018-10-17T12:49:23Z

The only somewhat icky bit here in my opinion is using "isomorphic encode" to avoid the lack of byte sequence manipulation infrastructure. It seems fine for now, but worth keeping an eye on.

I also filed a follow-up, unrelated to that: #817.

cc @MattMenke2

domenic

Don't feel super competent to review the actual processing model but overall seems good. Editorial review done.

domenic · 2018-10-17T14:03:27Z

fetch.bs

+
+ <li>
+  <p>Let <var>tokens</var> be the result of
+  <a lt="split on commas">Spliting <var>stringValue</var> on commas</a>.


lowercase "s"

fetch.bs

mikewest

One style nit, but the substance looks correct to me. Thank you!

mikewest · 2018-10-18T07:32:42Z

fetch.bs

+
+ <li><p>If <var>value</var> is null, then return false.
+
+ <li><p>Let <var>stringValue</var> be the <a>isomorphic encode</a> of <var>value</var>.


I wonder if this should be part of the generic get algorithm?

It should be isomorphic decode. I think for some header values we want to always decode using UTF-8?

I'd support adding a "get as string|getting as string" for header lists though to make this easier for simple cases.

fetch.bs

MattMenke2

This looks good to me.

fetch.bs

annevk · 2018-10-30T12:36:49Z

@MattMenke2 so I updated the tests and ran them again and Chrome and Safari both treat nosniff immediately followed by 0x0B or 0x0C as a "valid value". Firefox does so for 0x0C only. I think that's why I went with treating 0x0C as valid and 0x0B as invalid. I'm happy for them to both be restricted, but are you equally sure about wanting this after knowing these results?

MattMenke2 · 2018-10-30T15:37:04Z

@MattMenke2 so I updated the tests and ran them again and Chrome and Safari both treat nosniff immediately followed by 0x0B or 0x0C as a "valid value". Firefox does so for 0x0C only. I think that's why I went with treating 0x0C as valid and 0x0B as invalid. I'm happy for them to both be restricted, but are you equally sure about wanting this after knowing these results?

Running just Chrome's MIME sniffer through a test case (With a real HTTP server), "X-Content-Type-Options: nosniff\x0C" doesn't result in MIME sniffing, and there is no code anywhere in Chrome's network stack that could account for that.

However, it looks to me like Blink's code uses "nosniff" in a couple places, and that code does use a more permissive definition of space:

inline bool IsASCIISpace(CharType c) {
return c <= ' ' && (c == ' ' || (c <= 0xD && c >= 0x9));
}

So it looks to me like what's happening is the network stack sniffs the type, and gives "text/plain" to the renderer. Blink then applies its own header parsing logic, sees the header as being a nosniff header, and decides that "text/plain" just isn't going to cut it in a script tag.

For more well-behaved tags that don't have their own nosniff logic in Blink, like images (I assume), the network stack's interpretation will be respected, but in at least the particular case of Javascript, no so much... So that gets us back where we started.

annevk · 2018-10-30T15:43:58Z

That seems somewhat bad… I guess fingers crossed that we can align on not treating 0x0B and 0x0C as whitespace across all code bases?

MattMenke2 · 2018-10-30T15:49:21Z

I agree. Actually, it seems very bad to me.

I still suspect we won't see much breakage here (I mean, really, who uses that character?), but it does mean this has the potential to break pages. I'm much less gung ho about removing support for it now, but I still think doing so is best for the long term health of the platform, if we can manage it. I've made enough changes to Chrome's header parsing (One more is in the pipeline) in this version that I'm not comfortable making more until the current set has made it to stable or at least been on beta for a while, but we are going to have to change Chrome's behavior here, regardless, at some point.

MattMenke2 · 2018-10-30T15:53:06Z

This bifurcated space handling logic also applies to a number of other response headers in blink. Cache headers, Accept headers, and quite possibly others. Blink doesn't have an HTTP-specific whitespace checking method, so it will be difficult to locate them all.

annevk · 2018-10-31T10:28:49Z

Browser bugs:

annevk · 2018-10-31T11:22:09Z

As a heads up, I plan to merge this tomorrow or Friday, as it sets out new infrastructure for header parsing it's kind of nice to have it landed so the other bits can start to be converted.

asankah

Whitespace restrictions look good to me!

MattMenke2

Likewise happy with this.

For whatwg/fetch#818.

https://bugs.webkit.org/show_bug.cgi?id=191107 Patch by Rob Buis <[email protected]> on 2018-11-06 Reviewed by Darin Adler. LayoutTests/imported/w3c: Update improved result. * web-platform-tests/fetch/nosniff/parsing-nosniff-expected.txt: Source/WebCore: Implement new parsing rules for X-Content-Type-Options [1]: whatwg/fetch#818 [1] https://fetch.spec.whatwg.org/#x-content-type-options-header Test: web-platform-tests/fetch/nosniff/parsing-nosniff.html * platform/network/HTTPParsers.cpp: (WebCore::isHTTPTabOrSpace): (WebCore::parseContentTypeOptionsHeader): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@237850 268f45cc-cd09-0410-ab3c-d52691b4dbfc

…stonly Automatic update from web-platform-testsFetch: X-Content-Type-Options: nosniff parsing For whatwg/fetch#818. -- wpt-commits: 10f708e6f13141fc92ca9318c7606590f659fcf2 wpt-pr: 13559

…stonly Automatic update from web-platform-testsFetch: X-Content-Type-Options: nosniff parsing For whatwg/fetch#818. -- wpt-commits: 10f708e6f13141fc92ca9318c7606590f659fcf2 wpt-pr: 13559 UltraBlame original commit: c10367efab032503002f5a5836ea3cff8fd501f9

annevk requested review from mikewest and domenic October 17, 2018 12:47

annevk mentioned this pull request Oct 17, 2018

What does "combined value" return for a name not in the header list? #752

Closed

domenic reviewed Oct 17, 2018

View reviewed changes

mikewest approved these changes Oct 18, 2018

View reviewed changes

address part of the comments

d302e33

annevk mentioned this pull request Oct 18, 2018

Redesign "extract header values" and "extract header list values" #814

Open

MattMenke2 approved these changes Oct 18, 2018

View reviewed changes

MattMenke2 reviewed Oct 19, 2018

View reviewed changes

fetch.bs Outdated Show resolved Hide resolved

GPHemsley reviewed Oct 28, 2018

View reviewed changes

fetch.bs Outdated Show resolved Hide resolved

annevk mentioned this pull request Oct 30, 2018

MIME type parsing: stop treating 0x0C as whitespace whatwg/mimesniff#89

Closed

use "HTTP whitespace"

81f14e3

annevk mentioned this pull request Oct 30, 2018

Fetch: test nosniff parsing better web-platform-tests/wpt#13559

Merged

be more precise about HTTP whitespace bytes

3515d9b

asankah approved these changes Oct 31, 2018

View reviewed changes

MattMenke2 approved these changes Oct 31, 2018

View reviewed changes

pull bot pushed a commit to hoojaoh/web-platform-tests that referenced this pull request Nov 1, 2018

Fetch: X-Content-Type-Options: nosniff parsing

10f708e

For whatwg/fetch#818.

annevk merged commit 32c7b1c into master Nov 1, 2018

annevk deleted the annevk/x-content-type-options branch November 1, 2018 09:14

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Define parsing for X-Content-Type-Options in detail #818

Define parsing for X-Content-Type-Options in detail #818

annevk commented Oct 17, 2018 •

edited by pr-preview bot

Loading

annevk commented Oct 17, 2018

domenic left a comment

domenic Oct 17, 2018

mikewest left a comment

mikewest Oct 18, 2018

annevk Oct 18, 2018

annevk Oct 18, 2018

MattMenke2 left a comment

annevk commented Oct 30, 2018

MattMenke2 commented Oct 30, 2018 •

edited

Loading

annevk commented Oct 30, 2018

MattMenke2 commented Oct 30, 2018

MattMenke2 commented Oct 30, 2018

annevk commented Oct 31, 2018

annevk commented Oct 31, 2018

asankah left a comment

MattMenke2 left a comment


		<li><p>If <var>value</var> is null, then return false.

		<li><p>Let <var>stringValue</var> be the <a>isomorphic encode</a> of <var>value</var>.

Define parsing for X-Content-Type-Options in detail #818

Define parsing for X-Content-Type-Options in detail #818

Conversation

annevk commented Oct 17, 2018 • edited by pr-preview bot Loading

annevk commented Oct 17, 2018

domenic left a comment

Choose a reason for hiding this comment

domenic Oct 17, 2018

Choose a reason for hiding this comment

mikewest left a comment

Choose a reason for hiding this comment

mikewest Oct 18, 2018

Choose a reason for hiding this comment

annevk Oct 18, 2018

Choose a reason for hiding this comment

annevk Oct 18, 2018

Choose a reason for hiding this comment

MattMenke2 left a comment

Choose a reason for hiding this comment

annevk commented Oct 30, 2018

MattMenke2 commented Oct 30, 2018 • edited Loading

annevk commented Oct 30, 2018

MattMenke2 commented Oct 30, 2018

MattMenke2 commented Oct 30, 2018

annevk commented Oct 31, 2018

annevk commented Oct 31, 2018

asankah left a comment

Choose a reason for hiding this comment

MattMenke2 left a comment

Choose a reason for hiding this comment

annevk commented Oct 17, 2018 •

edited by pr-preview bot

Loading

MattMenke2 commented Oct 30, 2018 •

edited

Loading