The HttpSession is hard to retrieve: Add getHttpSession method to Session

[glassfishrobot]

Currently, the only way to retrieve the HTTP session (such as the Servlet API's HttpSession) is to call HandshakeRequest's getHttpSession method. Getting the HTTP session is very often required within a WebSocket, and this design means every server endpoint must have the following configurator to expose the session to the rest of the endpoint methods:

public static class EndpointConfigurator extends ServerEndpointConfig.Configurator
{
    @Override
    public void modifyHandshake(ServerEndpointConfig config, HandshakeRequest request, HandshakeResponse response)
    {
        super.modifyHandshake(config, request, response);

        config.getUserProperties().put("someSessionPropertyName", request.getHttpSession());
    }
}

And then later in an endpoint method:

...
    @OnOpen
    public void sessionOpened(Session session)
    {
        HttpSession httpSession = (HttpSession)session.getUserProperties.get("someSessionPropertyName");
    }
...

I suggest that the HandshakeRequest isn't the only interface that needs a getHttpSession method. We should add an Object getHttpSession() method to the Session interface as well. I'm aware that the HTTP session can time out before the Session, but the fact remains that there is never more than one HTTP session per Session, that the HTTP session never changes during the life of the Session, and that when the Session is initially created during the HTTP request an HTTP session may exist for that HTTP request.

Like its counterpart on HandshakeRequest, Session's getHttpSession method should return null if no HTTP session existed when the WebSocket connection was opened.

Affected Versions

[2.0]

[glassfishrobot]

@glassfishrobot Commented
Reported by beamerblvd

[glassfishrobot]

@glassfishrobot Commented
slominskir said:
Is the workaround described here even valid? It seems concurrent connections make the ServerEndpointConfig an unreliable place to stash sessions (apparently ServetEndpoingConfig is a shared Singleton). This is alluded to here: http://stackoverflow.com/questions/28939581/access-useragent-in-websocket-session

Maybe if we stash the session into a ThreadLocal it would work?

[glassfishrobot]

@glassfishrobot Commented
joakimerdfelt said:
Please include a clearly declared definition of the scope of the HttpSession in the JSR356 spec as well.

Example: Some current implementations make any Servlet HttpSession accessed during an HTTP Upgrade essentially immutable/read-only during the lifetime of the WebSocket. Meaning changes to that HttpSession are not persisted, and information contained in that HttpSession are not updated from events outside of the WebSocket.

Also: Eclipse Jetty (and apparently Apache Tomcat) implement HttpSession access in the current JSR356 api/spec as outlined at
http://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-serverendpoint/17994303#17994303

[glassfishrobot]

@glassfishrobot Commented
slominskir said:
More general problem (passing request data to endpoint) is reported here:

https://java.net/jira/browse/WEBSOCKET_SPEC-235

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA WEBSOCKET_SPEC-218

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/websocket-spec/issues/218
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @pavelbucek

[markt-asf]

The request here is covered by #238.