Re: Working Group Last Call: Compression Dictionary Transport

[Yoav Weiss <[e-mail]>]

On Thu, Jun 13, 2024 at 7:15 AM Martin Thomson <[e-mail]> wrote:

> On Thu, Jun 13, 2024, at 14:16, Yoav Weiss wrote:
> > Can you expand on that uncertainty? I don't think I get your concern.
>
> It might be nothing, but we haven't had enough time to implement and find
> out.  Consider that you have a bunch of resources in cache for a
> site/origin/whatever.  Some of them have Use-As-Dictionary attached.  When
> you fetch, the dumb implementation strategy here is to iterate your entire
> cache to find applicable Use-As-Dictionary matches, which requires a bunch
> of URL pattern tests.  That will be inefficient.
>

Yeah, I don't think this is the way to go.
The way I imagined deployments to happen for static assets is:
* Diffs are generated at build time (potentially asynchronously), compared
to the past N versions of that same resource
* The server that gets a Use-As-Dictionary header in a request can
immediately translate that to a filename of the relevant diff on disk
* If that diff exists, it responds with that. Otherwise, it responds with
the original URL.
* Vary headers (or custom CDN ones) ensure that intermediate caches
distinguish the two.


> Now, obviously, that inefficiency isn't what you would ship, but we
> haven't done the work to find an implementation strategy.  Given that we
> essentially only have one implementation of this right now in Chrome, it's
> not clear that their strategy will translate to other implementations
> (those in CDNs as well as browsers).
>
> We've been burned by this sort of performance optimization feature in the
> past.  Claims did not bear out when deployed more widely.  I've learned to
> be very skeptical of claims coming from a single implementation.
>
> All of which is to say, I think this needs time as an experiment.
>

I'll let Pat chime in with his thoughts, as I don't have strong opinions on
that particular front.