31–40 of 66 posts
I've recently spent more time using H2O over nginx, mainly because of its more complete support of HTTP 2 (push, cache-aware push, ..) but also out of the box support for brotli compression and mruby (think lua landscape for nginx). Even though nginx made it easier to build and ship third party modules separately, I feel like the module community (as well as distro maintainers/packagers) haven't followed suit. There'…
Are there any good general guidelines on when you should use HTTP2 push? Edit: Oops, I missed out "push" at the end.
This is specific to H2 Push
Please correct me if I'm wrong in anything I say here. I haven't had any real-world deployment experiences with HTTP 2.0. Every time I've tried looking into it, I've found it underwhelming. Infrastructure support and tooling is still heavily lacking as far as I can tell. To really take advantage of server push it seems like you'd need to have really good build tools available. Don't you risk sending useless data with…
I've recently spent more time using H2O over nginx, mainly because of its more complete support of HTTP 2 (push, cache-aware push, ..) but also out of the box support for brotli compression and mruby (think lua landscape for nginx). Even though nginx made it easier to build and ship third party modules separately, I feel like the module community (as well as distro maintainers/packagers) haven't followed suit. There'…
Please correct me if I'm wrong in anything I say here. I haven't had any real-world deployment experiences with HTTP 2.0. Every time I've tried looking into it, I've found it underwhelming. Infrastructure support and tooling is still heavily lacking as far as I can tell. To really take advantage of server push it seems like you'd need to have really good build tools available. Don't you risk sending useless data with…
I think (not sure if this has been agreed as best practice) that you can use cookies to decide which content to push. This should work in most cases - set a cookie that lasts as long as your users' cache, and don't do server push if that cookie exists.
Are there any good general guidelines on when you should use HTTP2 push? Edit: Oops, I missed out "push" at the end.
You might want to read https://jakearchibald.com/2017/h2-push-tougher-than-i-though... This is specific to H2 Push
Please correct me if I'm wrong in anything I say here. I haven't had any real-world deployment experiences with HTTP 2.0. Every time I've tried looking into it, I've found it underwhelming. Infrastructure support and tooling is still heavily lacking as far as I can tell. To really take advantage of server push it seems like you'd need to have really good build tools available. Don't you risk sending useless data with…
For example, say you had a chart on your page that is generated with JavaScript. That JavaScript makes an API call to get data. You can go ahead and push this data when the page is requested. Since it's (usually) dynamic you don't have to worry about caching nearly as much.
This type of thing is extremely common, but when it comes to H2 everyone is focused on the hardest thing.
Are there any good general guidelines on when you should use HTTP2 push? Edit: Oops, I missed out "push" at the end.
I would suggest using HTTP/2 whenever possible. Features like connection multiplexing and pipelining alone are huge benefits.
Please correct me if I'm wrong in anything I say here. I haven't had any real-world deployment experiences with HTTP 2.0. Every time I've tried looking into it, I've found it underwhelming. Infrastructure support and tooling is still heavily lacking as far as I can tell. To really take advantage of server push it seems like you'd need to have really good build tools available. Don't you risk sending useless data with…
I think, but could be completely wrong, that browsers can reject a pushed resource at the start. Since the "connection" cost for each resource is minimal, this wouldn't be too much of a problem. Someone confirm or deny this.