Support Programmatic WebSocket upgrade in Jetty 10

[lachlan-roberts]

Jetty version
10.0.x

Description
Issue brought up on the jetty-dev mailing list by @rstoyanchev.

I need to support WebSocket upgrades on Jetty 10 from within a web framework. Like what JettyWebSocketServlet or WebSocketUpgradeFilter do internally but not actually using them nor relying on their mapping mechanism.

The upgrade needs to be performed within a web framework which has its own Servlet, mappings, and infrastructure so it's not feasible to extend JettyWebSocketServlet. In addition, WebSocket upgrades are supported on multiple servers from the same place in the code which necessitates a programmatic API. Last but not least, the framework can also run on an abstraction layer above the Servlet API, with support for non-Servlet containers, which makes it very challenging to devise a solution based on use of a Servlet or Filter.

[sbordet]

@lachlan-roberts please consider that this seems the same use case that is already implemented in CometD, so perhaps we don't need anything because it's already there?

[lachlan-roberts]

@sbordet I think CometD is still using the WebSocketUpgradeFilter, and it would be registering the mappings through the JettyWebSocketServerContainer.

[sbordet]

@lachlan-roberts the upgrade mechanism is a standard in Servlet APIs, so I'm not sure what exactly is that we can't already do?

And if we really want to use a Jetty specific mechanism, WebSocketMappings.upgrade() is not enough?

[rstoyanchev]

@sbordet my request is for a programmatic way to perform a WebSocket upgrade at runtmie without having to register mappings. Those mappings are already maintained independently.

[sbordet]

@rstoyanchev did you try the standard Servlet 4.0 API for upgrade? Not good/enough for your case?

[rstoyanchev]

The only thing I'm aware of is the upgrade method on HttpSevletRequest but if IIRC that is a low level hook created for JSR-356 to get access to the underlying connection while the Servlet API remains unaware of any further details. Is there anything else I'm not aware of? I want to upgrade and handle the WebSocket with an @org.eclipse.jetty.websocket.api.annotations.WebSocket handler.

[gregw]

@sbordet we don't support the standard upgrade mechanism. Plus it won't upgrade to our websocket implementation even if we did.

[lachlan-roberts]

@rstoyanchev PR #5874 is ready if you want to take a look and give some feedback for your use case.

This exposes some additional classes including Handshaker in the websocket-core API. However you should avoid using websocket-core directly if possible. We have added a way to do programmatic websocket upgrades directly using the Jetty WebSocket API.

JettyWebSocketServerContainer container = JettyWebSocketServerContainer.getContainer(getServletContext());
...

JettyWebSocketCreator creator = (req, resp) -> new EchoSocket();
container.upgrade(creator, request, response);

[rstoyanchev]

@lachlan-roberts this looks good from an initial look. I will perform a more complete experiment next to confirm but as an API this is what I was looking for.

[rstoyanchev]

I have now done a deeper experiment successfully. I still need to do some more testing on the async side but overall I can confirm the API is good for our needs.

Note that I did run into other challenges due to types that have moved or changed, e.g. Frame, ExtensionConfig, WebSocketPolicy. This a challenge for us because we'll support both Jetty 9 and 10 for a while. I've been able to work around most of those via reflection but some remain a challenge like having an @OnWebSocketFrame method that can work in both Jetty 9 and 10. We use it to enable support for access to Pong messages, so it's not a high priority, but worth mentioning.

Thanks for these changes!

[joakime]

@rstoyanchev lots of internals changes from Jetty 9 to Jetty 10 (and just as big from Jetty 10 to Jetty 11)

[sunng87]

I'm working on a Clojure websocket server based on jetty too. As in Jetty 9, it relies on WebSocketHandler to configure websocket policy and create the creator

As I checked demos of Jetty 10, the new APIs requires subclassing JettyWebSocketServlet and give the servlet class to ServletContextHandler. The issue with this API is lack of ability to configure the servlet at runtime.

Being able to call container.upgrade(creator, request, response); can help a lot on this issue.