- From: Mark Delany <s2y@romeo.emu.st>
- Date: 13 Jul 2013 18:29:02 +0000
- To: ietf-http-wg@w3.org
(Gack wrong sender address - you might see this twice). On 13Jul13, Sam Pullara allegedly wrote: > This can be (and in many cases is already) solved at any web company big enough to need to solve it. I'm 100% in favor of using a client generated session identifier. This would dramatically simplify HTTP/2 in a real way. Cookies are from another era when building a server-side scalable session data store was difficult and expensive. I would argue that isn't the case anymore. Just so I understand, does "solved" in this context means: a) Clients stop exchange cookies b) Clients start exchanging sessions ids (As we know, both of these can be achieved thru the cookie mechanism today by the server generating a session id cookie and dropping/expiring all other cookies). c) Assuming origins and other internal systems will still need to see a cookie flow for many years to come, participating edge systems will need to act as a persistent, consistent cookie cache/proxy on behalf of the clients. Client -> sessionid -> Edge --sessionid+Cookies--> origin | ^ | | Cookie Jar | | ^ | Client <- sessionid <- Edge <--New Cookies-- origin d) In a decade or two, when all internal systems grok session id, the edges can discard their cookie proxy implementations. The benefit being that you achieve perfect cookie compression on your external links without inventing a fancy compression system. The cost being that large/complicated sites will need to implement a persistent, consistent, distributed cookie store at their edges until they upgrade all internal systems. The argument being that the big guys get the most benefit, ergo they should bear the cost? Mark.
Received on Saturday, 13 July 2013 18:29:25 UTC