You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2013/11/28 10:27:11 UTC

[Bug 55824] New: HandshakeRequest.getHttpSocket() may return null at ServerEndpointConfig.Configurator.modifyHandshake time

https://issues.apache.org/bugzilla/show_bug.cgi?id=55824

            Bug ID: 55824
           Summary: HandshakeRequest.getHttpSocket() may return null at
                    ServerEndpointConfig.Configurator.modifyHandshake time
           Product: Tomcat 8
           Version: 8.0.0-RC5
          Hardware: PC
                OS: OpenBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: WebSocket
          Assignee: dev@tomcat.apache.org
          Reporter: niklas+apache@appli.se

Created attachment 31081
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=31081&action=edit
A test websocket endpoint implementation, a JS client to test it, and a
context.xml for container deployment.

In a webapp with just a websocket implementation, an HttpSession does not seem
to be created in time for the modifyHandshake call.  Attached is a test to show
this.  I have no idea if there are any downsides to it but I have a proposed
fix that does solve my test case, call the
HttpServletRequest.getSession(boolean create) method with a true parameter
instead of false from the WsHandshakeRequest constructor:

Index:
/d/sd0h/h/niklas/java/workspace-1/Tomcat8/java/org/apache/tomcat/websocket/server/WsHandshakeRequest.java
===================================================================
---
/d/sd0h/h/niklas/java/workspace-1/Tomcat8/java/org/apache/tomcat/websocket/server/WsHandshakeRequest.java
   (revision 1546042)
+++
/d/sd0h/h/niklas/java/workspace-1/Tomcat8/java/org/apache/tomcat/websocket/server/WsHandshakeRequest.java
   (working copy)
@@ -51,7 +51,7 @@

         queryString = request.getQueryString();
         userPrincipal = request.getUserPrincipal();
-        httpSession = request.getSession(false);
+        httpSession = request.getSession(true);

         // URI
         StringBuilder sb = new StringBuilder(request.getRequestURI());

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55824] HandshakeRequest.getHttpSession() may return null at ServerEndpointConfig.Configurator.modifyHandshake time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55824

Henri Manson <hf...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #7 from Henri Manson <hf...@gmail.com> ---
I totally agree with Nikla Hallqvist that it would really be convenient to get
an non-null httpSession when calling request.getHttpSession() in
modifyHandshake. My endpoint uses File resources with a path that would be
retrieved with ServletContext. I tried Nikla Hallqvist's method to obtain a
ServletContext using @WebListener but that fails on Apache 8.0.3.
I hope to get a solution for this problem

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55824] HandshakeRequest.getHttpSession() may return null at ServerEndpointConfig.Configurator.modifyHandshake time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55824

--- Comment #5 from Mark Thomas <ma...@apache.org> ---
That isn't how I read it.

If there is no "HTTP session under which a client is operating" then there is
no requirement to create one.

If you want an HTTP session to be available then you'll have to create one
first (e.g. with a filter). Note that the lifecycle of the HTTP session is
separate from that of the WebSocket session and the HTTP session can timeout
irrespective of whether or not the WebSocket session is still active.

"Anyway, it's quite inconvenient to have to create something else, a dummy,
that creates the HttpSession, just to get at the container's context, and thus,
parameters needed to configure the websocket." suggests you aren't configuring
your WebSocket connections correctly. There should be no need for access to the
HTTP session to do this. The users list is the place to follow up on that.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55824] HandshakeRequest.getHttpSession() may return null at ServerEndpointConfig.Configurator.modifyHandshake time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55824

--- Comment #6 from Niklas Hallqvist <ni...@appli.se> ---
OK, I accept the ruling, no problems.

I made the Configurator a @WebListener to get at the context instead.  It's
actually a better design.  Thanks for bearing with me.  I post this final
comment here since it may be useful resolution for others having the same
issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55824] HandshakeRequest.getHttpSession() may return null at ServerEndpointConfig.Configurator.modifyHandshake time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55824

--- Comment #4 from Niklas Hallqvist <ni...@appli.se> ---
"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. [WSC-7.2-1]"

To me this seems to imply there should be an HttpSession.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55824] HandshakeRequest.getHttpSession() may return null at ServerEndpointConfig.Configurator.modifyHandshake time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55824

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID
            Summary|HandshakeRequest.getHttpSoc |HandshakeRequest.getHttpSes
                   |ket() may return null at    |sion() may return null at
                   |ServerEndpointConfig.Config |ServerEndpointConfig.Config
                   |urator.modifyHandshake time |urator.modifyHandshake time

--- Comment #1 from Mark Thomas <ma...@apache.org> ---
Fixed the title.

The WebSocket specification and Javadoc refer to the HTTP Session that already
exists when the WebSocket handshake is received. There is no requirement for an
Http ses

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55824] HandshakeRequest.getHttpSession() may return null at ServerEndpointConfig.Configurator.modifyHandshake time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55824

--- Comment #3 from Niklas Hallqvist <ni...@appli.se> ---
Granted, this may not be a bug, I am not a native english speaker and did not
interpret the standards text quite as rigidly as you.  For me, there is an HTTP
session, although not an HttpSession, at the time. I consider that lazy
creation to be just an optimization.  Anyway, it's quite inconvenient to have
to create something else, a dummy, that creates the HttpSession, just to get at
the container's context, and thus, parameters needed to configure the
websocket.  Perhaps this is better seen as a feature request, and as such, much
too late in the release process.  Sad :-(

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55824] HandshakeRequest.getHttpSession() may return null at ServerEndpointConfig.Configurator.modifyHandshake time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55824

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 55824] HandshakeRequest.getHttpSession() may return null at ServerEndpointConfig.Configurator.modifyHandshake time

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55824

--- Comment #2 from Mark Thomas <ma...@apache.org> ---
...session to be created if one does not already exist.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org