Is it possible to get the HttpServletRequest inside a @ServerEndpoint? Primarily I am trying to get it so I can access the HttpSession object.
6 Answers
Update (November 2016): The information provided in this answer is for the JSR356 spec, individual implementations of the spec may vary outside of this information. Other suggestions found in comments and other answers are all implementation specific behaviors outside of the JSR356 spec.
If the suggestions in here are causing you problems, upgrade your various installations of Jetty, Tomcat, Wildfly, or Glassfish/Tyrus. All current versions of those implementations have all been reported to work in the way outlined below.
Now back to the original answer from August 2013...
The answer from Martin Andersson has a concurrency flaw. The Configurator can be called by multiple threads at the same time, it is likely that you will not have access to the correct HttpSession object between the calls from modifyHandshake()
and getEndpointInstance()
.
Or said another way...
- Request A
- Modify Handshake A
- Request B
- Modify Handshake B
- Get Endpoint Instance A <-- this would have Request B's HttpSession
- Get Endpoint Instance B
Here's a modification to Martin's code that uses ServerEndpointConfig.getUserProperties()
map to make the HttpSession
available to your socket instance during the @OnOpen
method call
GetHttpSessionConfigurator.java
package examples;
import javax.servlet.http.HttpSession;
import javax.websocket.HandshakeResponse;
import javax.websocket.server.HandshakeRequest;
import javax.websocket.server.ServerEndpointConfig;
public class GetHttpSessionConfigurator extends ServerEndpointConfig.Configurator
{
@Override
public void modifyHandshake(ServerEndpointConfig config,
HandshakeRequest request,
HandshakeResponse response)
{
HttpSession httpSession = (HttpSession)request.getHttpSession();
config.getUserProperties().put(HttpSession.class.getName(),httpSession);
}
}
GetHttpSessionSocket.java
package examples;
import java.io.IOException;
import javax.servlet.http.HttpSession;
import javax.websocket.EndpointConfig;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;
@ServerEndpoint(value = "/example",
configurator = GetHttpSessionConfigurator.class)
public class GetHttpSessionSocket
{
private Session wsSession;
private HttpSession httpSession;
@OnOpen
public void open(Session session, EndpointConfig config) {
this.wsSession = session;
this.httpSession = (HttpSession) config.getUserProperties()
.get(HttpSession.class.getName());
}
@OnMessage
public void echo(String msg) throws IOException {
wsSession.getBasicRemote().sendText(msg);
}
}
Bonus feature: no instanceof
or casting required.
Some EndpointConfig Knowledge
EndpointConfig
objects do exist per "Endpoint Instance".
However, an "Endpoint Instance" has 2 meanings with the spec.
- Default behavior of the JSR, where each incoming upgrade request results in a new object instance of the endpoint class
- A
javax.websocket.Session
that ties together the object endpoint instance, with its configuration, to a specific logical connection.
It is possible to have a singleton Endpoint instance being used for multiple javax.websocket.Session
instances (that is one of the features that ServerEndpointConfig.Configurator
supports)
The ServerContainer implementation will track a set of ServerEndpointConfig's that represent all of the deployed endpoints that the server can respond to a websocket upgrade request.
These ServerEndpointConfig object instances can come from a few different sources.
- Manually provided by the
javax.websocket.server.ServerContainer.addEndpoint(ServerEndpointConfig)
- Usually done within a
javax.servlet.ServletContextInitializer.contextInitialized(ServletContextEvent sce)
call
- Usually done within a
- From the
javax.websocket.server.ServerApplicationConfig.getEndpointConfigs(Set)
call. - Automatically created from scanning of the web application for
@ServerEndpoint
annotated classes.
These ServerEndpointConfig
object instances exist as defaults for when a javax.websocket.Session
does eventually get created.
ServerEndpointConfig.Configurator Instance
Before any upgrade requests are received or processed, all of the ServerEndpointConfig.Configurator
objects now exist and are ready to perform their main and sole purpose, to allow for customization of the upgrade process of a websocket connection to an eventual javax.websocket.Session
Access to Session specific EndpointConfig
Note, you cannot access the ServerEndpointConfig
object instances from within a endpoint instance. You can only access EndpointConfig
instances.
This means if you provided ServerContainer.addEndpoint(new MyCustomServerEndpointConfig())
during deploy and later tried to access it via the annotations, it will not work.
All of the following would be invalid.
@OnOpen
public void onOpen(Session session, EndpointConfig config)
{
MyCustomServerEndpointConfig myconfig = (MyCustomServerEndpointConfig) config;
/* this would fail as the config is cannot be cast around like that */
}
// --- or ---
@OnOpen
public void onOpen(Session session, ServerEndpointConfig config)
{
/* For @OnOpen, the websocket implementation would assume
that the ServerEndpointConfig to be a declared PathParam
*/
}
// --- or ---
@OnOpen
public void onOpen(Session session, MyCustomServerEndpointConfig config)
{
/* Again, for @OnOpen, the websocket implementation would assume
that the MyCustomServerEndpointConfig to be a declared PathParam
*/
}
You can access the EndpointConfig during the life of the Endpoint object instance, but under a limited time. The javax.websocket.Endpoint.onOpen(Session,Endpoint)
, annotated @OnOpen
methods, or via the use of CDI. The EndpointConfig is not available in any other way or at any other time.
However, you can always access the UserProperties via the Session.getUserProperties()
call, which is available always. This User Properties map is always available, be it via the annotated techniques (such as a Session parameter during @OnOpen
, @OnClose
, @OnError
, or @OnMessage
calls), via CDI injection of the Session, or even with the use of non-annotated websockets that extend from javax.websocket.Endpoint
.
How Upgrade Works
As stated before, every one of the defined endpoints will have a ServerEndpointConfig
associated with it.
Those ServerEndpointConfigs
are a single instance that represents the default state of the EndpointConfig
that are eventually made available to the Endpoint Instances that are possibly and eventually created.
When a incoming upgrade request arrives, it has go through the following on the JSR.
- does the path match any of the ServerEndpointConfig.getPath() entries
- If no match, return 404 to upgrade
- pass upgrade request into ServerEndpointConfig.Configurator.checkOrigin()
- If not valid, return error to upgrade response
- create HandshakeResponse
- pass upgrade request into ServerEndpointConfig.Configurator.getNegotiatedSubprotocol()
- store answer in HandshakeResponse
- pass upgrade request into ServerEndpointConfig.Configurator.getNegotiatedExtensions()
- store answer in HandshakeResponse
- Create new endpoint specific ServerEndpointConfig object. copy encoders, decoders, and User Properties. This new ServerEndpointConfig wraps default for path, extensions, endpoint class, subprotocols, configurator.
- pass upgrade request, response, and new ServerEndpointConfig into ServerEndpointConfig.Configurator.modifyHandshake()
- call ServerEndpointConfig.getEndpointClass()
- use class on ServerEndpointConfig.Configurator.getEndpointInstance(Class)
- create Session, associate endpoint instance and EndpointConfig object.
- Inform endpoint instance of connect
- annotated methods that want EndpointConfig gets the one associated with this Session.
- calls to Session.getUserProperties() returns EndpointConfig.getUserProperties()
To note, the ServerEndpointConfig.Configurator is a singleton, per mapped ServerContainer endpoint.
This is intentional, and desired, to allow implementors several features.
- to return the same Endpoint instance for multiple peers if they so desire. The so called stateless approach to websocket writing.
- to have a single point of management of expensive resources for all Endpoint instances
If the implementations created a new Configurator for every handshake, this technique would not be possible.
(Disclosure: I write and maintain the JSR-356 implementation for Jetty 9)

- 1
- 1

- 46,896
- 7
- 86
- 136
-
3**1.** Did you know that the `EndpointConfig` object passed to your `@OnOpen` method, if you're using Tyrus, is not your custom configuration object but it is the default? That made me not trust the user properties map. Besides, you don't have to use the instanceof operator. I used it to make sure we get a proper exception type if a future programmer uses the custom class inappropriately. **2.** It may look like a concurrency flaw but it isn't. I have emphasized this in my answer already. The JavaDoc says: "The implementation creates a new instance of the configurator per logical endpoint." – Martin Andersson Aug 01 '13 at 20:27
-
Since Archimedes Trajano accepted your answer and the statement that my answer contains a "concurrency flaw". I would be glad if anyone of you could elaborate a bit why you think that way. Maybe I have misunderstood the specification and/or the JavaDocs of the WebSocket API. – Martin Andersson Aug 01 '13 at 20:34
-
A quote from page 23 of JSR-356: "[..] the container must use a unique instance of the endpoint per peer". But again, you are two guys against me so I reserve the honor of being wrong. But please let me know why. I tested the user properties map and it seems to work even though the properties map is supposed to be unique per configuration object instance and the objects passed in are different. One being our custom object and the other one being the Tyrus default. I would say that the bonus feature added with such a design is not having to override the `getEndpointInstance` method at all. – Martin Andersson Aug 01 '13 at 20:55
-
*ping*. Joakim (and implicitly Archimedes), you kind of have a community responsibility to update your answer or make sense out of the claim that storing a variable in a custom Configurator object isn't thread safe. – Martin Andersson Aug 05 '13 at 13:01
-
I implemented this example code on Tomcat 8.0.0-RC3 and request.getHttpSession() returns null. I think it's time to return to AJAX long polling. The fact that Tomcat and Jetty are exhibiting completely different behaviour does not bode well for the near future of the WebSocket standard. – jr. Oct 16 '13 at 13:27
-
3@studro it actually points to a poor spec for `javax.websocket`, not "the WebSocket standard". – Joakim Erdfelt Oct 16 '13 at 13:35
-
Great point. Is there an alternative Java WebSocket specification and implementation that you can recommend that will work in both Tomcat and Jetty containers? – jr. Oct 16 '13 at 23:42
-
1@Joakim Looking at the source code of Jetty 9.1.x in JsrCreator.java, it's clear that `modifyHandshake` receives the original `ServerEndpointConfig` and not the per-handshake copy. Compared to the flow you describe, `modifyHandshake` (point 6) happens even before `checkOrigin` (point 2). It is exactly the same with GlassFish 4, so I don't see how using userProperties() is more threadsafe than using instance variables of the configurator. In fact, I don't see how it's possible to reliably pass anything between the configurator and the endpoint instance with current JSR 356 impls. – wdrai Feb 13 '14 at 01:52
-
ServerEndpointConfig.Configurator can be created by the implementation (via annotations) or be passed in pre-instantiated via other parts of the javax.websocket standard. The safe approach is to instantiate once and reuse, unlike the alternative with per-handshake copies. – Joakim Erdfelt Feb 14 '14 at 16:08
-
I guess my explanation was not very clear. What I meant is just that `modifyHandshake` receives a 'singleton' `ServerEndpointConfig` so it's not threadsafe to use endpointConfig.userProperties to store the session. From what I've checked, none of the two answers to the original question about storing the httpsession is right. – wdrai Feb 15 '14 at 20:53
-
3Just to be complete, Tomcat does pass the per-session endpointConfig to `modifyHanshake` so the answer is correct for Tomcat but not for Jetty and GlassFish. The spec does not seem to specify any particular behaviour. – wdrai Feb 18 '14 at 17:51
-
`HttpSession httpSession = (HttpSession)request.getHttpSession();` will return null in my case. I thought a WS connection is initiated within a http-request? So there should be a HttpSession. Do you have any idea whats wrong here? EDIT: Looks like the HttpSession is not created yet. So I just have to create a Session before I allow access to the Websocket – Lama May 09 '14 at 10:55
-
I just deployed an spring mcv application and my websocket project to the same jboss. The Spring mvc fronted will show my httpSession. However, the Webservice still won't read the HttpSession. – Lama May 09 '14 at 12:30
-
Same problem for Wildfly endpointConfig.userProperties is absolutely not thread safe, and for the record I also get null in (HttpSession)request.getHttpSession() but I'm using instead request.getHeaders() that returns the https headers... the problem is I can't pass to the ServerEnpoint because I can't use userProperties – Israel Dec 03 '14 at 16:40
-
After lot of tests I was unable to get this working using a brand new wildfly with a simple websocket app – Israel Dec 05 '14 at 10:49
-
Could you take a look at this question http://stackoverflow.com/questions/39740531/jetty-websocket-java-lang-runtimeexception-cannot-load-platform-configurator – Pavel_K Sep 28 '16 at 07:17
-
Is there a way to copy websocket session attributes back to Http Session? – Hari Rao Apr 11 '17 at 10:10
-
No, as the HttpSession has no lifecycle once you are upgraded past http into websocket. (This is undefined by the Servlet spec and WebSocket spec). – Joakim Erdfelt Apr 11 '17 at 14:59
-
2022.03.14, unfortunately, when my program running on JBoss EAP 7.4 the EndpointConfig instance is just the one (ServerEndpointConfig) used in configurator, so request A & request B shares the same user data, I also tried ThreadLocal, modifyHandshake is not run in the same thread as onOpen, no solutions so far. :( – Daniel Yang Mar 14 '22 at 09:47
Preface
It's unclear whether you're wanting the HttpServletRequest
, the HttpSession
, or properties out of the HttpSession
. My answer will show how to get the HttpSession
or individual properties.
I've omitted null and index bounds checks for brevity.
Cautions
It's tricky. The answer from Martin Andersson is not correct because the same instance of ServerEndpointConfig.Configurator
is used for every connection, hence a race condition exists. While the docs state that "The implementation creates a new instance of the configurator per logical endpoint," the spec does not clearly define a "logical endpoint." Based on the context of all the places that phrase is used, it appears to mean the binding of a class, configurator, path, and other options, i.e., a ServerEndpointConfig
, which is clearly shared. Anyway you can easily see if an implementation is using the same instance by printing out its toString()
from within modifyHandshake(...)
.
More surprisingly the answer from Joakim Erdfelt also does not work reliably. The text of JSR 356 itself does not mention EndpointConfig.getUserProperties()
, it is only in the JavaDoc, and nowhere does it seem to be specified what its exact relationship is to Session.getUserProperties()
. In practice some implementations (e.g., Glassfish) return the same Map
instance for all calls to ServerEndpointConfig.getUserProperties()
while others (e.g., Tomcat 8) don't. You can check by printing out the map contents before modifying it within modifyHandshake(...)
.
To verify, I copied the code directly from the other answers and then tested it against a multithreaded client I wrote. In both cases I observed the incorrect session being associated with the endpoint instance.
Outline of Solutions
I've developed two solutions, which I've verified work correctly when tested against a multithreaded client. There are two key tricks.
First, use a filter with the same path as the WebSocket. This will give you access to the HttpServletRequest
and HttpSession
. It also gives you a chance to create a session if it doesn't already exist (although in that case using an HTTP session at all seems dubious).
Second, find some properties that exist in both the WebSocket Session
and HttpServletRequest
or HttpSession
. It turns out there are two candidates: getUserPrincipal()
and getRequestParameterMap()
. I will show you how to abuse both of them :)
Solution using User Principal
The easiest way is to take advantage of Session.getUserPrincipal()
and HttpServletRequest.getUserPrincipal()
. The downside is this could interfere with other legitimate uses of this property, so use it only if you are prepared for those implications.
If you want to store just one string, such as a user ID, this is actually not too much of an abuse, though it presumably should be set in some container managed way rather than overriding the wrapper as I'll show you. Anyway you would do that by just overriding Principal.getName()
. Then you don't even need to cast it in the Endpoint
. But if you can stomach it, you can also pass the whole HttpSession
object as follows.
PrincipalWithSession.java
package example1;
import java.security.Principal;
import javax.servlet.http.HttpSession;
public class PrincipalWithSession implements Principal {
private final HttpSession session;
public PrincipalWithSession(HttpSession session) {
this.session = session;
}
public HttpSession getSession() {
return session;
}
@Override
public String getName() {
return ""; // whatever is appropriate for your app, e.g., user ID
}
}
WebSocketFilter.java
package example1;
import java.io.IOException;
import java.security.Principal;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;
@WebFilter("/example1")
public class WebSocketFilter implements Filter {
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest httpRequest = (HttpServletRequest) request;
final PrincipalWithSession p = new PrincipalWithSession(httpRequest.getSession());
HttpServletRequestWrapper wrappedRequest = new HttpServletRequestWrapper(httpRequest) {
@Override
public Principal getUserPrincipal() {
return p;
}
};
chain.doFilter(wrappedRequest, response);
}
public void init(FilterConfig config) throws ServletException { }
public void destroy() { }
}
WebSocketEndpoint.java
package example1;
import javax.servlet.http.HttpSession;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;
@ServerEndpoint("/example1")
public class WebSocketEndpoint {
private HttpSession httpSession;
@OnOpen
public void onOpen(Session webSocketSession) {
httpSession = ((PrincipalWithSession) webSocketSession.getUserPrincipal()).getSession();
}
@OnMessage
public String demo(String msg) {
return msg + "; (example 1) session ID " + httpSession.getId();
}
}
Solution Using Request Parameters
The second option uses Session.getRequestParameterMap()
and HttpServletRequest.getParameterMap()
. Note that it uses ServerEndpointConfig.getUserProperties()
but it is safe in this case because we're always putting the same object into the map, so whether it's shared makes no difference. The unique session identifier is passed not through the user parameters but instead through the request parameters, which is unique per request.
This solution is slightly less hacky because it does not interfere with the user principal property. Note that if you need to pass through the actual request parameters in addition to the one that's inserted, you can easily do so: just start with the existing request parameter map instead of a new empty one as shown here. But take care that the user cannot spoof the special parameter added in the filter by supplying their own request parameter by the same name in the actual HTTP request.
SessionTracker.java
/* A simple, typical, general-purpose servlet session tracker */
package example2;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import javax.servlet.annotation.WebListener;
import javax.servlet.http.HttpSession;
import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;
@WebListener
public class SessionTracker implements ServletContextListener, HttpSessionListener {
private final ConcurrentMap<String, HttpSession> sessions = new ConcurrentHashMap<>();
@Override
public void contextInitialized(ServletContextEvent event) {
event.getServletContext().setAttribute(getClass().getName(), this);
}
@Override
public void contextDestroyed(ServletContextEvent event) {
}
@Override
public void sessionCreated(HttpSessionEvent event) {
sessions.put(event.getSession().getId(), event.getSession());
}
@Override
public void sessionDestroyed(HttpSessionEvent event) {
sessions.remove(event.getSession().getId());
}
public HttpSession getSessionById(String id) {
return sessions.get(id);
}
}
WebSocketFilter.java
package example2;
import java.io.IOException;
import java.util.Collections;
import java.util.Map;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;
@WebFilter("/example2")
public class WebSocketFilter implements Filter {
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
HttpServletRequest httpRequest = (HttpServletRequest) request;
final Map<String, String[]> fakedParams = Collections.singletonMap("sessionId",
new String[] { httpRequest.getSession().getId() });
HttpServletRequestWrapper wrappedRequest = new HttpServletRequestWrapper(httpRequest) {
@Override
public Map<String, String[]> getParameterMap() {
return fakedParams;
}
};
chain.doFilter(wrappedRequest, response);
}
@Override
public void init(FilterConfig config) throws ServletException { }
@Override
public void destroy() { }
}
WebSocketEndpoint.java
package example2;
import javax.servlet.http.HttpSession;
import javax.websocket.EndpointConfig;
import javax.websocket.HandshakeResponse;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.HandshakeRequest;
import javax.websocket.server.ServerEndpoint;
import javax.websocket.server.ServerEndpointConfig;
@ServerEndpoint(value = "/example2", configurator = WebSocketEndpoint.Configurator.class)
public class WebSocketEndpoint {
private HttpSession httpSession;
@OnOpen
public void onOpen(Session webSocketSession, EndpointConfig config) {
String sessionId = webSocketSession.getRequestParameterMap().get("sessionId").get(0);
SessionTracker tracker =
(SessionTracker) config.getUserProperties().get(SessionTracker.class.getName());
httpSession = tracker.getSessionById(sessionId);
}
@OnMessage
public String demo(String msg) {
return msg + "; (example 2) session ID " + httpSession.getId();
}
public static class Configurator extends ServerEndpointConfig.Configurator {
@Override
public void modifyHandshake(ServerEndpointConfig sec, HandshakeRequest request,
HandshakeResponse response) {
Object tracker = ((HttpSession) request.getHttpSession()).getServletContext().getAttribute(
SessionTracker.class.getName());
// This is safe to do because it's the same instance of SessionTracker all the time
sec.getUserProperties().put(SessionTracker.class.getName(), tracker);
super.modifyHandshake(sec, request, response);
}
}
}
Solution for Single Properties
If you only need certain properties out of the HttpSession
and not the whole HttpSession
itself, like say a user ID, then you could do away with the whole SessionTracker
business and just put the necessary parameters in the map you return from your override of HttpServletRequestWrapper.getParameterMap()
. Then you can also get rid of the custom Configurator
; your properties will be conveniently accessible from Session.getRequestParameterMap()
in the Endpoint.
WebSocketFilter.java
package example5;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;
@WebFilter("/example5")
public class WebSocketFilter implements Filter {
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
HttpServletRequest httpRequest = (HttpServletRequest) request;
final Map<String, String[]> props = new HashMap<>();
// Add properties of interest from session; session ID
// is just for example
props.put("sessionId", new String[] { httpRequest.getSession().getId() });
HttpServletRequestWrapper wrappedRequest = new HttpServletRequestWrapper(httpRequest) {
@Override
public Map<String, String[]> getParameterMap() {
return props;
}
};
chain.doFilter(wrappedRequest, response);
}
@Override
public void destroy() {
}
@Override
public void init(FilterConfig arg0) throws ServletException {
}
}
WebSocketEndpoint.java
package example5;
import java.util.List;
import java.util.Map;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;
@ServerEndpoint("/example5")
public class WebSocketEndpoint {
private Map<String, List<String>> params;
@OnOpen
public void onOpen(Session session) {
params = session.getRequestParameterMap();
}
@OnMessage
public String demo(String msg) {
return msg + "; (example 5) session ID " + params.get("sessionId").get(0);
}
}

