- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Fri, 20 Jul 2012 10:32:46 -0400
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Ross Nicoll <jrn@jrn.me.uk>, ietf-http-wg@w3.org
On Fri, Jul 20, 2012 at 8:51 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > In message <500952FE.1020402@jrn.me.uk>, Ross Nicoll writes: >>On 20/07/2012 13:35, Poul-Henning Kamp wrote: > >>> Ohh, that's the disconnect: It should _never_ share the session-id >>> with any other site, that's sort of the entire point. > >>We rather do want sites to share session IDs, actually, so we can do >>easy single-sign-on. > > I'm all for single-sign-on, but they need to use a different nonce > than the session-id I'm talking about. > > The session-id I'm talking about, are mainly for letting HTTP routers > chose the same server for the entire sessions, without having to > dig through cookies. I think it would be good to have just one of these and it could cut down on the number of cookies a browser needs to store/track. The REST argument seems to be a red herring to me. If people want to write stateless servers then fine, they can use a different technique. There have been statefull servers on the Web since 1993. That is why the POST method is written the way it is. The design goal was to separate out the idempotent methods from the rest. You can't do an application like Web Mail without loca state because a mailspool IS state. But it is quite easy for the session-ID to be used for routing without state at either end: Session-ID: Base64 ( HMAC-SHA2-256 ( host-domain, client-secret )) Client only needs to store the variable 'client secret' which is the same for all domains. The specification does not need to be tied to any crypto algorithm as it is just an opaque blob with at least 256 bits of randomness (the birthday attack is an issue here for a change). A router can then take as many bits as it needs to identify the 'bucket' to direct the response to and then map 'buckets' to back-end servers as required to meet need. An application can use the session-id as an index into whatever table it has to maintain per-connection state - which is why you would need a router in the first place. Having said that, this is not a total slam dunk for doing client side state as you might also want to achieve the same thing with a server pushed token being used in an authentication scheme. -- Website: http://hallambaker.com/
Received on Friday, 20 July 2012 14:33:16 UTC