Re: Negotiating Window Limits for Content Encodings

> On Aug 4, 2021, at 2:47 PM, W. Felix Handte <w@felixhandte.com> wrote:
> 
> Hello all,
> 
> I hope you had a pleasant IETF 111.
> 
> TL;DR:
> 
> I want to specify an option along these lines:
> 
>  Accept-Encoding: zstd;w=18
> 
> Which in this case would mean that a client will accept a
> zstd-compressed response, only if the window size is less than or equal
> to 256KB (2 ** 18 bytes).

Hi Felix,

Accept-Encoding doesn't work that way because it results in a proliferation
of encodings and unique request field values, which has an extremely negative
impact on shared caching and Vary. That's why we don't do dynamic window
tweaks with Accept-Encoding.

If you happen to use Transfer-Encoding instead, those problems wouldn't apply
(but then you have another set of problems regarding implementations).

In general, when you can expect different clients to have different/unique
resource limitations in the processing of representations, what you want to do
is provide different sites (or different path hierarchies) for those resources
such that all of the similar clients operate within the same resource space and
make effective use of caching all the way down the delivery chain.

Request fields are the wrong place to negotiate window sizes. That should be
done within the client itself, prior to making a request, with code that takes
a list of available window sizes, matches that to the user agent's desired size,
and then uses something like a URI template to construct the right resource
target to retrieve. This can be done with links and media types, without
changing HTTP, or even by the traditional mechanism of informing the user
via hypertext and having them choose which link to select. It can be
entirely automated if the patterns are standardized.

Another workaround is to define different coding names for different window
sizes. That at least narrows the proliferation of choice to a common set of
maximum window sizes, rather than an arbitrary integer.  For example, register
zstd-tiny, zstd, zstd-big, and zstd-huge (or zstd-mb, zstd-gb, zstd-tb).
That better aligns with how implementations work in practice -- picking
a fixed max rather than arbitrarily changing it on the fly.

Cheers,

....Roy

Received on Thursday, 5 August 2021 18:08:54 UTC