Re: Cookies, sessions, browser software

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:

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