Getting 404 on WebSocket when deploying on my Server

[Christian Wansart]

Hey there,

I programmed a WebSocket in Java, which works fine on my local Tomcat 7 server when running inside of Eclipse. But after deploying on my Server it doesn't work anymore. I've just programmed a little test application which without any other code in it. Same result: works on my local Tomcat but not on my Server.

This is what I get when running in my Firefox console:

new WebSocket('ws://myServer:8080/wsock/chat');
WebSocket { url: "ws://myServer:8080/wsock/chat", readyState: 0, bufferedAmount: 0, onopen: null,
 onerror: null, onclose: null, extensions: "", protocol: "", onmessage: null, binaryType: "blob" }
Firefox can't establish a connection to the server at ws://myServer:8080/wsock/chat

I have really no Idea what to do now. I read many threads on Stackoverflow, here and other boards but nothing helped.
The Tomcat version on the server is 7.0.56. I couldn't attach the .war nor the .java file, so here you go:

package wsock;

import javax.websocket.OnClose;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;

@ServerEndpoint("/chat")
public class ChatServer {
	@OnOpen
	public void onOpen(Session session) {
		System.err.println("Opened session: " + session.getId());
	}
	
	@OnClose
	public void onClose(Session session) {
		System.err.println("Closed session: " + session.getId());
	}
	
	@OnMessage
	public String onMessage(String message) {
		System.err.println("Message received: " + message);
		return "{ \"message\": \"Hello World\" }";
	}
}

Any ideas? :-)

[L Foster]

First, are you sure that's a 404? 404 is about not finding something on a server, once communication has been established. Your Firefox message is claiming there was no contact at all. You might also try hitting a page known to be on 'myserver:8080' directly from the Firefox URL input, if you have not already. That would eliminate this having to do with the hostname you are using, and port.

[Christian Wansart]

Yes, I am sure. I checked the package using Firefox' analyze tool. The interesting thing was, that it wasn't send to ws:// but to http:// instead. When I try to access http://myServer:8080/wsock/chat I get a 404 error page by Tomcat. So I guess that Java or Tomcat is redirecting those WebSocket messages on my local machine. (But that's only an assumption.)

[Karthik Shiraly]

Christian Wansart wrote:The interesting thing was, that it wasn't send to ws:// but to http:// instead. When I try to access http://myServer:8080/wsock/chat I get a 404 error page by Tomcat. So I guess that Java or Tomcat is redirecting those WebSocket messages on my local machine. (But that's only an assumption.)

Every WS handshake starts off as a normal HTTP request to the same URL, with an additional "Upgrade to websocket header". If the server is capable of doing so, it'll return the same header with HTTP 101. If not, you get 404.
Check in Firefox Dev tools network tab if the response header from remote server sent "Upgrade:websocket". If not, it's probably a Tomcat configuration problem.

[Christian Wansart]

It seems that you're right. This is the header that was sent to the server:

Host: 192.168.2.103:8888
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Sec-WebSocket-Version: 13
Origin: http://192.168.2.103:8888
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: YYZq2+qBTCFZi1kRHI5Z+A==
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

and this is what it returned:

Content-Language: en
Content-Length: 1005
Content-Type: text/html;charset=utf-8
Date: Fri, 01 Jan 2016 02:39:11 GMT
Server: Apache-Coyote/1.1

This is very interesting, but what setting could be missing? If you know please let me know. I'm going to work through some documentation.

[Paul Clapham]

You got 1005 bytes in the response, it says in one of the headers, so it might be interesting to look at them. Perhaps you aren't missing anything.

[Karthik Shiraly]

A successful WS handshake shouldn't contain a "content-type" response header. So I suppose the response here is the standard 404 resource not found tomcat page, which OP should verify from dev tools response tab.

I don't know exactly what the misconfiguration here, because WS usually works out of the box and version 7.0.56 is fairly recent.
So just a checklist below which you can run through:

1) The URLs changed as this discussion progressed, making it a bit confusing.
Since this is a 404 error, first thing to verify is that all the actual URLs in code and deployment are correct, even if they were typed differently in these posts.
From the Origin header, I believe your page and its javascript code is served from "http://192.168.2.103:8888", which suggests it's the ROOT webapp on server.
From the first post, it looks like WS URL is "ws://myServer:8080/wsock/chat". Assuming "myServer:8080" is actually "http://192.168.2.103:8888", it means you have the WS servlet deployed in a second web app called wsock.war.
Is this the case?

