- From: Ludin, Stephen <sludin@akamai.com>
- Date: Fri, 12 Jul 2013 11:32:02 -0500
- To: Willy Tarreau <w@1wt.eu>, Poul-Henning Kamp <phk@phk.freebsd.dk>
- CC: Mark Nottingham <mnot@mnot.net>, Sam Pullara <spullara@gmail.com>, James M Snell <jasnell@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On 7/12/13 5:56 AM, "Willy Tarreau" <w@1wt.eu> wrote: >Hi Poul-Henning, > >On Fri, Jul 12, 2013 at 11:44:55AM +0000, Poul-Henning Kamp wrote: >> In message <CD9E163F-1225-4DA8-9982-8BDBD16B1051@mnot.net>, 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. +1. The distributed data store that the sea of user-agents compromises dwarfs anything we could engineer easily on the server (or proxy) side. Though I agree completely that there are numerous advantages to the idea of the user-agent holding only the session 'key' and the bulk of the data being on the server, the complexities of dealing with that in a distributed and massive origin/proxy environment are daunting and fear would erase much of the benefit that the distribution hopes to provide. I just implemented the header compression spec and it felt incredibly complex so I am definitely inclined to figure out a scheme for simplification. My concern is similar to Mike's: we will get buggy implementations out there that will cause us to to avoid its use in the long run. The beauty of the rest of the HTTP/2.0 spec is its simplicity of implementation. I like to think we can get there with header compression as well. > >Regards, >Willy > >
Received on Friday, 12 July 2013 16:32:36 UTC