Re: Introducing a Session header...

On 18.07.2012 12:04, James M Snell wrote:
> On Tue, Jul 17, 2012 at 4:56 PM, Martin Thomson wrote:
>
>> On 17 July 2012 16:49, James M Snell wrote:
>> > This moved off list unintentionally...
>>
>> Ahh, oops.  I thought it was intentional.
>>
>> > assuming we can successful move people away from using sessions as 
>> a
>> whole
>>
>> Who are you trying to kid?  Cookies are here to stay.  It's just 
>> that
>> anyone with any sense will avoid them.
>>
>>
> Yes... sadly, I know. One can dream.
>
>
>> > (While we're at it, can we also eliminate routing based on the
>> request-uri?)
>>
>> Why would you ever want to do that?  That's an important feature.  
>> At
>> least it is stateless.
>>
>
> A variety of reasons, really, but nothing that's likely to sway any
> opinions ;-) ... by far the more important thing is: IF session-based
> routing continues to be a "feature", we should do what we can to 
> break to
> reliance on cookies (as much as possible anyway). If, however, the 
> general
> movement is (quite thankfully) away from session-based routing, then
> beautiful, I'm happy.
>
> - James


What I'm getting from this thread is that the proposed "session" is 
just an identifier for some client context.

Essentially meaning a message from the client "I've created a context, 
any context you create for this request needs to associate with this 
ID".

The server is still free to create a traditional Session (or not) at 
its end. Using a different key entirely, just translate from server key 
to client key when talking to the client - and hey thats actually safer 
than todays session cookies. But first-party Cookie data and whatever 
state can be pushed back to the client for inclusion into that context 
without introducing ever-cookie issues around expiring a bunch of 
unassociated data.


NP: If/when this header gets defined it *will* have to traverse 
HTTP/1.x connections so please make the ABNF: 1#(token / quoted-string) 
[';' ... ]

AYJ

Received on Wednesday, 18 July 2012 00:52:36 UTC