This issue has been created
There is 1 comment.
 
 
XWiki Platform / cid:jira-generated-image-avatar-cfb8e576-4e06-41bc-98dd-0f48a284b016 XWIKI-22716 Open

The WebSocket context assumes the handshake request and response objects can be used after the handshake is performed

 
View issue   ยท   Add comment
 

Issue created

 
cid:jira-generated-image-avatar-21f8dc50-7e9f-450f-9d80-973dcc1eba59 Marius Dumitru Florea created this issue on 05/Dec/24 15:04
 
Summary: The WebSocket context assumes the handshake request and response objects can be used after the handshake is performed
Issue Type: cid:jira-generated-image-avatar-cfb8e576-4e06-41bc-98dd-0f48a284b016 Bug
Affects Versions: 16.10.0
Assignee: Unassigned
Components: WebSocket
Created: 05/Dec/24 15:04
Priority: cid:jira-generated-image-static-major-6b2695f8-70dc-4365-b92e-9e54b13f12e5 Major
Reporter: Marius Dumitru Florea
Description:

Our default WebSocket context implementation relies on stub HTTP request and response objects that wrap the WebSocket handshake request and response objects. Depending on the servlet container implementation, the WebSocket handshake request and response objects might become stale, and thus unusable after the handshake is performed, i.e. once we end up in the WebSocket end-point (which often needs to use the WebSocket context).

See https://github.com/jetty/jetty.project/issues/11809 for a related problem. This problem was caught on the Jakarta migration branch, where the new version of Jetty seems to have changed the behavior concerning the WebSocket handshake request and response objects.

 
 

1 comment

 
cid:jira-generated-image-avatar-21f8dc50-7e9f-450f-9d80-973dcc1eba59 Marius Dumitru Florea on 05/Dec/24 15:07
 

The WebSocket connection is initiated with an HTTP handshake request. We hook on this moment with modifyHandshake to access and cache both the HandshakeRequest and HandshakeResponse objects. The first one, HandshakeRequest gives us access to some of the HTTP request information (like headers and cookies) but more importantly to the HTTP session. The change on Jetty side is that these objects, HandshakeRequest and HandshakeResponse, are now invalidated (along with the HTTP request and response) once the handshake is done, and we end up in the WebSocket end-point. So when we try to access again the request from the cached HandshakeRequest we get an exception. The solution is to extract all the information we need from HandshakeRequest while the handshake takes place (in modifyHandshake) and to stop saving a reference to the HandshakeRequest.