This is the major knock on HTTP2. It's entirely focused on hacking around transport layer issues while keeping TCP intact and has shied away from fixing real and serious problems with the HTTP protocol itself. Here's a quote from the HTTP2 FAQ: ( https://http2.github.io/faq/#can-http2-make-cookies-or-other... )
"In particular, we want to be able to translate from HTTP/1 to HTTP/2 and back with no loss of information. If we started “cleaning up” the headers (and most will agree that HTTP headers are pretty messy), we’d have interoperability problems with much of the existing Web."
Pretty disappointing really. It took 15 years of haggling and we ended up with precisely the old protocol but now in a new, improved binary format with multiplexing.
> Pretty disappointing really. It took 15 years of haggling and we ended up with precisely the old protocol but now in a new, improved binary format with multiplexing.
Yeah, we can have a perfect reimplementation of the widely used protocol to fix all of the problems at once. Just look at how successful IPv6 has been.
IPv6 is doing fine. I have IPv6 at home, and natively on all of my servers. According to my Openwrt AP stats, about 47% of all my household inbound traffic receiving is via IPv6 (over 8 days of basically just web browsing).
IPv6 doesn't fix most of the problems with IP, in fact it makes some worse (routing tables are now bigger because of bigger addresses and there can be more of them). If IPv6 actually did attempt to fix issues in IP it might have seen faster adoption.
"In particular, we want to be able to translate from HTTP/1 to HTTP/2 and back with no loss of information. If we started “cleaning up” the headers (and most will agree that HTTP headers are pretty messy), we’d have interoperability problems with much of the existing Web."
Pretty disappointing really. It took 15 years of haggling and we ended up with precisely the old protocol but now in a new, improved binary format with multiplexing.