Need to know more details.
When you enable the `websocket` module on `jetty-home`/`jetty-base` a few things happen.
1. The websocket JARs for the various APIs become available on the Server classpath.
2. The websocket ServletContainerInitializers kick in to initialize various things within the javax.servlet.ServletContext of your running webapp (via use of a WebAppContext).
In the case of `javax.websocket.server` the discovered @ServerEndpoint annotated classes are deployed (only with a WebAppContext).
There's nothing in your question that indicates if this is a websocket server issue? or a websocket client issue?
Also, you don't indicate which API you are using. (the jetty native websocket API, or the javax.websocket API)
If you are using websocket on server, put a breakpoint in WebSocketServlet or WebSocketUpgradeFilter to see what's happening there (depends on what API and technique for deployment you are using).
The tests for `isUpgradeRequest` is a good place to start debugging your behaviors.
See:
If the incoming request doesn't have the `Connection: upgrade` or `Upgrade: websocket` then one of two things is happening.
1. The client didn't send it
2. or Something is stripping out those headers
As for that "something is stripping out those headers" part, that could be a servlet Filter on your server side, it could be a Rewrite Rule that's stripping out on your server side, or something in front of Jetty is stripping them out.
A quick look through the code, there's nothing built into (or ships with) Jetty that will strip out those headers.
