Re: Call for Adoption: draft-meenan-httpbis-compression-dictionary

> On Aug 9, 2023, at 6:58 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Everyone,
> 
> Discussion at IETF117 seemed to indicate strong support for, and no significant pushback against, restarting work on dictionary compression, based on this draft:
> 
>  https://datatracker.ietf.org/doc/draft-meenan-httpbis-compression-dictionary/
> 
> So, this e-mail begins its Call for Adoption; please indicate your support or lack thereof (ideally, with reasons). The CfA will end on 2023-08-24 , after which the Chairs will make a determination.

I support the idea of using shared dictionaries for transfer compression.

I think implementation of such through content-codings is fundamentally
misguided because it changes the resource itself and impacts all caching
along the chain of requests in ways that are non-recoverable. That is due
to the lost metadata and variance on whatever request field is used to indicate
that some downstream client can grok some possible dictionary.

In short, it looks like an easy solution for a browser, but will wreak
havoc with the larger architecture of the Web.

The right way to do this is to implement it as a transfer encoding that
can be decoded without loss or confusion with the unencoded resource,
which would require extending h2 and h3 to support that feature of HTTP/1.1.

For the existing draft, there is a lot of unnecessary confusion regarding
features of fetch, like CORS, that don't make any sense from a security
perspective. That's not what CORS is capable of covering, nor how it is
implemented in practice, so reusing it doesn't make any sense. 
The same goes for use of the Sec- prefix on header fields.

Allowing a response from one origin to define a compression dictionary
for responses received from some other origin would clearly violate the
assumptions of https in so many ways (space, time, and cross-analysis).
I don't see how we could possibly allow that even if both origins were
covered by the same certificate. It would be far easier to require that
everything have the same origin (as defined in RFC9110, not fetch) or
by having the response origin define specifically which dictionary is
being used (identifying both the dictionary URL and hash).  In the latter
case, it would be possible to pre-define common dictionaries and thus
reduce or remove the need to download them.

Likewise, using * as a wildcard in arbitrary URL references is a foot gun.
It would make more sense to have two attributes, prefix and suffix, and
have them only match within the URL path (i.e., exclude the origin and
query portions, preventing matches on full URIs or user-supplied
query parameters). That is far more likely to get right than allowing
things like "//example.com/*/*/*/*/****"

Cheers,

....Roy T. Fielding
    Senior Principal Scientist, Adobe

Received on Thursday, 17 August 2023 17:51:45 UTC