Skip to main content

[jsr356-experts] Re: WebSocket Session/HttpSession

  • From: Danny Coward < >
  • To:
  • Cc: Greg Wilkins < >
  • Subject: [jsr356-experts] Re: WebSocket Session/HttpSession
  • Date: Fri, 02 Nov 2012 16:59:16 -0700

Hi Greg,

On 11/1/12 3:05 PM, Greg Wilkins wrote:
" type="cite">
We've bumped against this problem, but not really found a solution nor found it a total show stopper.
" type="cite">
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 ?

- Danny




" type="cite">
cheers



On 30 October 2012 09:53, Danny Coward < " target="_blank"> > wrote:
Hi folks,

One of the outstanding issues we had was to figure out how to 'touch' the http session to prevent it timing out. This you might remember was for the case where a user has logged into web application containing web sockets (e.g. stock trading with live updates). The user doesn't issue any more http requests, but the websocket sessions are still open (ticker updates).

We talked this through with Rajiv - we can use httpsession.setMaxInactiveInterval to postpone (indefinitely) the expiry of the http session on the server at any time. But the client cookie will retain the expiry time of its last http interaction. In which case, it seems that a browser client will clean out the cookie and the session will effectively be lost. Obviously we can't set the expiry of the cookie to an irresponsibly long time.

Has anyone come up against this problem ?

- Danny


--
Danny Coward
Java EE
Oracle Corporation



--
Greg Wilkins < " target="_blank"> >
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.


--
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