Add compression dictionary negotiation and decoding to the fetch processing model

[pmeenan]

What problem are you trying to solve?

Compression dictionary transport provides a mechanism for using fetched resources as a compression dictionary for content-encoding of HTTP responses. The IETF draft for the http-level negotiation and compression is here.

Most of the HTTP-level negotiation is defined in the IETF draft but there are a few places where it intersects with the fetch processing model:

• Dictionary cache, associated metadata, partitioning and clearing.
• Matching an existing dictionary against outbound requests in HTTP-network fetch.
• CORS-readability requirements for storing dictionaries.
• CORS-readability requirements for decoding dictionary-compressed responses.

What solutions exist today?

No response

How would you solve it?

Add the necessary processing steps once we are comfortable that they are appropriate.

Anything else?

Chromium is currently the only browser engine experimenting with compression dictionaries so it might not make sense to fold into the standard quite yet but it is worth having the discussion to make sure that the implementation is something that we can all agree with before it gets too far.

[pmeenan]

From WICG/compression-dictionary-transport#52, the integration needs to specify that the Use-As-Dictionary response header is only processed if it was on the final response in a redirect chain.

[annevk]

I think there is enough implementer interest to proceed here. Apologies for the lack of updates on WebKit/standards-positions#160 until now.