Re: Compression dictionary draft ID - draft-meenan-httpbis-compression-dictionary-00

Thanks. I'll update the draft shortly to fix the edits. We originally had
used the "s" prefix and changed to "-d" but looks like I missed a spot.

I'll also add the detail that the hash is hex encoded ASCII with the proper
casing (makes it much easier to deploy if encoded assets are stored with
the hash appended to the file name).

The match is supposed to be for the full url including query Paramus so ?
isn't much better and has the filesystem baggage of usually being a single
character.

As far as the match algorithm goes, it's a linear pass through the url and
match string plus some special handling at the beginning and end. I could
see a lot of wildcards causing it to take a bit longer but no explosion of
an exponential kind. There could be a fast exit added if the length of the
match string exceeds the length of the URL.

On Fri, Jun 30, 2023 at 2:53 PM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Fri, Jun 30, 2023 at 01:30:07PM -0400, Patrick Meenan wrote:
> > Yoav and I have put together a first draft of a proposal for Compressed
> > Dictionary Transport. It's currently an individual draft but we'd like to
> > see if the HTTP working group would be willing to adopt it so we can all
> > iterate on the spec and get to something that is hopefully
> > consensus-shippable.
> >
> > This is otherwise known as the latest attempt at "shared brotli"
> > compression but in a more generic form that supports brotli and zstd and
> > hopefully resolves the security and privacy concerns of previous
> attempts.
> >
> > The draft is here:
> >
> https://datatracker.ietf.org/doc/draft-meenan-httpbis-compression-dictionary/
> >
> > The explainer (with examples and some browse-specific HTML bits) is here:
> > https://github.com/WICG/compression-dictionary-transport
> >
> > Some of the field names have changed since the explainer and I expect
> > bikeshedding will refine them further.
> >
> > Chrome will be running a field trial of the compression in the next few
> > months to gather developer feedback and see how it works for deploying.
> > The spec is hopefully written in such a way that it is not specific to
> the
> > browser use case but does have some additional carve-outs for some of the
> > browser-specific privacy concerns.
>
> Some quick comments:
>
> - Allowing absolute URLs in match is a footgun, since dictionaries are
>   restricted to same-origin. I don't think any of the usual URI
>   productions are suitable here.
>
>   I think most suitable would be 'segment *( "/" segment )', where
>   segment is the production from RFC 3986.
>
> - If match patterns are intended to be paths, one could use ? as the
>   wildcard, avoiding double meanings, since HTTP paths can not contain
>   ?.
>
> - It is not clear how Sec-Available-Dictionary is encoded. Is it
>   hex encoding? base64 encoding? base64url encoding? Something
>   else?
>
>   One could use sf-binary with the binary hash value.
>
> - Can that match algorithm blow up in runtime?
>
> - One place calls the encodings "br-d" and "zstd-d" and IANA
>   considerations seem to have "sbr" and "szstd".
>
>
>
>
> -Ilari
>
>