Re: [whatwg/fetch] Define parsing for X-Content-Type-Options in detail (#818)

MattMenke2 commented on this pull request.



> +steps:
+
+<ol>
+ <li><p>Let <var>value</var> be the result of <a for="header list">getting</a>
+ `<a http-header><code>X-Content-Type-Options</code></a>` from <var>list</var>.
+
+ <li><p>If <var>value</var> is null, then return false.
+
+ <li><p>Let <var>stringValue</var> be the <a>isomorphic decode</a> of <var>value</var>.
+
+ <li>
+  <p>Let <var>tokens</var> be the result of
+  <a lt="split on commas">spliting <var>stringValue</var> on commas</a>.
+
+  <p class="note">This intentionally strips U+000C FORM FEED, despite 0x0C not being being a
+  <a>HTTP whitespace byte</a>.

I'm rather reluctant to add this to Chrome, since it's inconsistent with handling of other headers, and we've gotten away without it for all these years.

I have a CL in progress to remover single quote handling in our general parser for things like 'foo=bar; baz="Jumbo, shrimp"', which was configurable so it could just recognize double quotes, or double-quotes or single quotes, which will make parsing of headers more consistent.  I think it would be unfortunate if we had to add a way of configuring it to treat U+000C as white space in some, but not all header-related contexts, taking a step in the opposite direction.  I also think treating it as whitespace everywhere is a bigger change to the web platform than allowing it as whitespace nowhere.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/818#discussion_r227324077