This is by design. The aim for HTTP/2 was always a new messaging scheme for HTTP/1.1 semantics. Basically, any HTTP/1.1 message can be converted to an HTTP/2 me

This is by design. The aim for HTTP/2 was always a new messaging scheme for HTTP/1.1 semantics. Basically, any HTTP/1.1 message can be converted to an HTTP/2 message (and this can be done by intermediaries); the only headers not expected to be supported in HTTP/2 are those that fall into the category of connection control (e.g., Connection). From the charter: > It is expected that HTTP/2.0 will: > * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields. > * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2). Quite probably a more radical, new version of HTTP, that drops message compatibility would be a good idea — but that's a lot harder to design and harder to deploy. As the old adage goes, "we believe in rough consensus and running code" — we have running code for a new message serialisation, and rough consensus for it. We should accept just that as done.