Re: [whatwg/fetch] CORB: blocking of nosniff and 206 responses (#686)

anforowicz commented on this pull request.



> + <!-- XXX If we recast downloading as navigation this step can be removed. -->
+
+ <li>
+  <p>If <var>request</var>'s <a for=request>current url</a>'s <a for=url>origin</a>'s
+  <a for=url>scheme</a> is not an <a>HTTP(S) scheme</a>, then return <b>allowed</b>.
+
+  <p class="note no-backref">Checking the <a for=url>scheme</a> of <a for=request>current url</a>'s
+  <a for=url>origin</a>, rather than of <a for=request>current url</a>'s itself, ensures that
+  <code>blob:</code> URLs are handled correctly.
+
+ <li><p>Let <var>mimeType</var> be the result of <a for="header list">extracting a MIME type</a>
+ from <var>response</var>'s <a for=response>header list</a>.
+
+ <li><p>If <var>response</var>'s <a for=response>status</a> is <code>206</code> and
+ <var>mimeType</var> (ignoring parameters) is an <a>HTML MIME type</a>, a <a>JSON MIME type</a>, or
+ an <a>XML MIME type</a>, but not "<code>image/svg+xml</code>, then return <b>blocked</b>.

Done.

Hmmm... it is a bit awful that 'text/plain' is special-cased in one of the places (this mimics the current CORB implementation in Chromium).  AFAIK:
- We don't want to block 'text/plain' 206 responses, because there are some existing websites that this would disrupt (serving video content with 'text/plain' MIME type)
- At the same time I think that we do want to block 'text/plain' nosniff responses, because prior research identified some security-sensitive responses served with this MIME type.  OTOH, I don't have any more details (@csreis might know more) and we might revisit if folks think consistency would be important here. 

-- 
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/686#discussion_r185081334