Re: Cookies, sessions, browser software

> 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:04:04 UTC