
The browser bugs and edge cases of HTTP/2 push - jaffathecake
https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/
======
avaer
Today I learned the modern browser has even more caches than I thought it did.

Actually, good web engineer interview question might be how many caches there
are in a web request. A good interview could easily end up with 20 on the
whiteboard.

~~~
roel_v
How do you get that high? Is that including eg cpu caches or just browser?

~~~
throwaway2048
Just a guess on my part here, () may or may not exist . This is not a
perfectly exact representation of the system, as in reality many steps here
are recursively recalled, and for most steps the CPU and disk phases occur.
I've certainly missed many.

( Application DNS cache) -> ( libc DNS cache ) -> ( gateway DNS cache ) -> (
DNS caching resolver cache ) -> ( DNS nameserver authoritative cache ) ->
Filesystem Cache -> Hard disk Device Cache -> ( JavaScript JIT cache ) -> HTTP
cache -> HTTP push cache -> HTTP Preload cache -> CPU L1 -> CPU L2 -> (CPU L3)
-> ( HTTP proxy cache ) -> (N hops invoking many of these steps N times) -> (
HTTP router/relay cache ) -> ( HTTP Reverse Proxy cache ) -> HTTP Server
request caching.

Because on some hops almost all of them are invoked for a request, we aren't
looking at 20 caches, we are looking at hundreds.

~~~
scrollaway
Even just at the browser level, there's also the CSS cache and Image cache as
well on every single page.

------
dullgiulio
The one thing that keeps on bugging me about HTTP/2 Push is that it
ignores/sidesteps all the usual cache logic.

If you are on mobile with limited GB (or expensive GBs) as it's always the
case, push can cause some heavy resources to be sent to you even after you
have them in the local cache.

The browser can cancel the stream, but once the stream is already arriving.

I am aware that there are cookie-based hacks, but... I really don't understand
why this didn't come up as a possible problem earlier during SPDY test etc.

~~~
ko27
Cache digest is a proper solution that will soon be standardized, it's not a
cookie-based hack. If you need it today, you can implement it by yourself,
just take any existing Bloom filter implementation.

~~~
DorothySim
For people interested in specs, here's the link:
[https://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-
cac...](https://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-cache-
digest-00.html)

~~~
jaffathecake
Here's a more up-to-date link [http://httpwg.org/http-extensions/cache-
digest.html](http://httpwg.org/http-extensions/cache-digest.html)

------
alex_duf
Really thorough article! thanks for sharing.

I'm wondering how long before the cache digest is used as a fingerprinting
mechanism.

~~~
jaffathecake
Cheers! Interesting point about the fingerprinting, although I can't think of
a way it's any worse than ETags.

~~~
alex_duf
My thoughts exactly. It can't be worse than cookies or ETags, but it's another
dimension on a vector of personal ids.

------
saurik
The lack of functional Vary in the non-Safari browsers sounds like a security
issue waiting to happen.

------
ko27
Even if it is not the silver bullet for every scenario, it will still solve
the need for in-lining scripts and styles, which is a big plus.

~~~
jaffathecake
Unless the user is using Safari, in which case it'll likely waste bandwidth.

Also, I don't think servers give us the correct priority control to replace
inlining. As things currently stand, if you spend bandwidth sending the body
of a page over pushing the critical CSS, you'll be slower than inlining.

------
sparewalking
HTTP/2 push is totally the problem browsers have today.

Not the damn CPU usage, not the enormous RAM consumption.

~~~
spiderfarmer
So because there are problems in one area, there shouldn't be progress
elsewhere?

