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

@pmeenan commented on this pull request.



> +   "<code>dictionary</code>", and <var>response</var>'s <a for=response>header list</a>.
+
+   <li><p>If <var>dictionaryValue</var> is null or <var>dictionaryValue</var>["<code>match</code>"]
+   does not <a for=map>exist</a>, then return <var>response</var>.
+
+   <li><p>Let <var>compressionDictionaryCache</var> be the result of
+   <a>determining the compression-dictionary cache partition</a> given <var>request</var>.
+
+   <li><p>If <var>compressionDictionaryCache</var> is null, then return <var>response</var>.
+
+   <li><p>Let <var>pattern</var> be the result of
+   <a for=/>creating a URL pattern</a> given the bare item of <var>dictionaryValue</var>["<code>match</code>"],
+   the <a lt="URL serializer">serialization</a> of <var>request</var>'s <a for=request>current URL</a>,
+   and an empty map.
+
+   <li><p>If <var>pattern</var> is failure or <var>pattern</var> <a for=/>has regexp groups</a>,

Thanks, I'll update the tests (may take a week to make it through the plumbing). 

As far as priority goes, path specificity is the only factor in prioritization (with freshness being a tie-breaker). `match-dest` is just a filter for what candidates can be considered.

For the unknown types, I'll see if something is broken with the current spec language and update it but the intent is:
- Default to match-everything (by defaulting to an empty list)
- If a `match-dest` are specified and it is not an empty list, ONLY match if the current dest is in the list.

For unsupported dests, this likely means we don't want to register them at all since there is nothing they could match and we don't want them to be treated like a wildcard. This might need some additional logic in the registration flow to remember the initial state of the `match-dest` list (empty or not) before filtering for known dest's and then drop the registration if the list is empty but it wasn't initially empty.

We want to avoid the case of a new dest being introduced and dictionaries that are targeting that dest accidentally behaving like a wildcard (and maybe taking priority over all other dictionaries for browsers that don't support the new dest).

> + 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.

I'll see if I can find a better way to plumb the error that isn't hand-wavy (FWIW, I'm not all that well versed in writing specs so thanks for pushing on these unclear cases).

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

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