Hacker News Reader

Comment by artursapek | Hacker News Reader

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?

View on HN

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.

The point here is to re-use the already open http2 connection; so I'd argue that you should strive for same-domain transport.

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.

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.

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.

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.

Reply on news.ycombinator.com