6 ms·

So wait, if the server pushes assets before the client request it, does that mean the server pushes them regardless of the cache status on the client? If so th

So wait, if the server pushes assets before the client request it, does that mean the server pushes them regardless of the cache status on the client? If so that should really be limited to small assets to be beneficial

Clownshoesms 10y ago
I think it still obeys the browser's cache: "When the user navigates to a subsequent page that requires that asset, it can be pulled from the cache, eliminating the need for additional requests to the server." I'm not clear on if there is any relation to existing cache headers. I would have thought even the first page hit could have Link'ed assets pulled from the cache if present (if the client had previously visited that push-enabled resource (edit: in which case it's not the first I guess zzz). I guess the client, upon hitting a cached asset referenced in a Link header ignores it where otherwise it'd suck it down the socket as part of the same initial request.
mozumder 10y ago
The H2O server, on the first request, sends a cookie that includes a signature of all the files a server pushes: https://h2o.examp1e.net/configure/http2_directives.html#http2-casper https://h2o.examp1e.net/configure/http2_directives.html#http... If, on subsequent requests, the cookie is sent along with the request, H2O doesn't send those files. This is still a bit of a hack, and ultimately browsers will have to include some information on what's in the actual cache, with proposals on that pending: https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-digest/?include_text=1 https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-di...
Ajedi32 10y ago
As I understand it, the client has an opportunity to proactively cancel pushes of assets it already has cached. The server will send a "push promise" which basically says "I'm going to send this file to you", and then the client can come back and say "don't bother, I already have it". And this all happens in parallel with the download of other assets (like the main page), so it doesn't really slow anything down. Here's an article I read which goes into how server push works in a lot more detail: https://hpbn.co/http2/#server-push https://hpbn.co/http2/#server-push
- Clownshoesms 10y ago
  I had a bit of a look around after reading the article, this page might also be useful in explaining how it interacts with the cache and some suggestions on when to apply it: https://www.shimmercat.com/en/blog/articles/whats-push/#interaction-with-the-browser-s-cache https://www.shimmercat.com/en/blog/articles/whats-push/#inte... Sounds painful to me.
  - mozumder 10y ago
    To set it up isn't that hard... just set it and forget it, and let the browser & server handle things from there. In practice, it's going to be a lot faster than the default of not pushing resources.
- jimktrains2 10y ago
  Doesn't that require more round trips than just having the client ask for it?
  - jaffathecake 10y ago
    Yes. This makes push better for things that you'd otherwise inline. link[rel=preload] is generally good enough for other resources.
  - Ajedi32 10y ago
    No, even in the worst case it's exactly the same number of round trips. Without server push: 1. Client requests main page -> 2. Client receives main page <- 3. Client requests subresources -> 4. Client receives subresources <- With server push: 1. Client requests main page -> 2. Client receives push promises and main page <- 3. Client cancels promises it doesn't need -> 4. Client receives subresources <- The only difference is that with server push, steps 2, 3 and 4 happen in parallel, and step 3 can be omitted entirely in the event that the client doesn't need to cancel any pushes.
    - jimktrains2 10y ago
dullgiulio 10y ago
Basically yes. The client can cancel the streams for pushed assets that are in cache. But the server doesn't have this information (natively) when one page is requested. As others have said, there are workarounds using cookies. Which is yet another abuse of a very bad feature of HTTP.
- youngtaff 10y ago
  I'm not sure that any of the current browsers actually do this though
EGreg 10y ago
Push shouldn't be used for GETting things that you can cache. For that you can use pull with HTTP pipelining. Push should only be used for updates, including updating the cache. Ideally you'd only be sending the deltas (changes).
jimktrains2 10y ago
It's unspecified how the server should handle this. AFAIK, it's "one of the great unsolved problems" with HTTP2.
vfaronov 10y ago
There is ongoing work at the HTTP working group to standardize “cache digests” to solve this problem: https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest
dfabulich 10y ago
You are precisely correct; server push is not cache aware today. According to the spec, browsers have the ability to abort pushes that the server has started, so if you start sending down a 3MB file, your browser can send the server a request to stop sending it, because it's already in cache, but no browser actually does this today, and the first part of the file gets sent down regardless. There's a draft spec for browsers to use "Cache Digests," a compact representation of the content already in the cache. http://httpwg.org/http-extensions/cache-digest.html http://httpwg.org/http-extensions/cache-digest.html But no browsers support that today. Luckily, you can workaround/polyfill Cache Digests using Service Workers. Your Service Worker can provide the Cache Digest as a custom HTTP header on subsequent requests, and then the server can know to avoid re-pushing cached resources. Alternately, and more simply, if you configure your Service Worker to return/render stale content on first load, your Service Worker can make a request in the background to fetch the latest content, passing a simple header to the server to disable push. Since the stale content has already rendered, the round-trip time to download updated resources is less important. http://calendar.perfplanet.com/2016/cache-digests-http2-server-push/ http://calendar.perfplanet.com/2016/cache-digests-http2-serv...
- jbergstroem 10y ago
  Some web servers[1] additionally stores cache information in cookies. The same author that (co-)wrote your linked draft implemented it as a primer to the draft. If only CDN's supported it :-) [1]: https://h2o.examp1e.net/configure/http2_directives.html#http2-casper https://h2o.examp1e.net/configure/http2_directives.html#http...
- forgotpwtomain 10y ago
  > but no browser actually does this today, and the first part of the file gets sent down regardless. Are browsers really not doing this? My understanding was that just one round-trip was wasted for the client to send an RST_STREAM frame, or does it really re-download the entire pushed file where normally it would be a 304 on request?
  - dfabulich 10y ago

