8 ms·

Apache 2.4.17 with HTTP/2 support

203 points by signaler 11y ago

skrause 11y ago
No mention of server push, so I assume it's not supported?
- deleted 11y ago
  [deleted]
- dtech 11y ago
  Reading the page it seems like it is still in quite an early state, I expect they have higher priorities.
- tootie 11y ago
  How would server push from a web server work?
  - Tobani 11y ago
    If the server can parse served html, it could preemptively also send along other required assets (css, images, etc) before the client has time to parse and request them. This would help remove necessity for optimizations like image bundling.
  - acdha 11y ago
    The simplest way would seem to be a directive to push static resources: <Location /> ServerPush /static/css/main.css ServerPush /static/js/main.js </Location> <LocationMatch "^/$"> ServerPush /static/img/gigantic-homepage-image.jpg </LocationMatch> <Location /maps/> ServerPush /static/js/leaflet.js </Location> I believe this could even avoid the need to include cache-busters in the URL since you could push with an ETag and the client can terminate if it already has the appropriate bytes without the incredible performance hit of using ETags with HTTP 1.
    - thethimble 11y ago
      I think this is unsustainable (any non-trivial change to your html resources would require updating and restarting httpd). This is not DRY. Jetty's approach to this problem is really interesting. Using HTTP referrer headers, it builds up a tree of resources that are often fetched together. Then, it optimistically pushes companion resources down. https://github.com/eclipse/jetty.project/blob/master/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/PushCacheFilter.java#L59 https://github.com/eclipse/jetty.project/blob/master/jetty-s...
      - acdha 11y ago
        You'll note that I said “simplest” – this could work on a $2/month shared hosting plan (not sure where you got the “updating and restarting httpd” bit from with a couple decades of prior art showing otherwise). The Jetty approach is clever, too, as would be things like scanning rel=prefetch links but simple declarative approaches have their moments, too. One thing the Jetty approach doesn't appear to offer is the ability to manage resources if not all resources are appropriate for every client so it would appear to do things like ship every size of a responsive image to every client.
  - pquerna 11y ago
    Other comments are are good starts. Another method would be to add a headers to the response: Server-Push: /relative/url Then have an output filter pull them out and push them -- but AFAIK the APIs to do that don't yet exist in mod_h2 to push like that. Adding headers in the response is nice because it works with any 'backend', and the web server doesn't have to parse the HTML/css/etc going the through it.
    - spankalee 11y ago
      This how it's done in mod_spdy[1] and App Engine[2], with the X-Associated-Content header. [1]: https://code.google.com/p/mod-spdy/wiki/OptimizingForSpdy#Using_SPDY_server_push https://code.google.com/p/mod-spdy/wiki/OptimizingForSpdy#Us... [2]: https://github.com/GoogleChrome/http2push-gae https://github.com/GoogleChrome/http2push-gae
- mholt 11y ago
  Here's a blog post I wrote about why this probably isn't implemented in most servers yet: https://caddyserver.com/blog/implementing-http2-isnt-trivial https://caddyserver.com/blog/implementing-http2-isnt-trivial
  - spankalee 11y ago
    There a few claims you have that I think are slightly off. First, push is very different than inlining, because individual resources are cacheable by the client, and inlined resources are not. There's a little handshake at the start of a push and if the client has (or doesn't otherwise want) the resource, it can cancel the push. In my team's experiments with using push for HTML Imports, push ends up being better than inlining (using Polymer's vulcanize tool), even with a cold cache. Also, push is relatively easy to implement if you use the response header approach, and was availably early on in mod_spdy.
- deleted 11y ago
  [deleted]
vpkaihla 11y ago
They added a significant new protocol in a minor upgrade. Is that right?
- itsbits 11y ago
  not defaulted as http2 though.
- chrisseaton 11y ago
  If all it does is add new functionality, and doesn't modify or break any existing functionality, then that seems to be good software engineering to do in a minor upgrade doesn't it?
  - dtech 11y ago
    If you follow semantic versioning, the third number should only be used for bugfixes. They don't.
- dtech 11y ago
  Apache version numbering is similar to what the linux kernel used before 2.6. In a.b.c, odd b indicates the unstable or experimental branch, and even b's are used for major and backwards-compatibility breaking changes. Backwards-compatibility preserving changed can be introduced in c. So 2.2 and 2.4 are pretty different versions, while 2.3 and 2.4 are closer except 2.3 is unstable. 2.4.0 is theoretically compatible with 2.4.17, except the latter has a lot more functionality and features.
- dspillett 11y ago
  Seems valid: MAJOR.MINOR.PATCH, with the minimum changes being increment "patch" for backwards compatible bug fixes, "minor" for new/improved functionality that does not break backwards compatibility, and "major" for any API/feature change that is not backwards compatible. They could of course chosen to increment MAJOR instead, but they don't have to in this case. (I'm assuming they are following "standard" semver rules here)
  - 11y ago
Tepix 11y ago
That's great news! I look forward to test this. I saw that the Ubuntu apache ppa at https://launchpad.net/~ondrej/+archive/ubuntu/apache2 https://launchpad.net/~ondrej/+archive/ubuntu/apache2 already has packages for this version (not tested by me). What's sad is that this is yet another github page with #777 colored text on white background. The resulting contrast is too low to read comfortably!

