I understand the issue of complexity in header compression but the impression I get is you seem to object to the whole basis of HTTP/2 seemingly because it's not ambitious enough.
If it didn't have HPACK but still did multiplexing would you still say abandon it?
It's a tradeoff: The added complexity must provide sufficient benefit to be worth it. HTTP/2.0 doesn't IMO, not even close.
> Also, cookies are wrong, because they store the servers state on the client computer, which led the EU to legislate against them.
Can you spell this out in more detail? (Maybe you've written an article about this at some point?)
When, if ever, is it OK to store state on the client? It seems like you'd at least make an exception for one session ID. I presume you'd also make exceptions for client-side caches? Anything else?
Do you advocate against all forms of client-side storage? IndexedDB, localStorage, Web SQL, etc?
RESTful advocates keep telling me not to store state on the server. Do you agree with that? If I can't store state on the server and I can't store it on the client, where am I supposed to store it?
The answer is that well-designed cookies are incompressible because they come out of cryptographic algorithms.
Also, cookies are wrong, because they store the servers state on the client computer, which led the EU to legislate against them.
Using information-free session nonces would have neither of these problems, and take up much less bandwidth.