Clownshoesms 10y ago

I think it still obeys the browser's cache: "When the user navigates to a subsequent page that requires that asset, it can be pulled from the cache, eliminating the need for additional requests to the server." I'm not clear on if there is any relation to existing cache headers. I would have thought even the first page hit could have Link'ed assets pulled from the cache if present (if the client had previously visited that push-enabled resource (edit: in which case it's not the first I guess zzz). I guess the client, upon hitting a cached asset referenced in a Link header ignores it where otherwise it'd suck it down the socket as part of the same initial request.

mozumder 10y ago

The H2O server, on the first request, sends a cookie that includes a signature of all the files a server pushes: https://h2o.examp1e.net/configure/http2_directives.html#http2-casper https://h2o.examp1e.net/configure/http2_directives.html#http... If, on subsequent requests, the cookie is sent along with the request, H2O doesn't send those files. This is still a bit of a hack, and ultimately browsers will have to include some information on what's in the actual cache, with proposals on that pending: https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-digest/?include_text=1 https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-di...

Ajedi32 10y ago

As I understand it, the client has an opportunity to proactively cancel pushes of assets it already has cached. The server will send a "push promise" which basically says "I'm going to send this file to you", and then the client can come back and say "don't bother, I already have it". And this all happens in parallel with the download of other assets (like the main page), so it doesn't really slow anything down. Here's an article I read which goes into how server push works in a lot more detail: https://hpbn.co/http2/#server-push https://hpbn.co/http2/#server-push

Clownshoesms 10y ago
I had a bit of a look around after reading the article, this page might also be useful in explaining how it interacts with the cache and some suggestions on when to apply it: https://www.shimmercat.com/en/blog/articles/whats-push/#interaction-with-the-browser-s-cache https://www.shimmercat.com/en/blog/articles/whats-push/#inte... Sounds painful to me.
- mozumder 10y ago
  To set it up isn't that hard... just set it and forget it, and let the browser & server handle things from there. In practice, it's going to be a lot faster than the default of not pushing resources.
jimktrains2 10y ago
Doesn't that require more round trips than just having the client ask for it?
- jaffathecake 10y ago
  Yes. This makes push better for things that you'd otherwise inline. link[rel=preload] is generally good enough for other resources.
- Ajedi32 10y ago
  No, even in the worst case it's exactly the same number of round trips. Without server push: 1. Client requests main page -> 2. Client receives main page <- 3. Client requests subresources -> 4. Client receives subresources <- With server push: 1. Client requests main page -> 2. Client receives push promises and main page <- 3. Client cancels promises it doesn't need -> 4. Client receives subresources <- The only difference is that with server push, steps 2, 3 and 4 happen in parallel, and step 3 can be omitted entirely in the event that the client doesn't need to cancel any pushes.
  - jimktrains2 10y ago

dullgiulio 10y ago

Basically yes. The client can cancel the streams for pushed assets that are in cache. But the server doesn't have this information (natively) when one page is requested. As others have said, there are workarounds using cookies. Which is yet another abuse of a very bad feature of HTTP.

youngtaff 10y ago
I'm not sure that any of the current browsers actually do this though

EGreg 10y ago

Push shouldn't be used for GETting things that you can cache. For that you can use pull with HTTP pipelining. Push should only be used for updates, including updating the cache. Ideally you'd only be sending the deltas (changes).

jimktrains2 10y ago

It's unspecified how the server should handle this. AFAIK, it's "one of the great unsolved problems" with HTTP2.

vfaronov 10y ago

There is ongoing work at the HTTP working group to standardize “cache digests” to solve this problem: https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest

dfabulich 10y ago

You are precisely correct; server push is not cache aware today. According to the spec, browsers have the ability to abort pushes that the server has started, so if you start sending down a 3MB file, your browser can send the server a request to stop sending it, because it's already in cache, but no browser actually does this today, and the first part of the file gets sent down regardless. There's a draft spec for browsers to use "Cache Digests," a compact representation of the content already in the cache. http://httpwg.org/http-extensions/cache-digest.html http://httpwg.org/http-extensions/cache-digest.html But no browsers support that today. Luckily, you can workaround/polyfill Cache Digests using Service Workers. Your Service Worker can provide the Cache Digest as a custom HTTP header on subsequent requests, and then the server can know to avoid re-pushing cached resources. Alternately, and more simply, if you configure your Service Worker to return/render stale content on first load, your Service Worker can make a request in the background to fetch the latest content, passing a simple header to the server to disable push. Since the stale content has already rendered, the round-trip time to download updated resources is less important. http://calendar.perfplanet.com/2016/cache-digests-http2-server-push/ http://calendar.perfplanet.com/2016/cache-digests-http2-serv...

jbergstroem 10y ago
Some web servers[1] additionally stores cache information in cookies. The same author that (co-)wrote your linked draft implemented it as a primer to the draft. If only CDN's supported it :-) [1]: https://h2o.examp1e.net/configure/http2_directives.html#http2-casper https://h2o.examp1e.net/configure/http2_directives.html#http...
forgotpwtomain 10y ago
> but no browser actually does this today, and the first part of the file gets sent down regardless. Are browsers really not doing this? My understanding was that just one round-trip was wasted for the client to send an RST_STREAM frame, or does it really re-download the entire pushed file where normally it would be a 304 on request?
- dfabulich 10y ago