Skip to content

Commit bfa30a6

Browse files
Merge pull request #460 from fmarier/sri-remove-fetch-modifications
SRI: Remove "Fetch Modifications" section
2 parents ee2d941 + 67b7cab commit bfa30a6

File tree

1 file changed

+6
-64
lines changed

1 file changed

+6
-64
lines changed

specs/subresourceintegrity/spec.markdown

Lines changed: 6 additions & 64 deletions
Original file line numberDiff line numberDiff line change
@@ -30,7 +30,7 @@ server, but also pin the _content_, ensuring that an exact representation of
3030
a resource, and _only_ that representation, loads and executes.
3131

3232
This document specifies such a validation scheme, extending two HTML elements
33-
and the `fetch()` API with an `integrity` attribute that contains a cryptographic hash
33+
with an `integrity` attribute that contains a cryptographic hash
3434
of the representation of the resource the author expects to load. For instance,
3535
an author may wish to load some framework from a shared server rather than hosting it
3636
on their own origin. Specifying that the _expected_ SHA-256 hash of
@@ -191,7 +191,8 @@ used to verify the response.
191191
### Integrity metadata
192192

193193
To verify the integrity of a response, a user agent requires <dfn>integrity
194-
metadata</dfn>, which consists of the following pieces of information:
194+
metadata</dfn> as part of the [request][]. This metadata consists of the following
195+
pieces of information:
195196

196197
* cryptographic hash function ("alg")
197198
* [digest][] ("val")
@@ -223,6 +224,7 @@ result of the following command line:
223224

224225
echo -n "alert('Hello, world.');" | openssl dgst -sha256 -binary | openssl enc -base64 -A
225226

227+
[request]: https://fetch.spec.whatwg.org/#concept-request-integrity-metadata
226228
[csp2-section42]: http://www.w3.org/TR/CSP2/#source-list-syntax
227229
[openssl]: https://www.openssl.org/
228230
</div>
@@ -466,64 +468,6 @@ warning message to the developer console to explain this failure.
466468
</section><!-- Algorithms::Match -->
467469
</section><!-- Algorithms -->
468470

469-
<section>
470-
### Modifications to Fetch
471-
472-
The Fetch specification should contain the following modifications in order
473-
to enable the rest of this specification's work [[!FETCH]]:
474-
475-
1. The following text should be added to [section 2.1.4][fetch-requests]: "A
476-
[request][fetch-request] has an associated [integrity metadata][].
477-
Unless stated otherwise, a request's integrity metadata is the empty
478-
string."
479-
480-
2. Perform the following step between steps 10 and 11 in the "[main fetch][]"
481-
algorithm:
482-
483-
1. If <var>request</var>'s integrity metadata is a non-empty string and
484-
<var>response</var> is not a [network error][]:
485-
1. Wait for either end-of-file to have been pushed to
486-
<var>response</var>'s body or for <var>response</var> to have a
487-
[termination reason][].
488-
2. If <var>response</var> does not have a [termination reason][] and
489-
<var>response</var> does not [match][] the [integrity metadata][] of
490-
the <var>request</var>, set <var>response</var> to a
491-
[network error][].
492-
493-
3. Add the following to the [Request class definition][fetch-request-api]:
494-
495-
1. Add the following attribute to the <code>Request</code> class after the
496-
<code>redirect</code> attribute as follows:
497-
498-
readonly attribute DOMString integrity;
499-
2. Add the following member to the end of the <code>RequestInit</code>
500-
dictionary:
501-
502-
DOMString integrity = "";
503-
504-
3. In step 4 of the constructor, modify the end of the step to read, "and
505-
[integrity][integrity metadata] is <var>request</var>'s
506-
[integrity][integrity metadata]."
507-
508-
4. Perform the following steps after step 19 of the constructor:
509-
1. Set <var>request</var>'s [integrity][integrity metadata] to the value
510-
of <var>init</var>'s [integrity][integrity metadata] member.
511-
512-
5. Add the following to the list of descriptions after the constructor:
513-
514-
"The <code>integrity</code> attribute's getter must return
515-
[request][fetch-request]'s <var>integrity</var>."
516-
517-
[fetch-requests]: https://fetch.spec.whatwg.org/#requests
518-
[fetch-request]: https://fetch.spec.whatwg.org/#concept-request
519-
[fetch-request-api]: https://fetch.spec.whatwg.org/#request
520-
[basic fetch]: https://fetch.spec.whatwg.org/#basic-fetch
521-
[CORS fetch with preflight]: https://fetch.spec.whatwg.org/#cors-fetch-with-preflight
522-
[main fetch]: https://fetch.spec.whatwg.org/#main-fetch
523-
[termination reason]: https://fetch.spec.whatwg.org/#concept-response-termination-reason
524-
[network error]: https://fetch.spec.whatwg.org/#concept-network-error
525-
</section>
526-
527471
<section>
528472
### Verification of HTML document subresources
529473

@@ -598,9 +542,8 @@ attribute DOMString integrity
598542
<section>
599543
#### Handling integrity violations
600544

601-
The user agent MUST refuse to render or execute responses that fail an
602-
integrity check <em>and</em> MUST return a network error, as described in
603-
[Modifications to Fetch][].
545+
The user agent will refuse to render or execute responses that fail an integrity
546+
check, instead returning a network error as defined in Fetch [[!FETCH]].
604547

605548
On a failed integrity check, an <code>error</code> event is thrown. Developers
606549
wishing to provide a canonical fallback resource (e.g., a resource not served
@@ -609,7 +552,6 @@ from a CDN, perhaps from a secondary, trusted, but slower source) can catch this
609552
failed resource with a different one.
610553
{:.note}
611554

612-
[Modifications to Fetch]: #modifications-to-fetch
613555
</section>
614556

615557
<section>

0 commit comments

Comments
 (0)