This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1256945 - javax.websocket.server.ServerEndpoints registered at "/" are ignored
javax.websocket.server.ServerEndpoints registered at "/" are ignored
Status: CLOSED NOTABUG
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web (Show other bugs)
6.4.3
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tomas Hofman
Radim Hatlapatka
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-25 15:56 EDT by tcrawley
Modified: 2015-09-01 10:02 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-01 09:54:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description tcrawley 2015-08-25 15:56:55 EDT
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.
Comment 1 Tomas Hofman 2015-08-27 09:03:00 EDT
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.
Comment 2 tcrawley 2015-08-27 10:49:44 EDT
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?
Comment 3 Tomas Hofman 2015-08-28 04:42:24 EDT
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.
Comment 5 tcrawley 2015-08-28 14:57:15 EDT
> 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
Comment 6 Tomas Hofman 2015-09-01 09:54:40 EDT
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.
Comment 7 tcrawley 2015-09-01 10:02:29 EDT
That makes sense, thanks.

Note You need to log in before you can comment on or make changes to this bug.