[TacticalCoder]

> Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

The savings are nice in the best case (like in TFA: switching from version 1.3.4 to 1.3.6 of a lib or whatever) but that Base64 encoded hash is not compressible and so this line basically adds 60+ bytes to the request.

Kinda ouch for when it's going to be a miss?

[dspillett]

Maybe.

Though from the client side 60 bytes is likely not really noticeable¹ as a delay in the request send. Perhaps server side, which is seen many many client requests, will see an uptick in incoming bandwidth used, but in most cases servers responding to HTTP(S) requests see a lot more outgoing traffic (response sizes are much larger than requests sizes, on average), so have enough incoming bandwidth “spare” that it is not going to be saturated to the point where this has a significant effect.

--

[1] if the link is slow enough that several lots of 60 bytes is going to have much effect² it likely also has such high latency that the difference is dwarfed by the existing delays.

[2] a spotty GRPS connection? is anything slower than that in common use anywhere?

[sethev]

If 60 bytes per request is a material overhead, then your workload is unlikely to benefit from general purpose compression of any kind.

[pornel]

Upload is usually slower, more latency sensitive, and suffers from tcp cold start. Pages also make lots of small requests, so header overhead can add up. HTTP/2 added header compression for these reasons.

[nevir]

What are the chances that the ~60 bytes are going to push the request over the frame size and end up splitting into another packet?

[adrianmonk]

Aren't misses pretty preventable?

The only reason the client is even asking is that the server sent them a header saying it might be beneficial to do so.

And the client definitely has the dictionary data. The only thing it needs is for the server to accommodate the request after leading it down that path in the first place.

I can picture how it could happen, though. If you didn't realize the cost, you might not try to prevent misses. Or you could have a configuration error like sending the header but forgetting to generate pre-compressed data in your build.

If this is a significant issue, a server could collect stats and generate warnings about situations where it's not pulling its weight. Or even automatically disable it if hit rates are terrible.

[tarasglek]

chrome team usually trials changes like this with extensive a/b testing via telemetry. Got to be a large overall win even with this.

[sillysaurusx]

Clearly we’ll need to use a shared dictionary to compress this.

[lozenge]

It might be compressible. HTTP/3 includes compression of request headers. Base64 doesn't use the top two bits in a byte so it's compressible.