3 ms·
Comparing to multiplexing is wrong. You should compare it to the header-compression ("HPACK") which is a major complication and risk in HTTP/2.0 The answer is
by phkamp 12y ago
Comparing to multiplexing is wrong. You should compare it to the header-compression ("HPACK") which is a major complication and risk in HTTP/2.0
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.
- youngtaff 12y agoI 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?
- phkamp 12y agoIt's a tradeoff: The added complexity must provide sufficient benefit to be worth it. HTTP/2.0 doesn't IMO, not even close.
- dfabulich 12y ago> 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?