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

@fred-wang 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>,

Correction:

- Actually "Dictionary registration with empty match-dest list acts as wildcard" and "Dictionary with unknown match-dest is not used for fetch() API" are contradictory. Since the unknown match-dest is removed they should behave the same. But one expect a dictionary to be registered without a match-dest requirement while the other expect the dictionary to be ignored.

- IIUC "New dictionary registration overrides the existing one" is already exercising the case I mentioned "Two Use-As-Dictionaries with the same match's length and matchDest's emptiness but different fetch time (the most recent wins)." so I guess the case missing is just priority of non-empty match-dest over empty match-dest.

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

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