2) Deploying to Tomcat from Eclipse is usually rather misleading because Eclipse makes a temp copy of the selected server's files and deploys in the copy.
What you want to do is make a WAR and deploy that on the standalone Tomcat. I suppose that's exactly what you're doing here, but just something to remember.

3) Check that "tomcat7-websocket.jar" and "websocket-api.jar" are in Tomcat server's lib directory.
That's usually "/usr/share/tomcat7/lib" in GNU/Linux distros, or TOMCAT_DIR/lib in Windows.

4) Ensure that your WAR's WEB-INF/lib does not have any of the standard Tomcat JARs like "servlet-api.jar", "tomcat*.jars", or "websocket-api.jar".

5) Finally, check the logs. Look for successful deployment of the WAR containing the WS servlet.

That's all I can think of for now.

[Karthik Shiraly]

I've moved this to the Tomcat forum, since it seems better suited.

[Christian Wansart]

Second Edit It's not fixed. I downloaded and unpacked the current tomcat 7 from Apache and run it:

ws = new WebSocket('ws://192.168.2.103:8080/wsock/chat');
WebSocket { url: "ws://192.168.2.103:8080/wsock/chat", readyState: 0, bufferedAmount: 0, onopen: null, 
onerror: null, onclose: null, extensions: "", protocol: "", onmessage: null, binaryType: "blob" }
Firefox kann keine Verbindung zu dem Server unter ws://192.168.2.103:8080/wsock/chat aufbauen.

"Firefox kann keine Verbindung zu dem Server unter ws://192.168.2.103:8080/wsock/chat aufbauen" means that it can't connect to the address.

------------------------------------

EDIT I guess we found the answer. Thanks for your help. I assumed that the tomcat7 package from the repos would work -- I'v been proven otherwise!
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787220 <-- this is what I found when I wanted to report this bug.


------------------------------------ old answer

Karthik Shiraly wrote:A successful WS handshake shouldn't contain a "content-type" response header. So I suppose the response here is the standard 404 resource not found tomcat page, which OP should verify from dev tools response tab.

I guess you're right, but the response tab is empty. See the attachment. (Anwort means response and Kopfzeilen means headers.)

Karthik Shiraly wrote:1) The URLs changed as this discussion progressed, making it a bit confusing.
Since this is a 404 error, first thing to verify is that all the actual URLs in code and deployment are correct, even if they were typed differently in these posts.

Oh sorry about that. Those are two almost identical programs doing almost the same thing, except that the new one has a JDBC Connection in it. I've ran the test again with my wsock application. You can see the exact same result in wsock2.jpg attachment. The request was:

Host: 192.168.2.103:8888
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Origin: http://192.168.2.103:8888
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: BqCyRdvL0iHKdqW8NRvpKQ==
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

and the response was:

Content-Language: en
Content-Length: 991
Content-Type: text/html;charset=utf-8
Date: Fri, 01 Jan 2016 09:29:12 GMT
Server: Apache-Coyote/1.1

Karthik Shiraly wrote: From the Origin header, I believe your page and its javascript code is served from "http://192.168.2.103:8888", which suggests it's the ROOT webapp on server.
From the first post, it looks like WS URL is "ws://myServer:8080/wsock/chat". Assuming "myServer:8080" is actually "http://192.168.2.103:8888", it means you have the WS servlet deployed in a second web app called wsock.war.
Is this the case?

Very interesting, because as you can see in my third attachment, I typed the full address ws://192.168.2.103:8888/wsock/login.
192.168.2.103 and myServer is the same machine, for the exception that the 8888 is not exposed to the Internet whereas 8080 is.

Karthik Shiraly wrote:2) Deploying to Tomcat from Eclipse is usually rather misleading because Eclipse makes a temp copy of the selected server's files and deploys in the copy.
What you want to do is make a WAR and deploy that on the standalone Tomcat. I suppose that's exactly what you're doing here, but just something to remember.

OK, I'll check that on my local machine by putting the war file in my Tomcat.

Karthik Shiraly wrote:3) Check that "tomcat7-websocket.jar" and "websocket-api.jar" are in Tomcat server's lib directory.
That's usually "/usr/share/tomcat7/lib" in GNU/Linux distros, or TOMCAT_DIR/lib in Windows.

Now THAT's interesting:

