Added support for link rel=compression-dictionary #11620
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -27791,17 +27791,19 @@ document.body.appendChild(wbr);</code></pre> | |
| removed.</p></li> | ||
| </ul> | ||
|
|
||
| <p>The <span>fetch and process the linked resource</span> steps for this type of linked resource, | ||
| given a <code>link</code> element <var>el</var>, are to <span | ||
| data-x="create link options from element">create link options</span> from <var>el</var> and | ||
|
Contributor
There was a problem hiding this comment. So I guess there is a bunch of options to be tested here: https://html.spec.whatwg.org/#create-link-options-from-element ; dictionary-fetch-with-link-element.tentative.https.html seems quite limited with only a test for crossorigin=anonymous (which is also default).
Contributor
There was a problem hiding this comment. Chromium does not seem to pass down the
Contributor
There was a problem hiding this comment. OK, I went over https://html.spec.whatwg.org/multipage/semantics.html#create-link-options-from-element and I think we have some satisfying coverage here: crossorigin: https://chromium-review.googlesource.com/c/chromium/src/+/8098207 |
||
| to <span>load a compression dictionary</span> given the result and <var>el</var>.</p> | ||
|
|
||
| <p>The <span>process a link header</span> step for this type of linked resource given a <span | ||
|
Member
There was a problem hiding this comment. My understanding from TPAC is that compression dictionary responses are intended to be processed almost primarily on subresource requests. But this header-processing algorithm does not run in those cases, and in fact we do not have a spec'ed processing model for subresource We haven't really had a pressing need to spec the
Contributor
Author
There was a problem hiding this comment. The The main use case envisioned is for a HTML document to trigger the loading of a dictionary that would be used in future document requests (compressing away the common HTML templates). That said, I am sure someone would have a use case for triggering a separate dictionary request from subresources and that might be something Chrome currently allows (along with preload and preconnect) though there are ongoing discussions about how those should be handled to avoid tracking concerns. The dictionary use case for subresource link headers should probably be included in whatever spec work we do to specify the behavior for preconnect and preload. Right now the only WPT tests that use the
Contributor
There was a problem hiding this comment.
Contributor
There was a problem hiding this comment. Note that this is also used by https://html.spec.whatwg.org/#process-link-headers (I guess the use case is even less important, but technically we should have WPT test for that too)
Contributor
There was a problem hiding this comment. Sorry, I was talking about Early hints here:
Contributor
There was a problem hiding this comment. Tentative test for this: web-platform-tests/wpt#61119 This is currently only implemented in Firefox (as I mentioned this use case is probably not super important...) |
||
| data-x="link processing options">link processing options</span> <var>options</var> are to | ||
| <span>load a compression dictionary</span> given <var>options</var>.</p> | ||
|
Contributor
There was a problem hiding this comment. Same here, I don't see a lot of options tested for dictionary-fetch-with-link-header.tentative.https.html
Contributor
There was a problem hiding this comment. As commented above I added several tests for options, although often it's only for the link element only, for which one can configure things via attributes. We could add similar tests for link header. |
||
|
|
||
| <p>To <dfn>load a compression dictionary</dfn> given a <span>link processing options</span> | ||
| <var>options</var> and optional <code>link</code> element <var>el</var>:</p> | ||
|
|
||
| <ol> | ||
| <li><p>If <var>options</var>'s <span data-x="link options crossorigin">crossorigin</span> | ||
| is <span data-x="attr-crossorigin-none">No CORS</span>, set <var>options</var>'s | ||
| <span data-x="link options crossorigin">crossorigin</span> to | ||
|
|
@@ -27824,12 +27826,12 @@ document.body.appendChild(wbr);</code></pre> | |
| <span>byte sequence</span> <var>bytesOrNull</var>:</p> | ||
|
|
||
| <ol> | ||
| <li><p>If <var>response</var> is a <span>network error</span> and <var>el</var> is set, <span | ||
| data-x="concept-event-fire">fire an event</span> named <code | ||
| data-x="event-error">error</code> at <var>el</var>.</p></li> | ||
|
Contributor
There was a problem hiding this comment. Can we please add WPT tests for these two events? (for both Link header and element).
Contributor
There was a problem hiding this comment. Tentative test at https://chromium-review.googlesource.com/c/chromium/src/+/8036725 for Link header, I'm unsure there is reasonable way to check the load/error are not dispatched, since we don't have link anyway... |
||
|
|
||
| <li><p>Otherwise, if <var>el</var> is set, <span data-x="concept-event-fire">fire an event</span> | ||
| named <code data-x="event-load">load</code> at <var>el</var>.</p></li> | ||
| </ol> | ||
| </li> | ||
|
|
||
|
|
@@ -27839,9 +27841,6 @@ document.body.appendChild(wbr);</code></pre> | |
| <var>request</var> to prioritize other requests that are necessary for the current document.</p></li> | ||
| </ol> | ||
|
|
||
|
|
||
| <h5>Link type "<dfn attr-value for="link/rel"><code | ||
| data-x="rel-dns-prefetch">dns-prefetch</code></dfn>"</h5> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is copied from prefetch, but for future reference this does not really match what browsers do, at least Chromium can also process link elements after mutations of
typeattribute,mediaattribute etc https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_link_element.cc?q=HTMLLinkElement::ParseAttribute&ss=chromium%2Fchromium%2Fsrc ; see also #11400 for some interpretation of "changes".