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

@pmeenan 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.

Cache implementations where it comes to dictionary-compressed assets can be "complicated". ACTUALLY varying on the `Available-Dictionary` is important for middle-boxes to make sure they serve the correct dictionary-compressed asset to clients that actually have the dictionary that was used to compress the resource. For something like delta-encoded script libraries, the "current" version might be compressed against the last N different previous versions so that a delta can be sent relative to whatever a given client has from when they last visited (particularly for apps that update their scripts frequently).

The browser's private cache is orders-of-magnitude more complicated:

- If the browser varies based on `Available-Dictionary` and a response's `Use-As-Dictionary` header includes itself in the `match` pattern (common for delta-updating scripts), then a cached visit to the same page that uses the same library will now have an `Available-Dictionary` of the hash of the current version of the code, not matching whatever it sent the first time, resulting in a cache miss even though the resource hasn't changed. It turns a cacheable resource into a 1-time cache miss, every time.

- If the browser STORES the response in cache in dictionary-compressed form, the cached version now depends on the dictionary used at fetch time being available to decode the response. If that dictionary was also a dictionary-compressed response then it also depends on the dictionary that was used for it's original request, creating a very long, fragile dependency chain. This can be solved a few different ways at implementation time (keep the dictionary dependency but make sure the dictionary is stored in it's whole form or cache a decoded version of the response). I'm not sure we want to force any specific implementation decisions on how clients handle the dependency chain issue internally (though it is probably worth making sure it is documented for their awareness).

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

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