203 points by signaler 11y ago

skrause 11y ago

No mention of server push, so I assume it's not supported?

deleted 11y ago
[deleted]
dtech 11y ago
Reading the page it seems like it is still in quite an early state, I expect they have higher priorities.
tootie 11y ago
How would server push from a web server work?
- Tobani 11y ago
  If the server can parse served html, it could preemptively also send along other required assets (css, images, etc) before the client has time to parse and request them. This would help remove necessity for optimizations like image bundling.
- acdha 11y ago
  The simplest way would seem to be a directive to push static resources: <Location /> ServerPush /static/css/main.css ServerPush /static/js/main.js </Location> <LocationMatch "^/$"> ServerPush /static/img/gigantic-homepage-image.jpg </LocationMatch> <Location /maps/> ServerPush /static/js/leaflet.js </Location> I believe this could even avoid the need to include cache-busters in the URL since you could push with an ETag and the client can terminate if it already has the appropriate bytes without the incredible performance hit of using ETags with HTTP 1.
  - thethimble 11y ago
    I think this is unsustainable (any non-trivial change to your html resources would require updating and restarting httpd). This is not DRY. Jetty's approach to this problem is really interesting. Using HTTP referrer headers, it builds up a tree of resources that are often fetched together. Then, it optimistically pushes companion resources down. https://github.com/eclipse/jetty.project/blob/master/jetty-servlets/src/main/java/org/eclipse/jetty/servlets/PushCacheFilter.java#L59 https://github.com/eclipse/jetty.project/blob/master/jetty-s...
    - acdha 11y ago
      You'll note that I said “simplest” – this could work on a $2/month shared hosting plan (not sure where you got the “updating and restarting httpd” bit from with a couple decades of prior art showing otherwise). The Jetty approach is clever, too, as would be things like scanning rel=prefetch links but simple declarative approaches have their moments, too. One thing the Jetty approach doesn't appear to offer is the ability to manage resources if not all resources are appropriate for every client so it would appear to do things like ship every size of a responsive image to every client.
- pquerna 11y ago
  Other comments are are good starts. Another method would be to add a headers to the response: Server-Push: /relative/url Then have an output filter pull them out and push them -- but AFAIK the APIs to do that don't yet exist in mod_h2 to push like that. Adding headers in the response is nice because it works with any 'backend', and the web server doesn't have to parse the HTML/css/etc going the through it.
  - spankalee 11y ago
    This how it's done in mod_spdy[1] and App Engine[2], with the X-Associated-Content header. [1]: https://code.google.com/p/mod-spdy/wiki/OptimizingForSpdy#Using_SPDY_server_push https://code.google.com/p/mod-spdy/wiki/OptimizingForSpdy#Us... [2]: https://github.com/GoogleChrome/http2push-gae https://github.com/GoogleChrome/http2push-gae
mholt 11y ago
Here's a blog post I wrote about why this probably isn't implemented in most servers yet: https://caddyserver.com/blog/implementing-http2-isnt-trivial https://caddyserver.com/blog/implementing-http2-isnt-trivial
- spankalee 11y ago
  There a few claims you have that I think are slightly off. First, push is very different than inlining, because individual resources are cacheable by the client, and inlined resources are not. There's a little handshake at the start of a push and if the client has (or doesn't otherwise want) the resource, it can cancel the push. In my team's experiments with using push for HTML Imports, push ends up being better than inlining (using Polymer's vulcanize tool), even with a cold cache. Also, push is relatively easy to implement if you use the response header approach, and was availably early on in mod_spdy.
deleted 11y ago
[deleted]

vpkaihla 11y ago

They added a significant new protocol in a minor upgrade. Is that right?

itsbits 11y ago
not defaulted as http2 though.
chrisseaton 11y ago
If all it does is add new functionality, and doesn't modify or break any existing functionality, then that seems to be good software engineering to do in a minor upgrade doesn't it?
- dtech 11y ago
  If you follow semantic versioning, the third number should only be used for bugfixes. They don't.
dtech 11y ago
Apache version numbering is similar to what the linux kernel used before 2.6. In a.b.c, odd b indicates the unstable or experimental branch, and even b's are used for major and backwards-compatibility breaking changes. Backwards-compatibility preserving changed can be introduced in c. So 2.2 and 2.4 are pretty different versions, while 2.3 and 2.4 are closer except 2.3 is unstable. 2.4.0 is theoretically compatible with 2.4.17, except the latter has a lot more functionality and features.
dspillett 11y ago
Seems valid: MAJOR.MINOR.PATCH, with the minimum changes being increment "patch" for backwards compatible bug fixes, "minor" for new/improved functionality that does not break backwards compatibility, and "major" for any API/feature change that is not backwards compatible. They could of course chosen to increment MAJOR instead, but they don't have to in this case. (I'm assuming they are following "standard" semver rules here)
- 11y ago

Tepix 11y ago

That's great news! I look forward to test this. I saw that the Ubuntu apache ppa at https://launchpad.net/~ondrej/+archive/ubuntu/apache2 https://launchpad.net/~ondrej/+archive/ubuntu/apache2 already has packages for this version (not tested by me). What's sad is that this is yet another github page with #777 colored text on white background. The resulting contrast is too low to read comfortably!