As long as there is someway for users to keep themselves logged into a site, sounds good to me. Sam ---Sent from Boxer | http://getboxer.com On Sat, Jul 13, 2013 at 11:40:19PM +0100, Stephen Farrell wrote: > > Its a bit of a moot point I guess but... > > On 07/13/2013 09:24 PM, Yoav Nir wrote: > > allow it to persist for as long as you want > > I've always been amused that HTTP needs to be able to > manage state for decades. It'd be truly impressive if > a browser really managed state that lasts far longer > than the h/w on either side and probably also longer > than any piece of n/w kit in between. > > If HTTP/2.0 were to impose an upper bound on cookie > lifetime of say, a session, that'd be good IMO. But I > guess that probably would be out of charter, even if > it'd be a good thing, as it'd break stuff. OTOH, it'd > arguably be a good thing to leave such stuff behind when > moving to HTTP/2.0. I think that *session* cookies are needed, but *permanent* cookies are mostly used by ads and user tracking, even if a few sites use them to store user preferences. One elegant solution would probably be to systematically have UAs ask end users whenever a cookie is sent to be stored for more than (say) 24h. Site designers will take care of this because they don't want to make their site emit warnings that upset end users. And if the cookie is used to store preferences, it is normal that the user gives the permission to do that. Also, we should probably recommend that UAs automatically expire session cookies after some time (maybe the same delay limit that is used before emitting a warning). I've dealt with issues where some smartphone browsers never close and never delete session cookies, causing the same browser to always go to the same server past the load balancer. In the end, I had the LB detect those cookies to fix them! Regards, Willy
Received on Sunday, 14 July 2013 06:22:43 UTC