The WebSocket upgrade is typically done before anything else. That includes cookie management, authentication, parameter handling, content-type handling, content-encoding handling, etc ...
Typically, the WebSocket upgrade is done via a WebSocketUpgradeFilter (which sits first in line of the filter chain). But in your specific case, I would recommend NOT using javax.websocket API, and use the Jetty WebSocket API instead. Register your own custom WebSocketCreator implementation that works within your web app. That way you are in (limited) control over what the upgrade does. I say limited, as there are many things not supported during the websocket upgrade handshake, and using the WebSocketCreator handles much of that for you (eg: many standard HTTP Response headers are forbidden during websocket upgrade). To use this, you would continue to use the WebSocketUpgradeFilter and add path mappings to your custom creator (be it Servlet url-pattern, or Regex, and even Uri Template path mappings). Joakim Erdfelt / [email protected] On Thu, Jan 7, 2021 at 10:37 AM Silvio Bierman <[email protected]> wrote: > Hello all, > > I have been experimenting with the JSR 356 Websocket support in Jetty > using WebSocketServerContainerInitializer. Although the API is pretty > clean and simple it is not a good match for my embedded Jetty > application model since requests are being promoted to socket class > instances at the context level. > > The application (embedded Jetty) uses one context with one Servlet > singleton and dispatches all messages through a complicated hierarchy > into scripts (which are custom language applications) and inside these > scripts into object instances containing handlers. HTTP Sessions are > also mapped onto object instances that either handle session local > requests themselves or contain other objects that handle their own > requests. This way URLs address specific parts of a specific > applications and the requests are handled inside the local object > state/scope of the handler objects. > > Adding Websockets to this application model would be extremely more > elegant if I could dispatch/handle the initial HTTP request as a regular > request (through the Servlet singleton) and then promote the request to > a socket class instance inside the local scopes myself. Is that at all > possible? And if so, will I have to do everything myself or is it still > possible to use most/part of the Jetty Websocket embedding? > > Any pointers will be very much appreciated. > > Kind regards, > > Silvio > _______________________________________________ > jetty-users mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