/usr/share/tomcat7/lib $ ls -l
insgesamt 0
lrwxrwxrwx 1 root root 44 Mär 28  2015 annotations-api.jar -> ../../java/tomcat-annotations-api-7.0.56.jar
lrwxrwxrwx 1 root root 34 Mär 28  2015 catalina-ant.jar -> ../../java/catalina-ant-7.0.56.jar
lrwxrwxrwx 1 root root 40 Mär 28  2015 catalina-ha.jar -> ../../java/tomcat-catalina-ha-7.0.56.jar
lrwxrwxrwx 1 root root 37 Mär 28  2015 catalina.jar -> ../../java/tomcat-catalina-7.0.56.jar
lrwxrwxrwx 1 root root 48 Mär 28  2015 catalina-jmx-remote.jar -> ../../java/tomcat-catalina-jmx-remote-7.0.56.jar
lrwxrwxrwx 1 root root 37 Mär 28  2015 catalina-tribes.jar -> ../../java/catalina-tribes-7.0.56.jar
lrwxrwxrwx 1 root root 27 Mär 28  2015 commons-dbcp.jar -> ../../java/commons-dbcp.jar
lrwxrwxrwx 1 root root 27 Mär 28  2015 commons-pool.jar -> ../../java/commons-pool.jar
lrwxrwxrwx 1 root root 32 Mär 28  2015 el-api.jar -> ../../java/tomcat-el-api-2.2.jar
lrwxrwxrwx 1 root root 38 Mär 28  2015 jasper-el.jar -> ../../java/tomcat-jasper-el-7.0.56.jar
lrwxrwxrwx 1 root root 35 Mär 28  2015 jasper.jar -> ../../java/tomcat-jasper-7.0.56.jar
lrwxrwxrwx 1 root root 33 Mär 28  2015 jsp-api.jar -> ../../java/tomcat-jsp-api-2.2.jar
lrwxrwxrwx 1 root root 37 Mär 28  2015 servlet-api.jar -> ../../java/tomcat-servlet-api-3.0.jar
lrwxrwxrwx 1 root root 32 Mär 28  2015 tomcat-api.jar -> ../../java/tomcat-api-7.0.56.jar
lrwxrwxrwx 1 root root 35 Mär 28  2015 tomcat-coyote.jar -> ../../java/tomcat-coyote-7.0.56.jar
lrwxrwxrwx 1 root root 36 Mär 28  2015 tomcat-i18n-es.jar -> ../../java/tomcat-i18n-es-7.0.56.jar
lrwxrwxrwx 1 root root 36 Mär 28  2015 tomcat-i18n-fr.jar -> ../../java/tomcat-i18n-fr-7.0.56.jar
lrwxrwxrwx 1 root root 36 Mär 28  2015 tomcat-i18n-ja.jar -> ../../java/tomcat-i18n-ja-7.0.56.jar
lrwxrwxrwx 1 root root 33 Mär 28  2015 tomcat-jdbc.jar -> ../../java/tomcat-jdbc-7.0.56.jar
lrwxrwxrwx 1 root root 33 Mär 28  2015 tomcat-util.jar -> ../../java/tomcat-util-7.0.56.jar

I installed it from the repos. Interestingly: ../../ only contains folders. There are no jar files. I've checked the tomcat package contents with "dpkg -L tomcat7" and "dpkg -L tomcat7-commen" and those symlinks are the only thing there. in ../../java are the files. I missed the "java" and thought it was pointing to /usr/share/lib. But in /usr/share/java is no websocket jar file. I think I'll contact the maintainer of that package. I ran locate to find all jar files and there are more symlinks but no real files... wtf is going on here? This is by the way raspbian as the operating system.

Karthik Shiraly wrote: 4) Ensure that your WAR's WEB-INF/lib does not have any of the standard Tomcat JARs like "servlet-api.jar", "tomcat*.jars", or "websocket-api.jar".

No, those folders are empty.

Karthik Shiraly wrote:5) Finally, check the logs. Look for successful deployment of the WAR containing the WS servlet.

INFORMATION: Deploying web application archive /var/lib/tomcat7/webapps/wsock.war
Dez 31, 2015 10:19:22 AM org.apache.catalina.startup.HostConfig deployWAR
INFORMATION: Deployment of web application archive /var/lib/tomcat7/webapps/wsock.war has finished in 3,879 ms

I guess the Tomcat 7 package is broken. I'll check if that happens on my local machine with Debian too. (edit: no websocket file either.)

[Karthik Shiraly]

So, if I've understood the sequence right, the summary of what has happened is:

