- From: Ross Nicoll <jrn@jrn.me.uk>
- Date: Fri, 20 Jul 2012 16:16:20 +0100
- To: Paul Frazee <pfrazee@gmail.com>
- CC: ietf-http-wg@w3.org
If session management is going to use headers, surely it needs to be defined in the protocol, irrespective of whether the user agent or client-side Javascript writes those headers. Beyond that, I don't think we can assume user agents will support Javascript or any other sort of scripting, and I fear that single pages that re-write themselves are likely to be a nightmare in terms of accessibility (for example for blind users). Certainly I'd much rather define sessions in a way that the user agent can manage, and therefore can present options (such as logout) in a way that makes sense given their user interface. On 20/07/2012 15:39, Paul Frazee wrote: > On the issue of cookies-- is it possible that improving javascript > features in browsers will ultimately solve the problem? For instance, > the trend of one-page applications give a model in which requests are > formed by the application's client software, allowing it to specify > any session-identifying headers it needs. The model also helps with > caching, as session-specific data can be requested in individual > chunks, while application-environment data (the layout, common markup, > etc) come separately (with more caching, since they apply more > generally). > > If I'm understanding it correctly, I'd suggest that cookies & sessions > be considered a client software issue, not a protocol issue. >
Received on Friday, 20 July 2012 15:16:50 UTC