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

Re: HTTP router point-of-view concerns

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 12 Jul 2013 22:00:49 +0200
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Message-ID: <20130712200049.GD32054@1wt.eu>
On Sat, Jul 13, 2013 at 05:29:59AM +1200, Amos Jeffries wrote:
> In these cases you build your session identifier to contain a shard 
> reference as well as an UID.
> For example I'm pretty sure that Facebook does not replicate all users 
> entire account details onto each and every server, or in a Cookie being 
> sent back and forward. For good reason. No, they have an ID which allows 
> extremely fast backend referencing for whatever assembly server is 
> running to access whatever data server the users account it stored on. 
> Not exactly complex even when running at large scale.
> >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.
> Only the Session ID and/or a shard reference (combined in one opaque 
> blob is even better) need be stored on the client.

A shard reference or session ID are two completely different things. A
session ID comes from one referential. A shard reference indicates what
referential to use. That's why a user-provided session ID cannot be used
as a shard reference and prevents from scaling. I *do* use cookies exactly
as you describe because it's the only way to scale, and have been doing so
for almost a decade now. In a cookie, you can indicate the DC, the server,
a location in a database, etc... Whatever you need to perform very fast
access. You simply can't do that by learning massive amounts of randoms
generated by clients.

Received on Friday, 12 July 2013 20:02:59 UTC

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