Description of problem: If a ServerEndpoint is registered at "/", WebSocket upgrade requests are treated as regular http requests, and the ServerEndpoint is not activated. Version-Release number of selected component (if applicable): I've recreated it with EAP 6.4.0 and 6.4.3. How reproducible: Easily, using the websocket-hello quickstart. Steps to Reproduce: 1. Modify HelloName.java in the quickstart to use "/" as the value to @ServerEndpoint 2. Modify index.html in the quickstart to connect to '/jboss-websocket-hello' 3. Build and deploy war 4. Visit http://localhost:8080/jboss-websocket-hello 5. Click "Open Connection" Actual results: You'll see an error message: "The connection was closed or timed out. Please click the Open Connection button to reconnect." This is because the upgrade request gets back a 302 response instead of being upgraded. Expected results: The connection should open properly. Additional info: I believe the cause of this is in org.apache.tomcat.websocket.server.WsFilter#doFilter, in the way it determines the path. It should probably treat "" as "/", since the former is not a valid path for an endpoint, but is conceptually equivalent.
It looks this is because path '/' conflicts with index.html file in WEB-INF/ -> you can't have two resources mapped to the same path. If you rename the file to e.g. index2.html, clean & redeploy, then it works. Closing as not a bug, please reopen if you disagree.
I tried that - I moved index.html -> index2.html, cleaned, and redeployed. If I then load index2.html and try to open the connection, I still get a 302 to http://localhost:8080/jboss-websocket-hello/ This was with EAP 6.4.3, is that the version you tested with?
Can you verify that there is no index.html file left in your war? Also, if you try to access the original address http://localhost:8080/jboss-websocket-hello/ (or also http://localhost:8080/jboss-websocket-hello/index.html) it should now return 404. Is that so? I tested with current SNAPSHOT and also with 6.4.3.
> Can you verify that there is no index.html file left in your war? Yes, the war contains: 0 Fri Aug 28 14:47:30 EDT 2015 META-INF/ 127 Fri Aug 28 14:47:28 EDT 2015 META-INF/MANIFEST.MF 0 Fri Aug 28 14:47:30 EDT 2015 WEB-INF/ 0 Fri Aug 28 14:47:30 EDT 2015 WEB-INF/classes/ 0 Fri Aug 28 14:47:30 EDT 2015 resources/ 0 Fri Aug 28 14:47:30 EDT 2015 resources/css/ 1210 Thu Aug 27 10:41:22 EDT 2015 WEB-INF/jboss-web.xml 4732 Tue Aug 25 14:51:00 EDT 2015 index2.html 1118 Tue Aug 25 13:10:20 EDT 2015 resources/css/hello.css 0 Fri Aug 28 14:47:30 EDT 2015 META-INF/maven/ 0 Fri Aug 28 14:47:30 EDT 2015 META-INF/maven/org.jboss.quickstarts.eap/ 0 Fri Aug 28 14:47:30 EDT 2015 META-INF/maven/org.jboss.quickstarts.eap/jboss-websocket-hello/ 3396 Tue Aug 25 13:10:20 EDT 2015 META-INF/maven/org.jboss.quickstarts.eap/jboss-websocket-hello/pom.xml 140 Fri Aug 28 14:47:30 EDT 2015 META-INF/maven/org.jboss.quickstarts.eap/jboss-websocket-hello/pom.properties > Also, if you try to access the original address > http://localhost:8080/jboss-websocket-hello/ (or also > http://localhost:8080/jboss-websocket-hello/index.html) it should > now return 404. Is that so? Yes, both of those routes result in a 404. I pushed my changes to https://github.com/tobias/jboss-eap-quickstarts/commits/websocket-at-root, in case you want to try with that version. All of my changes are in this commit: https://github.com/tobias/jboss-eap-quickstarts/commit/a4cdaba614c794a26064b2523144e8db244abd98
Hmm, it works only with the URL ending with a slash character: var wsURI = 'ws://' + window.location.host + '/jboss-websocket-hello/'; doesn't work without slash: var wsURI = 'ws://' + window.location.host + '/jboss-websocket-hello'; I would say it's OK though, because response is 302 with location header set to http://localhost:8080/jboss-websocket-hello/, so browser would normally follow this redirection. Apparently, websockets don't follow redirections, they fail if they get anything else than 101.
That makes sense, thanks.