Let Fetch be in charge of extracting the bytes

Corresponding Fetch PR: whatwg/fetch#1172.

Closes #63. Helps with #83.

index.bs

@@ -183,7 +183,7 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
       </pre>
       </div>
 
-  *   A user agent wishes to ensure that JavaScript code running in high-privilege HTML 
+  *   A user agent wishes to ensure that JavaScript code running in high-privilege HTML
       contexts (for example, a browser's New Tab page) aren't manipulated before display.
       <a>Integrity metadata</a> mitigates the risk that altered JavaScript will run
       in these pages' high-privilege contexts.
@@ -199,10 +199,6 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
 
   The terms [=/origin=] and [=same origin=] are defined in HTML. [[!HTML]]
 
-  The <dfn>representation data</dfn> of a resource is defined by
-  <a href="https://tools.ietf.org/html/rfc7231#section-3">Section 3
-  of RFC 7231</a>. [[!RFC7231]]
-
   A <dfn>base64 encoding</dfn> is defined in <a
   href="https://tools.ietf.org/html/rfc4648#section-4">Section 4 of RFC 4648</a>.
   [[!RFC4648]]
@@ -346,61 +342,12 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
 
   ## Response verification algorithms ## {#verification-algorithms}
 
-  ### Apply |algorithm| to |response| ### {#apply-algorithm-to-response}
+  ### Apply |algorithm| to |bytes| ### {#apply-algorithm-to-response}
 
-  1.  Let |result| be the result of [[#apply-algorithm-to-response]]
-      to the <a>representation data</a> without any content-codings
-      applied, except when the user agent intends to consume the content with
-      content-codings applied. In the latter case, let |result| be
-      the result of applying |algorithm| to the <a>representation data</a>.
+  1.  Let |result| be the result of applying |algorithm| to |bytes|.
   2.  Let |encodedResult| be result of <a>base64 encoding</a> |result|.
   3.  Return |encodedResult|.
 
-  ### Is |response| eligible for integrity validation? ### {#is-response-eligible}
-
-  In order to mitigate an attacker's ability to read data cross-origin by
-  brute-forcing values via integrity checks, responses are only eligible for such
-  checks if they are same-origin or are the result of explicit access granted to
-  the loading origin via Cross Origin Resource Sharing [[!Fetch]].
-
-  Note: As noted in 
-  <a href="https://tools.ietf.org/html/rfc6454#section-4">RFC6454, section 4</a>,
-  some user agents use
-  globally unique identifiers for each file URI. This means that
-  resources accessed over a `file` scheme URL are unlikely to be
-  eligible for integrity checks.
-
-  Note: Being in a <a>Secure Context</a> (e.g., a document delivered over HTTPS) is not
-  necessary for the use of integrity validation. Because resource integrity is
-  only an application level security tool, and it does not change the security
-  state of the user agent, a Secure Context is unnecessary. However, if integrity
-  is used in something other than a Secure Context (e.g., a document delivered
-  over HTTP), authors are reminded that the integrity provides <em>no security
-  guarantees at all</em>. For this reason, authors are encouraged to only deliver
-  integrity metadata in a Secure Context.  See [[#non-secure-contexts]] for
-  more discussion.
-
-  The following algorithm details these restrictions:
-
-  1.  Let |response| be the response that results from
-      <a lt="fetch">fetching</a> the |resource|.
-  2.  If the <a>|response| type</a> is `basic`,
-      `cors` or `default`, return `true`.
-  3.  Return `false`.
-
-  <div class="note">
-  The <a lt="response type">response types</a> are defined by the Fetch
-  specification [[!FETCH]] and refer to the following:
-
-  * `basic` is a <a>same origin</a> response, and thus the requestor has full access
-    to read the body.
-  * `cors` is a valid response to a cross-origin, CORS-enabled request, and thus
-    again the requestor has full access to read the body.
-  * `default` is a valid response that is generated by a Service Worker as a
-    response to the request, so its body, too, is fully readable by the requestor.
-
-  </div>
-
   ### Parse |metadata| ### {#parse-metadata}
 
   This algorithm accepts a string, and returns either `no metadata`, or a set of
@@ -440,23 +387,21 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
           set, and add |item| to |result|.
   3.  Return |result|.
 
-  ### Does |response| match |metadataList|? ### {#does-response-match-metadatalist}
+<h3 dfn export id=does-response-match-metadatalist>Do |bytes| match |metadataList|?</h3>
 
   1.  Let |parsedMetadata| be the result of
       <a href="#parse-metadata">parsing |metadataList|</a>.
   2.  If |parsedMetadata| is `no metadata`, return `true`.
-  3.  If <a href="#is-response-eligible">|response| is not eligible for integrity
-      validation</a>, return `false`.
-  4.  If |parsedMetadata| is the empty set, return `true`.
-  5.  Let |metadata| be the result of <a href="#get-the-strongest-metadata">
+  3.  If |parsedMetadata| is the empty set, return `true`.
+  4.  Let |metadata| be the result of <a href="#get-the-strongest-metadata">
       getting the strongest metadata from |parsedMetadata|</a>.
-  6.  For each |item| in |metadata|:
+  5.  For each |item| in |metadata|:
       1.  Let |algorithm| be the |alg| component of
           |item|.
       2.  Let |expectedValue| be the |val| component of
           |item|.
       3.  Let |actualValue| be the result of <a
-          href="#apply-algorithm-to-response">applying |algorithm| to |response|
+          href="#apply-algorithm-to-response">applying |algorithm| to |bytes|
           </a>.
       4.  If |actualValue| is a case-sensitive match for
           |expectedValue|, return `true`.
@@ -485,12 +430,6 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
   execute correctly, even if the HTTPS version of a resource differs from the HTTP
   version.
 
-  Note: This algorithm returns `false` if the response is not <a
-  href="#is-response-eligible">eligible</a> for integrity
-  validation since Subresource Integrity requires CORS, and it is a logical error
-  to attempt to use it without CORS. Additionally, user agents SHOULD report a
-  warning message to the developer console to explain this failure.
-
   ## Verification of HTML document subresources ## {#verification-of-html-document-subresources}
 
   A variety of HTML elements result in requests for resources that are to be
@@ -562,7 +501,7 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
   ## Handling integrity violations ## {#handling-integrity-violations}
 
   The user agent will refuse to render or execute responses that fail an integrity
-  check, instead returning a network error as defined in Fetch [[!FETCH]].
+  check, instead returning a network error as defined in Fetch [[!Fetch]].
 
   Note: On a failed integrity check, an `error` event is fired. Developers
   wishing to provide a canonical fallback resource (e.g., a resource not served