On 02/11/2012 23:59, Danny Coward wrote:
> Hi Greg,
>
> On 11/1/12 3:05 PM, Greg Wilkins wrote:
>>
>> We've bumped against this problem, but not really found a solution nor
>> found it a total show stopper.
>>
>> Without browser support, there is no way to refresh the cookie on the
>> client side. So to keep a HTTP session active, either the application
>> has to arrange for an occasional HTTP request, or even to occasionally
>> drop the websocket connection and force a rehandshake.
>>
>> Unless we advocate for a setCookie frame we can send over websocket, I
>> think the only solution is to simply say that the HTTPSession is
>> unrelated to the Websocket connection.
> Well, they are clearly related at the time of the opening handshake. So
> I think we can depend on getting the user's identity context used to
> initiate a web socket connection, for example. And I think we should
> require that if the user invalidates the session (e.g. by logging out)
> we should close any web socket connections that were initiated under
> that session.
>
> But, yes :( What it looks like we may not be able to do is to require
> the http session be kept alive if only the web sockets in a web
> application are active if there are no http requests. I think we should
> probably let containers do this if they have some informal strategy to
> do it, but not require it.
>
> OK with everyone ?
Not really. This assumes that the WebSocket needs the user's identity.
I'd prefer that the application added an HttpSessionListener and used
that to close the WebSocket connection if it wanted to when the HTTP
session ended. We could probably provide most of the plumbing for this
in the spec so all that app had to do was a single call to associate the
WebSocket connection with an HttpSession.
Mark