[daphreak]

While I look forward to a faster desktop and mobile browsing experience with HTTP/2 I do worry about the complexity. I hope that the simpler protocols remain supported for a long time to enable implementations on low resource embedded systems.

The last thing we need is for all the closed-source, internet-connected, black boxes in our lives to poorly implement a complicated web standard protocol. There are so many places where we have already seen vulnerabilities with implementations of simple web severs and clients.

[MichaelGG]

What looks particularly complex about HTTP/2?

The "simple" text based protocols are NOT simple to implement correctly. Go try out line-wrapping and play with using \r\n vs \r vs \n as line endings and tell me what the compatibility ends up like.

And this does create real-world security problems. Some VoIP companies allow you to make free calls by screwing with their SIP proxies because popular software handles line endings differently allowing you to make their edge software interpret packets differently than their core.

Even parsing is easier in a nice binary format (and much, much, faster, too).

[ris]

It's not got much to do with the serialization protocol itself as such - most server software uses a library which handles it properly and then doesn't have to worry about it. It's more that web developers have to get bits of their stack (the dynamic and static serving aspects) to cooperate in ways they never had to before (in fact, the general wisdom was to separate them as much as possible as they have totally different requirements when it comes to performant serving).

This is not even to get into persistent connections & server push etc., which is quite a big subject for developers used to handling independent fire-and-forget requests.

I guess I'm saying the massively complexity comes in trying to use these new features.