- tomcat7 installed from repos on 192.168.2.103 had missing WS jars.
You've now uninstalled the repo version (to ensure there's no clashes with new version), and replaced it with Tomcat7 downloaded directly from Apache.
I assume you've verified that websocket JARs are actually present in this new version?

- In the new version, wsock.war deployed correctly with no error in logs and listening on both 8080 and 8888 (or are these 2 different Tomcat instances).

- But the WS endpoint "ws://192.168.2.103:8080/wsock/chat"; is still failing.
What is "ws://192.168.2.103:8080/wsock/login"? Is it another endpoint?

- Is the website flow "user opens http://192.168.2.103:8080/wsock/login"; -> then javascript on that page tries to open WS to "ws://192.168.2.103:8080/wsock/chat"; and this fails? (sorry, I'm a bit confused about the URLs here, hence the question)

[Christian Wansart]

Karthik Shiraly wrote:- tomcat7 installed from repos on 192.168.2.103 had missing WS jars.
You've now uninstalled the repo version (to ensure there's no clashes with new version), and replaced it with Tomcat7 downloaded directly from Apache.
I assume you've verified that websocket JARs are actually present in this new version?

Yes, they are present.

Karthik Shiraly wrote:- In the new version, wsock.war deployed correctly with no error in logs and listening on both 8080 and 8888 (or are these 2 different Tomcat instances).

8888 was my prior instance from the repos. 8080 is the new one from Apache. I didn't change the port.

Karthik Shiraly wrote:- But the WS endpoint "ws://192.168.2.103:8080/wsock/chat"; is still failing.
What is "ws://192.168.2.103:8080/wsock/login"? Is it another endpoint?

They are the same. First it was login later it's chat. I wanted to make sure this issn't some keyword or so, that's why I changed it. Now it's only chat. This is the code I am currently working with. There is no other class.

package wsock;
 
import javax.websocket.OnClose;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;
 
@ServerEndpoint("/chat")
public class ChatServer {
    @OnOpen
    public void onOpen(Session session) {
        System.err.println("Opened session: " + session.getId());
    }
     
    @OnClose
    public void onClose(Session session) {
        System.err.println("Closed session: " + session.getId());
    }
     
    @OnMessage
    public String onMessage(String message) {
        System.err.println("Message received: " + message);
        return "{ \"message\": \"Hello World\" }";
    }
}

Karthik Shiraly wrote:- Is the website flow "user opens http://192.168.2.103:8080/wsock/login"; -> then javascript on that page tries to open WS to "ws://192.168.2.103:8080/wsock/chat"; and this fails? (sorry, I'm a bit confused about the URLs here, hence the question)

I do open http://192.168.2.103:8080/wsock, then I open Firefox' console and write "ws = new WebSocket('ws://192.168.2.103:8080/wsock/chat')" to check if the connection works.

Interestingly the WebSocket chat example shipped with Tomcat works! The same host, the same Tomcat instance.

[Karthik Shiraly]

I copied your code into a test WS webapp that I had, and it's working perfectly fine. So problem is not in your java code.
And it's not Tomcat either, as you already have the chat example working.

That leaves only your WAR file.
So another one of those checklists :
- Is there a /webapps/wsock directory in your newly installed tomcat directory?
- Is there a "/webapps/wsock/WEB-INF/web.xml" and "/webapps/wsock/WEB-INF/classes/wsock/ChatServer.class"?
- Is your web.xml <web-app version >= "3.0"> ? Can you put up the web.xml contents here?

[Christian Wansart]

I've just tested it on my Ubuntu Notebook (Java 8): working! Then on my Debian PC (Java 7): not working. My Windows 10 (Java 8) working. Raspberry PI (Java 7): not working. I do see a pattern here.

To my knowledge I build it with Java 8, so that could be the reason? I'll test that now. Also: It does work on your machine!

[Karthik Shiraly]

If the classes were built with Java 8 compiler but deployed on machines with older Java 7 JRE, you should see Unsupported class version error in tomcat logs.

[Christian Wansart]

Karthik Shiraly wrote:If the classes were built with Java 8 compiler but deployed on machines with older Java 7 JRE, you should see Unsupported class version error in tomcat logs.

I didn't see those messages. I probably didn't pay enough attention to this. However, building it with Java 7 made it work! Thank you so much for you time and effort!

[Karthik Shiraly]

You're welcome! Glad to know it's working
I'd never have guessed it was a Java version problem tbh. For some reason, I was under the impression web app deployment would fail if the class version was unsupported. I should test my assumptions.