3 ms·

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 expen

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 9y ago
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 9y ago
  For people interested in specs, here's the link: https://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-cache-digest-00.html https://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-cac...
  - jaffathecake 9y ago
    Here's a more up-to-date link http://httpwg.org/http-extensions/cache-digest.html http://httpwg.org/http-extensions/cache-digest.html
tootie 9y ago
You can just not push optional resources. Or push the smallest responsive asset and let the full-scale one come in if requested. Just because it doesn't handle every edge case doesn't make it a failure. Being able to push required dependencies without a round trip is a huge boon for those same mobile users that might have restricted bandwidth.
- matharmin 9y ago
  If the mobile user already has those resources cached, it ends up using more bandwidth. It's possible implement checks for this, but it can be tricky to get right for all cases. On the other hand, the browser's HTTP cache is well understood and standardised, and just requires sending the correct response headers (at the cost of the additional round trip).
  - WorldMaker 9y ago
    The spec gives the browser the ability to cancel a push in the case that it already has the resource cached. Testing that was one of the pieces of the linked article, because not all of the browsers implement that yet and have somewhat different behaviors.

ko27 9y ago

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 9y ago
For people interested in specs, here's the link: https://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-cache-digest-00.html https://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-cac...
- jaffathecake 9y ago
  Here's a more up-to-date link http://httpwg.org/http-extensions/cache-digest.html http://httpwg.org/http-extensions/cache-digest.html

tootie 9y ago

You can just not push optional resources. Or push the smallest responsive asset and let the full-scale one come in if requested. Just because it doesn't handle every edge case doesn't make it a failure. Being able to push required dependencies without a round trip is a huge boon for those same mobile users that might have restricted bandwidth.

matharmin 9y ago
If the mobile user already has those resources cached, it ends up using more bandwidth. It's possible implement checks for this, but it can be tricky to get right for all cases. On the other hand, the browser's HTTP cache is well understood and standardised, and just requires sending the correct response headers (at the cost of the additional round trip).
- WorldMaker 9y ago
  The spec gives the browser the ability to cancel a push in the case that it already has the resource cached. Testing that was one of the pieces of the linked article, because not all of the browsers implement that yet and have somewhat different behaviors.