W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: HTTP router point-of-view concerns

From: Mark Delany <s2y@romeo.emu.st>
Date: 13 Jul 2013 18:29:02 +0000
Message-ID: <20130713182902.69380.qmail@f5-external.bushwire.net>
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?

Received on Saturday, 13 July 2013 18:29:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC