On 11/3/12 4:36 AM, Mark Thomas wrote:
> 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.
OK, perhaps I'm confusing separate cases. Please check my thinking...
The association we're trying to qualify is between the HttpSession at
the time of the opening handshake and the websocket session.
the websocket is protected by a security constraint, and the user logs out
- in this case, I think the implementations have to close the web socket
connection at the time that the HttpSession in invalidated
the websocket is not protected by a security constraint, and the user
logs out
- in this case, I was thinking we should also close the web socket
connection, but Mark you think we should let the developer make that
choice ?
the websocket is active, and the HttpSession is about to time out
- if the websocket is still active we'd like to touch the http session
to keep it alive, but we cannot do that because we'd need to alter the
client cookie expiration time.
- so, if the websocket is protected by a security constraint, we need to
close it
- if the web socket is not protected by a security constraint, then let
the developer choose ?
- Danny
> Mark
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation