- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 11 Feb 2013 16:07:10 +0000
- To: Nico Williams <nico@cryptonector.com>
- cc: Zhong Yu <zhong.j.yu@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=ISO-8859-1 -------- In message <CAK3OfOhGoQ0HtMu4HRo5kne1fgwDkzU6AHceCUTPHEXXW5HypQ@mail.gmail.com> , Nico Williams writes: >On Mon, Feb 11, 2013 at 1:20 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >> If somebody needs 8k of storage for each browser that visits their >> website, they can bloody well buy their own disks... > >It's a common implementation pattern. I'm not ready to tell >application implementors to stop doing this. > >It's not just the disk space, but also the need to fetch it and the >need to distribute it across related servers. Using the client to do >this has some benefits. ... for the server, yes. And a lot of disadvantages for the client, such as not having your context coming along to a different computer, privacy, bandwidth etc. I'm a big beliver in making disadvantages follow advantages, and therefore the servers should bear this cost. >(Also, a note about small session IDs: they can't be so small as to be >guessable. 32-bit session IDs would be a disaster. I think I'd not >feel comfortable with session IDs smaller than 96-bits.) Sure, 128 bits would be a minimum, 256 should be enough. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 11 February 2013 16:07:39 UTC