Re: [whatwg/fetch] Add support for compression dictionary transport (PR #1854)

@fred-wang commented on this pull request.



> + then return a <a>network error</a>.
+
+ <li><p>Let <var>availableDictionaryItem</var> be the result of
+ <a for="header list">getting a structured field value</a> given <a><code>Available-Dictionary</code></a>,
+ "<code>item</code>", and <var>request</var>'s <a for=request>header list</a>.
+
+ <li><p>If <var>availableDictionaryItem</var> is null, then return a <a>network error</a>.
+
+ <li><p>Let <var>availableDictionaryHash</var> be the <a>bare item</a> of <var>availableDictionaryItem</var>.
+
+ <li><p>Let <var>newBody</var> be a new <a for=/>body</a> whose <a for=body>stream</a> is the
+ result of transforming <var>response</var>'s <a for=response>body</a>'s <a for=body>stream</a>
+ with an algorithm that verifies that the dictionary hash in the stream matches
+ <var>availableDictionaryHash</var> and decodes the rest of the stream with the applicable
+ algorithm as defined in [[!RFC9842]]. If verification or decoding fails,
+ error the transformed stream.

> The issue we need to protect against is a server responding with a dcb or dcz stream that was compressed with a dictionary other than the one requested (has happened to more than a few people when deploying because of incorrectly-configured Vary response headers).

I a few questions regarding this incorrectly-configured Vary response headers. I was re-reading https://datatracker.ietf.org/doc/html/rfc9842#section-6.2 and the Vary header is only required when serving cacheable compressed reponse (I assume for other content-encoding than dcb/dcz too but that's probably defined in other spec).

If I understand the issue you refer to is when the client first retrieves a resource with or without a compression dictionary for it, and then retrieves it again after a better matching dictionary become available or after the initial dictionary is removed from the cache. **Do we have tests for these cases?**

For these cases, the available-dictionary header would change and if the server properly setting the Vary header and if the client properly takes them into account, things should just work as expected...

That being said, searching for "vary", the only match is this test:
https://github.com/web-platform-tests/wpt/blob/92ce110bdfaafc84acc1e37b4bbae549f112b8aa/fetch/compression-dictionary/dictionary-registration.tentative.https.html#L62
and it says the opposite: browsers cache should not vary based on those headers!
I understand why the hash protection becomes even more relevant. **Is this behavior specified anywhere?**. https://chromium-review.googlesource.com/c/chromium/src/+/6634910 does not provide much context.

(incidentally, I submitted https://chromium-review.googlesource.com/c/chromium/src/+/8163980 to better align the server with RFC9842 while still testing this case)

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

Message ID: <whatwg/fetch/pull/1854/review/4796249405@github.com>