Also... nothing stops a site from implementing something like what Nico described today with what already exists in HTTP, though the logic would be encoded in the server business logic and page javascript instead of done automatically by browser and server. -=R On Sun, Feb 10, 2013 at 11:20 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: > Content-Type: text/plain; charset=ISO-8859-1 > -------- > In message <CAK3OfOieNOsN7= > 2TV_25nTr+7Y3a-fyjSGV+F7HdbEQT8cB9xg@mail.gmail.com> > , Nico Williams writes: > > I really don't see why it should be the clients problem to store > the servers state. > > If somebody needs 8k of storage for each browser that visits their > website, they can bloody well buy their own disks... > > Poul-Henning > > > >... sounds like an oxymoron. > > > >HOWEVER, we can probably use a combination of server-side state stored > >[encrypted] in state cookies, small session identifiers, and > >server-side caching of state cookies. Clients would normally only > >send the [small] session IDs, and would send the cookies only when the > >server needs them to [re-]establish state after it falls off the > >server's cache. > > > >On Sun, Feb 10, 2013 at 6:15 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> > wrote: > >> [1] We can probably do much more for transmission efficiency by killing > >> cookies and adding client provided session-identifieres, than any > >> kind of encoding or compression will ever be able to...[2] > > > > -- > 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 07:39:16 UTC