Bug 57761 - WebSocket client won't connect to URLs that don't end in a slash (/)
WebSocket client won't connect to URLs that don't end in a slash (/)
Status: RESOLVED FIXED
Product: Tomcat 8
Classification: Unclassified
Component: WebSocket
8.0.x-trunk
PC All
: P2 normal (vote)
: ----
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2015-03-26 00:25 UTC by palmercox
Modified: 2015-03-26 21:01 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description palmercox 2015-03-26 00:25:41 UTC
The following program won't work on Tomcat's WebSocket client jars, both 8.0.20 and Trunk:

public class App2 {
    @ClientEndpoint
    public static class Client {
        @OnOpen
        public void onOpen(Session s) throws Exception {
            System.out.println("Sending PING");
            s.getBasicRemote().sendText("PING");
        }

        @OnMessage
        public void onMessage(Session s, String msg) throws Exception {
            System.out.println("GOT: " + msg);
            Thread.sleep(1000);
            s.getBasicRemote().sendText("PING");
            System.out.println("Sending PING");
        }
    }

    public static void main(final String[] args) throws Exception {
        ContainerProvider.getWebSocketContainer().connectToServer(
                Client.class,
                URI.create("ws://echo.websocket.org"));
        Thread.sleep(Long.MAX_VALUE);
    }
}

It fails with:

Exception in thread "main" javax.websocket.DeploymentException: The
HTTP request to initiate the WebSocket connection failed
    at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:357)
    at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:164)
    at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:181)
    at io.davinci.test_sync_gateway_websocket.App2.main(App2.java:31)
Caused by: java.io.EOFException
    at org.apache.tomcat.websocket.WsWebSocketContainer.processResponse(WsWebSocketContainer.java:606)
    at org.apache.tomcat.websocket.WsWebSocketContainer.connectToServer(WsWebSocketContainer.java:309)
    ... 3 more


If you add a slash to the end of the URL, however, it connects.
Comment 1 Remy Maucherat 2015-03-26 09:11:16 UTC
Without the slash, it would do a redirect and that's likely the cause of the problem. The ws client is not a real HTTP client, and I guess it cannot do many things, including auth, or apparently redirects. I am not convinced using a real HTTP client is mandatory, working only with a server that will do a straight upgrade could be good enough given what the ws API looks like (a non interactive direct connection).

I recommend considering the slash is mandatory.
Comment 2 Mark Thomas 2015-03-26 11:08:32 UTC
It isn't the redirec.  The Tomcat client has a bug. It requests "GET  HTTP/1.1".
Comment 3 Remy Maucherat 2015-03-26 11:20:05 UTC
Ah, that's another explanation and easier fix !

More generally, if it ran into a redirect (like requesting the root of a webapp maybe) or anything besides the upgrade response really, I don't think anything is supported. Did I miss something ? I don't think support is mandatory (should connect directly to a websocket URL, and it is not required to be a full client).
Comment 4 Remy Maucherat 2015-03-26 15:39:20 UTC
The empty path in the request line is fixed in r1669353 in trunk, but I also verified that the websocket client cannot handle anything other than an upgrade response, so the same test adapted to a webapp root will fail to process the redirect response.

I don't think it is required that the websocket client is a competent HTTP client, so maybe this bz can be transformed into a more generic enhancement.

I don't think the fix is very useful "standalone" without client enhancements so no plan for porting it.
Comment 5 Mark Thomas 2015-03-26 21:01:15 UTC
I haven't seen any demand (yet) for handling a redirect. Lets cross that bridge if we come to it.

I've backported your fix to 8.0.x (for 8.0.22 onwards) and 7.0.x (for 7.0.61 onwards).