Here's a few thoughts since this thread has sort of ended up talking about web socket connections and Http Sessions.
HttpSession is only an embodiment of the sequence Http calls from the same web client into the web server where the web sockets are, and from our perspective, the opening handshakes from one web client to one or more of the web sockets are some those calls. There might have been several calls (including an authentication interaction) before the web client sent each opening handshake. The same web client may have sent several different opening handshakes, each for a different web socket. There might be lots more plain http requests and/or opening handshakes coming from the same web client before the day is done.
So we have one HttpSession per web client. Embodies all the http requests it made. (some of them handshakes, some of them not).
Then, per web-socket-client-server pair, we have (logically) one connection. We're modeling this in the API as a Session. The Session appears with the Open frame, and dies when the connection ends.
So we have one Session per connection. Since each web client can create multiple web-socket-clients, there are multiple Sessions for each HttpSession. Since web developers often put all sorts of useful information in the HttpSession, I think it'd be useful to expose this into web socket sessions (as v003 of the API does).
How we relate the lifetimes of Sessions and HttpSessions is going to depend in part how we want to do the security model for web sockets.
I'll throw out a few scenarios that perhaps we should make easy for developers to create:-
1. if a web client has already authenticated with the server (using one of the standard EE methods for example: HttpBasic, form or client cert) then an opening handshake from the same client should be treated as already authenticated.
2. it should be easy for a web socket developer to declare whether access to a web socket server endpoint needs to be authenticated, and who can access it, and if it needs an encrypted connection or not. Maybe this is as simple as treating the ws:// URLs as falling under the same security model as the web container uses for its web resources?
3. in a web application, if the client doesn't make any interactions for a long time, but the web socket connections that the client opened up are in use (or have not expired), then for many developers, this will mean they think of the client as being still active, and it should be easy configure things so that HttpSession does not expire on the web sockets (maybe by 'touching it' as I think Greg suggested.
4. in a web application where all the resources require authentication and an access check to access (web content and web socket content alike), if the client 'logs out' then the client should not be able to access any of the content any more (including the web sockets).
Do you agree ? Are there others ?
On 8/9/12 8:43 AM, Joe Walnes wrote:
[jsr356-experts] Re: [jsr356-users] Re: Multithreading Options