Accept-Encoding in Variants

[irori]

When fetching a Signed Exchange, Chromium sets Accept-Encoding request header to gzip, deflate, br. However, actually Chromium accepts differnt set of content encodings for Signed Exchange's outer and inner responses. gzip, deflate, and br are supported for outer responses, and only mi-sha256-03 is supported for inner responses.

This is problematic when performing the Request Matching. For example if exchange has:

 Variants: Accept-Encoding;mi-sha256-03
 Variant-Key: mi-sha256-03

It will not match the browserRequest which has Accept-Encoding: gzip, deflate, br.

What should we do?

Ideas:

• When making a redirect to the inner response, overwrite the request's Accept-Encoding header to mi-sha256-03.
• Or, specify that Cache Behavior for Request Matching does not support Accept-Encoding content negotiation, because it makes little sense for signed exchange's inner responses (?)

[jyasskin]

In the long run, I think it'll be useful to support encoded inner responses in bundles to optimize local disk storage. Since signed exchanges don't need to be random access, it's less important to support compressing the inner response if that makes the implementation trickier.

In the short run, I think it'd be fine to say that seeing Accept-Encoding in the Variants header results in a mismatch from https://wicg.github.io/webpackage/loading.html#request-matching. I won't get around to this in the next couple weeks.

[jimmywarting]

I think it'll be useful to support encoded inner responses in bundles to optimize local disk storage. Since signed exchanges don't need to be random access

👍

it don't make any since to (de)encode things like video and images that are already compressed... So it would be wasteful to compress the hole web bundle