Skip to main content

[jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession

  • From: Danny Coward < >
  • To:
  • Cc: Mark Thomas < >
  • Subject: [jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession
  • Date: Wed, 07 Nov 2012 18:02:35 -0800

On 11/3/12 4:36 AM, Mark Thomas wrote:
" type="cite">
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


" type="cite">
Mark



--
Danny Coward
Java EE
Oracle Corporation


[jsr356-experts] Re: WebSocket Session/HttpSession

Greg Wilkins 11/01/2012

[jsr356-experts] Re: WebSocket Session/HttpSession

Danny Coward 11/02/2012

[jsr356-experts] Re: WebSocket Session/HttpSession

Mark Thomas 11/03/2012

[jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession

Danny Coward 11/08/2012

[jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession

Mark Thomas 11/09/2012

[jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession

Danny Coward 11/13/2012

[jsr356-experts] Re: [jsr356-users] Re: WebSocket Session/HttpSession

Mark Thomas 11/14/2012

[jsr356-experts] Re: [jsr356-users] Re: Re: WebSocket Session/HttpSession

Danny Coward 11/15/2012

[jsr356-experts] Re: [jsr356-users] Re: Re: WebSocket Session/HttpSession

Mark Thomas 11/24/2012

[jsr356-experts] Re: [jsr356-users] Re: Re: WebSocket Session/HttpSession

Greg Wilkins 11/29/2012
 
 
Close
loading
Please Confirm
Close