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

@fred-wang commented on this pull request.



> @@ -8527,7 +8699,7 @@ dictionary RequestInit {
   any window; // can only be set to null
 };
 
-enum RequestDestination { "", "audio", "audioworklet", "document", "embed", "font", "frame", "iframe", "image", "json", "manifest", "object", "paintworklet", "report", "script", "sharedworker", "style", "text", "track", "video", "worker", "xslt" };
+enum RequestDestination { "", "audio", "audioworklet", "compression-dictionary", "document", "embed", "font", "frame", "iframe", "image", "json", "manifest", "object", "paintworklet", "report", "script", "sharedworker", "style", "text", "track", "video", "worker", "xslt" };

Even if it's implementation-defined, it seems there is some motivation to have very low priority for "compression-dictionary" destinations and that seems to be what Chromium implements. What about having some non-normative note suggesting that?

(Note: I was checking if it's possible to write a test for fetchpriority, it is mentioned on https://html.spec.whatwg.org/multipage/semantics.html#processing-link-headers:link-processing-options-3 but does not seem to be exposed by https://fetch.spec.whatwg.org/#request ; so one really need to check the behavior, which is implementation-defined...)









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

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