- 817
- 9
- 11
-
1This should be the accepted answer. Great work Chad. But I have a doubt: I don't think it is possible to place an outer filter for every implementation – idelvall Feb 16 '16 at 10:25
-
I tried this on Wildfly/Undertow, but `session.getUserPrincipal()` always returns `null` even if the filter is applied correctly. Is it possibile the Undertow WS doesn't use the servlet request from the filter? – Giovanni Lovato Mar 24 '16 at 16:30
-
"I've developed two solutions, which I've verified work correctly when tested against a multithreaded client." <--- tested on what plaforms? – Gus Nov 27 '16 at 21:55
-
You cannot cast the WebSocket Session around like that (its not supported by the JSR356 spec), your solution will be implementation specific. – Joakim Erdfelt Nov 28 '16 at 14:11
-
Also, the JSR356 spec has no support requirement of Filters before the WebSocket upgrade. The implementers can choose to handle Upgrade before the Servlet chain is executed. (and many implementation do this) – Joakim Erdfelt Nov 28 '16 at 14:14
-
@Gus Works on Tomcat 8.0.23 and 9.0.0.M13; GlassFish 4.1.1; Jetty 9.1.6. However it has **stopped working** on Jetty 9.2.10 and 9.3.8 because it no longer processes your Servlet Filters before the WebSocket upgrade. – Chad N B Dec 06 '16 at 07:09
-
@JoakimErdfelt Where is the invalid cast? I am not sure which line you're referring to. This one `Object tracker = ((HttpSession) request.getHttpSession())...` should be OK by the [HandshakeRequest JavaDoc](https://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html#getHttpSession--). This one `httpSession = ((PrincipalWithSession) webSocketSession.getUserPrincipal())...` might be sketchier...it depends on the `Principal` being the same one returned by `HttpServletRequest.getUserPrincipal()`...but it is not casting a WS session. – Chad N B Dec 06 '16 at 07:18
Is it possible?
Let's review the Java API for WebSocket specification to see if getting hold of the HttpSession
object is possible. The specification says on page 29:
Because websocket connections are initiated with an http request, there is an association between the HttpSession under which a client is operating and any websockets that are established within that HttpSession. The API allows access in the opening handshake to the unique HttpSession corresponding to that same client.
So yes it is possible.
However, I don't think it is possible for you to get hold of a reference to the HttpServletRequest
object though. You could listen for all new servlet requests using a ServletRequestListener
, but you would still have to figure out which request belong to which server endpoint. Please let me know if you find a solution!
Abstract how-to
How-to is loosely described on pages 13 and 14 in the specification and exemplified by me in code under the next heading.
In English, we will need to intercept the handshake process to get hold of a HttpSession
object. To then transfer the HttpSession reference to our server endpoint, we also need to intercept when the container creates the server endpoint instance and manually inject the reference. We do all of this by providing our own ServerEndpointConfig.Configurator
and override the methods modifyHandshake()
and getEndpointInstance()
.
The custom configurator will be instantiated once per logical ServerEndpoint
(See the JavaDoc).
Code example
This is the server endpoint class (I provide the implementation of the CustomConfigurator class after this code snippet):
@ServerEndpoint(value = "/myserverendpoint", configurator = CustomConfigurator.class)
public class MyServerEndpoint
{
private HttpSession httpSession;
public void setHttpSession(HttpSession httpSession) {
if (this.httpSession != null) {
throw new IllegalStateException("HttpSession has already been set!");
}
this.httpSession = httpSession;
}
@OnOpen
public void onOpen(Session session, EndpointConfig config) {
System.out.println("My Session Id: " + httpSession.getId());
}
}
And this is the custom configurator:
public class CustomConfigurator extends ServerEndpointConfig.Configurator
{
private HttpSession httpSession;
// modifyHandshake() is called before getEndpointInstance()!
@Override
public void modifyHandshake(ServerEndpointConfig sec, HandshakeRequest request, HandshakeResponse response) {
httpSession = (HttpSession) request.getHttpSession();
super.modifyHandshake(sec, request, response);
}
@Override
public <T> T getEndpointInstance(Class<T> endpointClass) throws InstantiationException {
T endpoint = super.getEndpointInstance(endpointClass);
if (endpoint instanceof MyServerEndpoint) {
// The injection point:
((MyServerEndpoint) endpoint).setHttpSession(httpSession);
}
else {
throw new InstantiationException(
MessageFormat.format("Expected instanceof \"{0}\". Got instanceof \"{1}\".",
MyServerEndpoint.class, endpoint.getClass()));
}
return endpoint;
}
}

