The second HTTP Workshop just ended this week. About 40 people converged on Stockholm to discuss all things HTTP. Presentations, opinions, experience exchange and talks a plenty. There are several good posts summarizing it:
What can I bring additinally to the table? A little bit from Apache side, maybe. But remember that all this here is my personal point of view!
The state of HTTP/2 Push was discussed from different angles. Cloudflare and Akamai stated experiences and measurements, Kazuho (h2o) presented his cache digests. Ilya, Yoav argued differences and synergies between preload and push. Patrick (Mozilla) wondered if it is all worth the complexity.
The consensus I took from all of this is that push can be very beneficial, but it is hard to get right. And it can also hurt a lot. Certainly just pushing all static resources at the client, all the time, is not the way to go.
In Apache we do support pushes and the experimental cache digest for some time now, but there is lots
of room for improvement. For example, we take the
Link headers with
use those for pushing. But that means that the response header must first be calculated and until that
the connection will idle. Bandwidth wasted.
Expect lots of fiddling and fine tuning in this area in the months to come.
Cory Benfield and Brad Fitzpatrick prototyped a way to expose HTTP/2 state information to the client. The idea here is that clients interop problems offen arrive because of misatches in state (with flow control being the top number one). So given the client this information from the server's point of view will help to sort out misunderstandings.
The information will be exposed on the path
/.well-known/h2/state and it will only show
information about the current connection. That should make it safe. And since HTTP/2 allows many requests
on a connection, clients can ask for it almost all the time. Nice!
The two did sample implementations in their servers on day three. Apache has it now in trunk; expect it to be available in a github mod_h2 release soon!
During our discussion of the feature, we considered possibilities for the server to interrogate the client for its state, too. This is still considerably difficult, even in HTTP/2, as there are no server-initiated requests really. Maybe it's all for the better that way. In the end, we decided we did not really need it, if clients make it available (preferably side-by-side) to the user.
The Big One. The monster change. With nice features. But look at the size of that thing!
To summarize what it does in one sentence: it takes all things that are nicely hidden in your kernels about TCP, mixes them with a new TLS, ciphers and certificates and, with the little finger of its left hand, knocks over some assumptions in your HTTP(/2) stacks. It's like mashed potatoes in a stew mixed to a smoothie.
And it tastes really good!
One of the really nice things it does is the following: you get a connection from your client to a server without tying it to IP addresses. This means you open a SSH session to a server, leave the house and go cellular, then enter a cafe WLAN before biking to your office and plug the 1 gig ethernet in, and your SSH is still alive and kicking. Or your download/upload continues (as you might have paused that on cellular automatically).
But it's sooo complex to do all that right. And the Operating Systesm will not do it soonish (and bring a TLS library into kernel space). So, the connection management is in user space. Which means, when you want to handle a port in different processes, you need to route yourself (at least to my limited understanding). And, and, and.
So, do not expect that in Apache anytime soon, if at all. HTTP/1+2 will be there and keep you safe and warm for the near and mid-term future. But, one day, maybe? Will be interesting...
Enjoy Apache. And the sun outside.
Stefan Eissing, greenbytes GmbH
Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without warranty of any kind. See LICENSE for details.