Re: HTTP router point-of-view concerns

[Sam Pullara <[e-mail]>]

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.

Sam

On Jul 12, 2013, at 5:56 AM, Willy Tarreau <[e-mail]> wrote:

> Hi Poul-Henning,
> 
> On Fri, Jul 12, 2013 at 11:44:55AM +0000, Poul-Henning Kamp wrote:
>> In message <[e-mail]>, Mark Nottingham wri
>> tes:
>> 
>>> This has been brought up a number of times. I think what we need is a =
>>> concrete proposal *with* a detailed plan for a workable transition to =
>>> the new mechanism -- which seems to be the (or at least one) sticking =
>>> point whenever this comes up.
>> 
>> I have given a concrete example multiple times, it's very simple:
>> 
>> 	The client always sends along a session-identifier of N (128?)
>> 	bits.
>> 
>> 	If the first bit is zero, this is an anonymous, transient
>> 	session, not (to be) associated with any other session.
>> 
>> 	If the first bit is one, this is a persistent session
>> 	identifier, which the server can use to look up any relevant
>> 	state or information from previous instances of this
>> 	session, in its local database.
>> 
>> 	This replaces the Cookie: and Set-Cookie: headers, which
>> 	SHALL NOT be sent in the HTTP/2.0 protocol.
>> 
>> Advantages:
>> 
>> 	We get a fixed size session-identifier for HTTP routers to
>> 	use for flow-routing.
>> 
>> 	We get an actual (client controlled) session-concept, rather
>> 	than all sorts of ad-hoc simulations with cookies.
>> 
>> 	Data with privacy-concerns are stored on the server not on
>> 	random clients the user happens to borrow or use.
>> 
>> 	The overhead of encrypting and signing the data in cookies
>> 	is avoided, since they are stored on the server side where
>> 	nobody can fudge them.
>> 
>> Backwards compatibility:
>> 
>> 	It should be obvious that simulating the Cookie concept for
>> 	framework compatibility on the server side is a trivial
>> 	matter of programming:  Rather than send set-cookies, write
>> 	them to a database, indexed by the session-id.  Rather than
>> 	receive Cookie: headers, look them up in the database.
>> 
>> There, solved.
> 
> Not really in fact. While I tend to generally agree with the points
> you make for scalability, this one does not scale. One of the big
> benefits of cookies is that client is responsible for synchronizing
> information between multiple servers *if needed*. When you're building
> an architecture using anycast DNS + ECMP + L4 load balancers to reach
> your servers, you can't predict if a client will come back to the same
> place to retrieve its context, and having the ability to make it hold
> *some* data is really useful.
> 
> If you store everything on server-side, you're forced to synchronize
> everything between all servers of all datacenters because you don't
> even know where your client will go with next hit, let alone parallel
> requests. And this is clearly not possible on many of the platforms
> where both of our products are deployed to achieve connection rates
> in the 6 digits.
> 
> So there *is* some use to store data on the client, it's just that it
> has been long abused to store session identifiers because it was the
> only mechanism available.
> 
> While I'd like to see a simple session management system (like the one
> you propose maybe, even if it does not cover the case of low entropy
> client devices), I don't want to see the cookies disappear. I just want
> to be able to rely on session ID without having to parse cookies when
> that's not needed.
> 
> Regards,
> Willy
>