- 18,072
- 9
- 87
- 115
-
1
-
2oh shit. Sorry! Copy pasted that part from an already implemented solution I had. In my case the endpoint was called a ConnectionWebSocket =) I edited the answer. Thank you! Don't forget to upvote if it was useful to you. – Martin Andersson Aug 01 '13 at 07:25
-
There is an easier (and more correct) way, see my answer to this question too. – Joakim Erdfelt Aug 01 '13 at 12:43
-
1For JBoss/WildFly 8.1 powered by Undertow, getEndpointInstance is never called at all. For me, the only workaround is to pass HttpSession via ThreadLocal because modifyHandshake and onOpen are actually executed in the same filter/request processing chain. – Jiří Vypědřík Sep 23 '14 at 13:24
-
I was wrong, modifyHandshake and onOpen are always executed in different threads, so I had to pass servlet data via static map with keys as pairs host/port of the client connection. However, this information is not directly available but via some reflection magic. – Jiří Vypědřík Sep 23 '14 at 19:05
-
All above answers worth reading, but none of them solves OP's (and my) problem.
You can access HttpSession when a WS end point is opening and pass it to newly created end point instance but no one guarantees there exist HttpSession instance!
So we need step 0 before this hacking (I hate JSR 365 implementation of WebSocket). Websocket - httpSession returns null
-
This is a good point, but it is not an answer and should be a comment. – daiscog Jun 01 '16 at 12:00
All possible solutions are based upon:
A. Client browser implementations maintains Session ID via Cookie value passed as an HTTP Header, or (if cookies are disabled) it is managed by Servlet container which will generate Session ID postfix for generated URLs
B. You can access HTTP Request Headers only during HTTP handshake; after that, it is Websocket Protocol
So that...
Solution 1: use "handshake" to access HTTP
Solution 2: In your JavaScript on the client side, dynamically generate HTTP Session ID parameter and send first message (via Websocket) containing this Session ID. Connect "endpoint" to the cache / utility class maintaining Session ID -> Session mapping; avoid memory leaks, you can use Session Listener for instance to remove session from cache.
P.S. I appreciate answers from Martin Andersson and Joakim Erdfelt. Unfortunately, solution of Martin is not thread safe...

- 155
- 1
- 9
-
2You can literally vote for solution 1 [once you have 15 rep](http://stackoverflow.com/help/privileges/vote-up). This looks more like commentary, which you can earn the privilege of sharing [once you have 50 rep](http://stackoverflow.com/help/privileges/comment). Please read ["How do I write a good answer?"](http://stackoverflow.com/help/how-to-answer) – Scott Solmer Sep 17 '14 at 17:25
-
I was unable to comment, that's why I posted it as 'answer'. Thank you! – Fuad Efendi Sep 23 '15 at 17:24
The only way that works across all applications servers is use ThreadLocal. See:

- 7,499
- 9
- 52
- 61
-
link is dead. That's why it's best to write examples. Isn't it superseded by : https://www.oracle.com/technical-resources/articles/java/jsr356.html ? – Vincent Gerris Nov 20 '20 at 21:23