Subject: Cookies, sessions, browser software

From: Paul Frazee <[email-masked]>
Date: Fri, 20 Jul 2012 09:39:05 -0500

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.

---

From: Ross Nicoll <[email-masked]>
Date: Fri, 20 Jul 2012 16:16:20 +0100

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.

---

From: Paul Frazee <[email-masked]>
Date: Fri, 20 Jul 2012 11:02:45 -0500

> 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.

Header usage is certain; I'm wondering if we can just simplify the
HTTP protocol and anticipate that each application can tailor their
own protocol with a more specific behavior.

> Beyond that, I don't think we can assume user agents will support Javascript
> or any other sort of scripting

Fair point; I don't know the scope of that issue. If that's not just
an "old software" situation, then my suggestion doesn't hold.

> 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.

Yeah, those are definitely problems with current implementations. I'm
trying to watch the trend and assume that issues like that will
eventually be sorted out, but maybe not.

---

From: Jonathan Ballard <[email-masked]>
Date: Fri, 20 Jul 2012 09:52:09 -0700

The HTTP-proxy that acquires state becomes the agent, and that change in
state does not require VM specifications in the protocol.

On Friday, July 20, 2012, Paul Frazee wrote:

> defined
> Javascript