4 ms·

HTTP/2 Server Push and ASP.NET MVC – Cache Digest

31 points by PretzelFisch 10y ago

jbergstroem 10y ago
Another (actually, the first) implementation of "http2-casper" (referenced in the article) can be found in h2o [https://github.com/h2o/h2o https://github.com/h2o/h2o]: https://h2o.examp1e.net/configure/http2_directives.html#http2-casper https://h2o.examp1e.net/configure/http2_directives.html#http... The main author – Kazuho Oku – is to me a http2 wizard (and just now joined Fastly). You can read his thoughts on the matter: https://github.com/h2o/h2o/issues/421 https://github.com/h2o/h2o/issues/421
artursapek 10y ago
I've started reading more about HTTP/2 recently because I removed nginx from a project I work on and exposed a bare Golang webserver (which nicely comes with HTTP/2). As far as I understand, HTTP server push is only beneficial if you serve assets from the same machine as the initial HTML page. If you have them on a CDN like CloudFront you can't really get any benefit from push. Is this incorrect?
- sudhirj 10y ago
  Probably incorrect - the HTTP/2 push specification is a way for a server to send files the client along with the original request - it makes no mandates about where the files must be sourced from. It doesn't even say the data needs to be static. Cloudflare already supports push - you set a special header, and the CF proxy will GET the URLs you specify and bundle them along with the original request. No technical Cloudfront or any other CDN can't do this as well.
  - jbergstroem 10y ago
    The point here is to re-use the already open http2 connection; so I'd argue that you should strive for same-domain transport.
    - artursapek 10y ago
      That's what I meant - if the HTML page (which knows which assets it will require) is not being served from the same machine as the assets will be, you cannot take advantage of HTTP/2 push.
      - jbergstroem 10y ago
        Well, you can still utilize it. For instance, if you serve `/static.css` from your CDN; you would (should) also add `Link` headers to all same-domain assets tied to it.
    - sudhirj 10y ago
      I think same-domain is enforced - because it's sending data down the same connection (a different domain would need a different connection). The point is that it doesn't matter where the proxy server gets the data from, if the proxy is handline HTTP/2 termination.
- viggity 10y ago
  it reads like you're implying that nginx doesn't have http2 capabilities (perhaps you're not, if so, I'm sorry). But you can use http2 with nginx - "listen 443 ssl http2;". You just need nginx 1.9 or above.
ebidel 10y ago
Also relevant: "Cache-Aware Server Push (Client Side)" https://docs.google.com/document/d/1HhmyzKUPuWcCs8wG_GLSu3mvptygXtO2mBl5xlmEB-4/edit# https://docs.google.com/document/d/1HhmyzKUPuWcCs8wG_GLSu3mv... The Chrome team is hashing out potential solutions to the server push <-> browser cache problem.

31 points by PretzelFisch 10y ago

Another (actually, the first) implementation of "http2-casper" (referenced in the article) can be found in h2o [https://github.com/h2o/h2o https://github.com/h2o/h2o]: https://h2o.examp1e.net/configure/http2_directives.html#http2-casper https://h2o.examp1e.net/configure/http2_directives.html#http... The main author – Kazuho Oku – is to me a http2 wizard (and just now joined Fastly). You can read his thoughts on the matter: https://github.com/h2o/h2o/issues/421 https://github.com/h2o/h2o/issues/421

artursapek 10y ago

I've started reading more about HTTP/2 recently because I removed nginx from a project I work on and exposed a bare Golang webserver (which nicely comes with HTTP/2). As far as I understand, HTTP server push is only beneficial if you serve assets from the same machine as the initial HTML page. If you have them on a CDN like CloudFront you can't really get any benefit from push. Is this incorrect?

sudhirj 10y ago
Probably incorrect - the HTTP/2 push specification is a way for a server to send files the client along with the original request - it makes no mandates about where the files must be sourced from. It doesn't even say the data needs to be static. Cloudflare already supports push - you set a special header, and the CF proxy will GET the URLs you specify and bundle them along with the original request. No technical Cloudfront or any other CDN can't do this as well.
- jbergstroem 10y ago
  The point here is to re-use the already open http2 connection; so I'd argue that you should strive for same-domain transport.
  - artursapek 10y ago
    That's what I meant - if the HTML page (which knows which assets it will require) is not being served from the same machine as the assets will be, you cannot take advantage of HTTP/2 push.
    - jbergstroem 10y ago
      Well, you can still utilize it. For instance, if you serve `/static.css` from your CDN; you would (should) also add `Link` headers to all same-domain assets tied to it.
  - sudhirj 10y ago
    I think same-domain is enforced - because it's sending data down the same connection (a different domain would need a different connection). The point is that it doesn't matter where the proxy server gets the data from, if the proxy is handline HTTP/2 termination.
viggity 10y ago
it reads like you're implying that nginx doesn't have http2 capabilities (perhaps you're not, if so, I'm sorry). But you can use http2 with nginx - "listen 443 ssl http2;". You just need nginx 1.9 or above.

ebidel 10y ago

Also relevant: "Cache-Aware Server Push (Client Side)" https://docs.google.com/document/d/1HhmyzKUPuWcCs8wG_GLSu3mvptygXtO2mBl5xlmEB-4/edit# https://docs.google.com/document/d/1HhmyzKUPuWcCs8wG_GLSu3mv... The Chrome team is hashing out potential solutions to the server push <-> browser cache problem.