Added support for link rel=compression-dictionary

[pmeenan]

Add processing steps for handling the "compression-dictionary" link relation type defined in HTTP Compression Dictionary Transport.

It largely mirrors the support for prefetch but also adds a default crossorigin mode of "cors" anonymous (necessary for dictionaries to be usable in a third-party context).

Fix #11619

• At least two implementers are interested (and none opposed):
  • Chrome
  • Firefox
  • Safari
• Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/tree/master/fetch/compression-dictionary
  • PR for removal of "tentative": Removed tentative from compression dictionary tests web-platform-tests/wpt#54532
• Implementation bugs are filed:
  • Chromium: https://crbug.com/1413922
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1882979
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=295249
• Corresponding HTML AAM & ARIA in HTML issues & PRs:
• MDN issue is filed: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport
• The top of this comment includes a clear commit message to use.

---

/index.html ( diff )
/links.html ( diff )
/references.html ( diff )
/semantics.html ( diff )

[pmeenan]

RFC is pending publication so this should wait until it has been published (any day now - final edits are complete).

[domenic]

Double-checking that this is intended? https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/ seems to imply the Link: header should work, but this mandates that in browsers it do nothing.

[pmeenan]

Thanks. Mistake from mirroring the prefetch behavior. Should be fixed now. The flow feels a bit weird since I merged the header and link element processing steps but need to not fire the load/error in the header side of things (made el optional to the processing). Happy for suggestions on ways to make it cleaner.

Presumably we could also treat it more like preconnect and fire-and-forget without load/error events.

[domenic]

I think the intended pattern is supposed to be like what preload does. I believe you could make that work, but I haven't double-checked...

[domenic]

The structure here is a bit surprising for me, in that you have HTML just do a fetch, and then do nothing with the response.

Instead, you seem to have located the response processing all in whatwg/fetch#1854. I can understand that if the goal is that there are many places that should be able to trigger that processing, e.g., if you want to be able to trigger it from fetch(). But, if HTML is the only place on the web platform that can set a "compression-dictionary" initiator, what is the point of that?

A more normal processing model would be to process the response in HTML, and not modify Fetch much. Was that considered?

[pmeenan]

The structure here is a bit surprising for me, in that you have HTML just do a fetch, and then do nothing with the response.

Instead, you seem to have located the response processing all in whatwg/fetch#1854. I can understand that if the goal is that there are many places that should be able to trigger that processing, e.g., if you want to be able to trigger it from fetch(). But, if HTML is the only place on the web platform that can set a "compression-dictionary" initiator, what is the point of that?

A more normal processing model would be to process the response in HTML, and not modify Fetch much. Was that considered?

Compression dictionaries are a transport-layer content-encoding and entirely handled within fetch. For the most part they should be completely transparent to HTML. Any HTTP response for any fetch can be stored as a compression dictionary and, usually, none of that will even be visible from HTML.

We did need a way to trigger a fetch for triggering the request of a dictionary that would not have otherwise been loaded (which will then be treated like any other response and handled entirely at the HTTP layer). preload and prefetch both would have worked fine (and can still work if someone uses them and they have the appropriate response headers) but by using a dedicated relation type we can avoid triggering fetches from clients that don't support compression dictionaries.

It also allows for adjusting the priorities and timing of the fetch independently from prefetches and preloads.

[domenic]

Any HTTP response for any fetch can be stored as a compression dictionary and, usually, none of that will even be visible from HTML.

Got it. I misunderstood the role of the compression-dictionary initiator. It is not required that the request initiator be set to compression-dictionary, for the response to be used as such.

In that case, I agree with the design split.

[pmeenan]

The RFC finally published so this should be ready for review now (just rebased it).

[domfarolino]

I don't think this data-x is required here, if the text content matches it.

[domfarolino]

Is this ref required? We're not referencing any definition from that spec, right? (Maybe I don't understand all the ref rules and Anne can correct me).

[domfarolino]

This is already the empty string, per https://html.spec.whatwg.org/C#link-options-destination right?

[domfarolino]

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 Link header requests. Is my understanding correct, and do we have tests for this behavior?

We haven't really had a pressing need to spec the Link header processing model on subresource requests, but if that's one of the main and expected ways of engaging with this new feature, and we have tests for it, perhaps it's important enough to invest in.