News for hackers. Stuff that matters.

A comment on HTTP/2.0 – Please admit defeat. Parent comment

Re:HTTP/2.0 – Please admit defeat by youngtaff on Monday May 26, 2014 @01:55PM (#7800767)
> If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on.

Yes, they add request and response overhead but what evidence is there that removing them would deliver greater performance improvements than a multiplexed protocol does?

[ Parent | on HN ]
Re:HTTP/2.0 – Please admit defeat by phkamp on Monday May 26, 2014 @03:16PM (#7801092)
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.

[ Parent | on HN ]
Re:HTTP/2.0 – Please admit defeat by youngtaff on Monday May 26, 2014 @04:07PM (#7801353)
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?

[ Parent | on HN ]
Re:HTTP/2.0 – Please admit defeat by phkamp on Monday May 26, 2014 @06:36PM (#7801966)
It's a tradeoff: The added complexity must provide sufficient benefit to be worth it. HTTP/2.0 doesn't IMO, not even close.
[ Parent | on HN ]
Re:HTTP/2.0 – Please admit defeat by dfabulich on Monday May 26, 2014 @07:23PM (#7802121)
> 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?

[ Parent | on HN ]