W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Cookies, sessions, browser software

From: Jonathan Ballard <dzonatas@gmail.com>
Date: Fri, 20 Jul 2012 09:52:09 -0700
Message-ID: <CAAPAK-7bcjva7L0+_yVAeVsztoSX+5YTovMk9Pab3gqwV53DOg@mail.gmail.com>
To: Paul Frazee <pfrazee@gmail.com>
Cc: Ross Nicoll <jrn@jrn.me.uk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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.
> >>
> >
>
>
Received on Friday, 20 July 2012 16:52:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 20 July 2012 16:52:43 GMT