Describe CORB confirmation sniffing

[anforowicz]

Cross-Origin Read Blocking (CORB) confirmation sniffing needs to be described in a spec somewhere (see whatwg/fetch#681 (comment)). CORB sniffs response body with the goal of confirming that the body matches the Content-Type and cannot possibly parse as another, cross-origin-embeddable body type.

Example 1: If response headers include "Content-Type: text/html" and the response body starts with "<html" then the response cannot possibly represent a resource that can be embedded cross-origin (and therefore can be safely blocked by CORB).

Example 2: If response headers include "Content-Type: text/html" and the response body starts with "<!-- // --> <script type='text/javascript'>" then the response might be interpreted both as text/html and/or application/javascript (and therefore should not be blocked by CORB). Such "polyglot" responses are allowed by covering HTML-style comments in Javascript syntax spec. This example shows that sniffing "<!--" (as suggested by "section 7.1. Identifying a resource with an unknown MIME type") is not sufficient to decide that the response really is a text/html.

[annevk]

Apologies for the late response here. I'm generally not super happy with the current state of sniffing algorithms in this document, which is why I hoped we'd define CORB sniffing directly in Fetch in a newer algorithm style. As such I'm not entirely sure how to proceed. I want to find a way to test the existing algorithms better so we can figure out to what extent they are implemented and correct.

I'm also no longer convinced only CORB should be sufficient to enable high resolution timers. Requiring CORS seems better, but it's still worthwhile to block as many of these "no-cors" loads as possible.