Re: [whatwg/fetch] CORB: nosniff handling (#686)

annevk commented on this pull request.

I made some formatting tweaks and did another review pass.

> @@ -2354,6 +2354,49 @@ X-Content-Type-Options           = "nosniff" ; case-insensitive</pre>
 pertain to them. Also, considering "<code>image</code>" was not compatible with deployed content.
 
 
+<h3 id=cross-origin-read-blocking>Cross-Origin Read Blocking (CORB)</h3>

What do you think about calling this 'Cross-origin "no-cors" blocking'? Or maybe "Opaque filtered response blocking". That would make it more in line with terminology Fetch already uses.

> @@ -2354,6 +2354,49 @@ X-Content-Type-Options           = "nosniff" ; case-insensitive</pre>
 pertain to them. Also, considering "<code>image</code>" was not compatible with deployed content.
 
 
+<h3 id=cross-origin-read-blocking>Cross-Origin Read Blocking (CORB)</h3>
+
+<h4 lt="should response to request be blocked due to corb" dfn id=should-response-to-request-be-blocked-due-to-corb?>Should
+<var>response</var> to <var>request</var> be blocked due to CORB?</h4>

I think rather than a heading we should introduce this algorithm with a paragraph. I'm not a big fan of using headings.

> @@ -2354,6 +2354,49 @@ X-Content-Type-Options           = "nosniff" ; case-insensitive</pre>
 pertain to them. Also, considering "<code>image</code>" was not compatible with deployed content.
 
 
+<h3 id=cross-origin-read-blocking>Cross-Origin Read Blocking (CORB)</h3>
+
+<h4 lt="should response to request be blocked due to corb" dfn id=should-response-to-request-be-blocked-due-to-corb?>Should
+<var>response</var> to <var>request</var> be blocked due to CORB?</h4>

We should also try to avoid the question mark in the ID. That was not really intentional with the other algorithm in Fetch and complicates linking towards it.

> + <!-- 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>.

Since we use these MIME types twice, I suggest we give them a common term.

> +<var>response</var> to <var>request</var> be blocked due to CORB?</h4>
+
+<p>Run these steps:
+
+<ol>
+ <li><p>If <var>request</var>'s <a for=request>initiator</a> is "<code>download</code>", then return
+ <b>allowed</b>.
+ <!-- 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.

I don't understand this bit. Can you even fetch a `blob:` URL across origins today? @mkruisselbrink I remember you were looking into this, did you ever finish that research?

-- 
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#pullrequestreview-115571406