@@ -328,12 +328,12 @@ resources accessed over a `file` scheme URL are unlikely to be
328
328
eligible for integrity checks.
329
329
{:.note}
330
330
331
- One should note that being a [ secure document] [ ] (e.g. a document delivered
331
+ One should note that being a [ secure document] [ ] (e.g., a document delivered
332
332
over HTTPS) is not necessary for the use of integrity validation. Because
333
333
resource integrity is only an application level security tool, and it does not
334
334
change the security state of the user agent, a [ secure document] is
335
335
unnecessary. However, if integrity is used in something other than a [ secure document] [ ]
336
- (e.g. a document delivered over HTTP), authors should be aware that the integrity
336
+ (e.g., a document delivered over HTTP), authors should be aware that the integrity
337
337
provides <em >no security guarantees at all</em >. For this reason, authors should
338
338
only deliver integrity metadata on a [ potentially secure origin] [ ] . See
339
339
[ Non-secure contexts remain non-secure] [ ] for more discussion.
@@ -598,7 +598,7 @@ integrity check <em>and</em> MUST return a network error, as described in
598
598
[ Modifications to Fetch] [ ] .
599
599
600
600
On a failed integrity check, an <code >error</code > event is thrown. Developers
601
- wishing to provide a canonical fallback resource (e.g. a resource not served
601
+ wishing to provide a canonical fallback resource (e.g., a resource not served
602
602
from a CDN, perhaps from a secondary, trusted, but slower source) can catch this
603
603
<code >error</code > event and provide an appropriate handler to replace the
604
604
failed resource with a different one.
0 commit comments