Re: [whatwg/fetch] Handle `Unencoded-Digest` assertions. (PR #1867)

@annevk commented on this pull request.



> + <var>list</var>.
+
+ <li><p>If <var>value</var> is null, then return <b>verified</b>.
+
+ <li>
+  <p><a for="list">For each</a> <var>algorithm</var> → <var>digest</var> of <var>value</var>:
+
+  <ol>
+   <li>
+    <p>Switch on <var>algorithm</var>:
+
+    <dl class=switch>
+     <dt>"<code>sha-256</code>"
+     <dd>
+      <ol>
+       <li><p>Let <var>body digest</var> be the result of executing the SHA-256 algorithm on

bodyDigest*

> +       <li><p>Let <var>body digest</var> be the result of executing the SHA-256 algorithm on
+       <var>bytes</var>. [[!FIPS-180-4]]
+
+       <li><p>If <var>body digest</var> is <var>digest</var>, <a for="iteration">continue</a>.
+      </ol>
+
+     <dt>"<code>sha-512</code>"
+     <dd>
+      <ol>
+       <li><p>Let <var>body digest</var> be the result of executing the SHA-512 algorithm on
+       <var>bytes</var>. [[!FIPS-180-4]]
+
+       <li><p>If <var>body digest</var> is <var>digest</var>, <a for="iteration">continue</a>.
+      </ol>
+
+     <dt><b>Otherwise</b>

No need for `<b>`

> +
+     <dt><b>Otherwise</b>
+     <dd><p><a for="iteration">Continue</a>.
+    </dl>
+
+   <li><p>Return <b>failed</b>.
+  </ol>
+
+ <li><p>Return <b>verified</b>.
+</ol>
+
+<p class="note">This algorithm requires all valid digests delivered via
+`<a http-header><code>Unencoded-Digest</code></a>` to match the response’s decoded body, while
+ignoring unknown algorithms. Since the server controls both the body and the headers, it seems
+unnecessary to allow the flexibility of allowing the asserted digests to match more than one
+resource (as we do in client-initiated checks via [[SRI]], which need to support servers'

References go at the end of a paragraph. If you want something inline you have to use `<cite>` and such.

> @@ -5022,7 +5098,9 @@ steps:
   <p class=note>This standardizes the error handling for servers that violate HTTP.
 
  <li>
-  <p>If <var>request</var>'s <a for=request>integrity metadata</a> is not the empty string, then:
+  <p>If <var>request</var>'s <a for=request>integrity metadata</a> is not the empty string, or if

```suggestion
  <p>If <var>request</var>'s <a for=request>integrity metadata</a> is not the empty string or
```

> @@ -5022,7 +5098,9 @@ steps:
   <p class=note>This standardizes the error handling for servers that violate HTTP.
 
  <li>
-  <p>If <var>request</var>'s <a for=request>integrity metadata</a> is not the empty string, then:
+  <p>If <var>request</var>'s <a for=request>integrity metadata</a> is not the empty string, or if
+  <var>internalResponse</var>'s <a for="response">header list</a> <a for="header list">contains</a>
+  `<a http-header><code>Unencoded-Digest</code></a>`, then:

```suggestion
  `<a http-header><code>Unencoded-Digest</code></a>`:
```

> +  <p>If <var>request</var>'s <a for=request>integrity metadata</a> is not the empty string, or if
+  <var>internalResponse</var>'s <a for="response">header list</a> <a for="header list">contains</a>
+  `<a http-header><code>Unencoded-Digest</code></a>`, then:

But we don't want SRI to work for opaque responses so there will be some mismatches in the overall model. Is the idea that SRI also ends up poking at the header list?

I'm not a big fan of us poking at the internal header list as it means this is yet another header that cannot be hidden from web content processes.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1867#pullrequestreview-3482738355
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1867/review/3482738355@github.com>