- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Fri, 20 Jul 2012 15:36:22 -0400
- To: James M Snell <jasnell@gmail.com>
- Cc: Roberto Peon <grmocg@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>, Philippe Mougin <pmougin@acm.org>
2012 is not 1992, quite a lot has changed since * Server state is now cheap, but it remains difficult to scale. If you have an service that will fit on one server then server side state is cheap and plentiful. I just built a new machine with 16GB on 2 DIMMS for $98. If I was building a server I would automatically fill it with 64GB just because I can. Server side state is no problem at all until you have a service that requires 64.00000001 Gb and then you are into a big problem. You can go up to 256Gb with 32 threads for about $10K. But you have to use registered memory which isn't even stocked at my favorite supplier. So the ability to use a router to front end the system and offload requests in a sensible fashion is a very big win here, it makes deployment of applications that are inherently statefull very much more practical. The lack of support in legacy browsers is not a major concern to me as I can simply consider all requests without the token to be one bucket of work and resign myself to having to one-off that particular site. * People use multiple browsers, state tends to be bound to account profiles. Not so long ago it was fairly unusual for someone to have more than one machine in daily use. Today it is absolutely routine. So that makes client selected state identifiers rather less useful than server side so that the server has control over where the requests are being directed. This is the reason that we want a session identifier rather than relying on the source IP address. * What is often required is a session authenticator rather than just an account identifier. It is a protocol design error to rely on confidentiality as a means of protecting authentication data sent over the wire. A password exchange scheme should establish knowledge of the password without disclosing the password. In general an authentication scheme should demonstrate knowledge of the authentication secret (preferably a cryptographic key) without revealing it. There are in fact two separate authentication concerns in HTTP: 1) How does the service determine that Alice is making the request on behalf of 'alice' at the start of a session? 2) How does the service re-authenticate subsequent requests in the same session (which may span multiple TCP/HTTP sessions). If the session ID is being used as a proxy for authentication, I would prefer to do the job right.
Received on Friday, 20 July 2012 19:36:49 UTC