Reputation: 4836
I created and tested a Java EE 7 application that uses WebSockets on my local PC. All works fine when I deploy to WildFly 8 on my local machine, and access the application using localhost.
When I deploy the same application on a cloud server, (Ubuntu 14.04) with exactly the same WildFly configuration, I get the following message when the application tries to connect:
"NetworkError: 404 Not Found - http://178.11.11.11:8080/pss/ws/notification"
Firefox can't establish a connection to the server at ws://178.11.11.11:8080/pss/ws/notification.
I can access the application, it is just the websocket connection that fails.
pss is my context root, and the websocket end point is annotated with @ServerEndpoint("/ws/notification"), so the URL is correct and works 100% on my local machine using localhost.
When I deploy the application I can see that the websocket endpoint has been picked up by WildFly, so this is not the issue
2015-02-14 14:18:21,200 INFO [io.undertow.websockets.jsr] (MSC service thread 1-2) UT026003: Adding annotated server endpoint class za.co.ssms.interfaces.websocket.NotificationWebSocket for path /ws/notification
The request headers are correct:
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Cache-Control no-cache
Connection keep-alive, Upgrade
Cookie JSESSIONID=mgFhI1MAZwT2NwULXDXgEaXt.app
Host 178.11.11.11:8080
Origin http://178.11.11.11:8080
Pragma no-cache
Sec-WebSocket-Key LD55xYAKjJoXgLXQpUS7fA==
Sec-WebSocket-Version 13
Upgrade websocket
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:35.0) Gecko/20100101 Firefox/35.0
I am accessing the application using the following URL (IP modified), and the ports match:
http://178.11.11.11:8080/pss/
If I run netstat -an | grep 'LISTEN' on my cloud server I get the following, which shows that 0.0.0.0:8080 is bound and listening:
tcp 0 0 127.0.0.1:9990 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3528 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8787 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
unix 2 [ ACC ] STREAM LISTENING 9227 /var/run/acpid.socket
unix 2 [ ACC ] STREAM LISTENING 7014 @/com/ubuntu/upstart
unix 2 [ ACC ] STREAM LISTENING 8907 /var/run/dbus/system_bus_socket
unix 2 [ ACC ] STREAM LISTENING 9448 /var/run/mysqld/mysqld.sock
unix 2 [ ACC ] SEQPACKET LISTENING 7666 /run/udev/control
My public interface is configured as shown below:
<interface name="public">
<inet-address value="${jboss.bind.address:0.0.0.0}"/>
</interface>
Apache is not installed so this is a direct connection to Wildfly server.
After several days I am pretty stumped as to why this is failing.
Has any body experienced this before and have a solution, or do you have a way to toubleshoot this further.
Thanks
Upvotes: 3
Views: 3240
Reputation: 441
I had similar issues.
but any http upgrade requests fail with a 404. The same call works when WildFly and the browser is on the same machine
Reason for working is not necessarily because of been on the same machine, tested by connecting to a colleague's machine on the same network, the connection worked.
How I solved my issue:
I did a tcpdump on the server and noticed that the traffic was missing the Upgrade http header, but this was not the case when i connected via a different network (cellphone hotspot tethering).
Bad connection dump:
GET /websocket/api/alert HTTP/1.0
Host: www.example.co.za
Pragma: no-cache
Origin: http://www.example.co.za
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: JSESSIONID=biPOHuOQGRlw59eDqH4nevzt.mpilotech2
Sec-WebSocket-Key: U7f+gZQLqFLX18x6vB+i1Q==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Via: 1.1 localhost (squid/3.0.STABLE19)
X-Forwarded-For: 10.1.1.148
Cache-Control: no-cache, max-age=259200
Connection: keep-alive
HTTP/1.1 404 Not Found
Server: nginx/1.8.0
Date: Wed, 06 May 2015 08:29:05 GMT
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: http://www.example.co.za
Vary: Origin
X-Powered-By: Undertow/1
Access-Control-Allow-Credentials: true
Good Connection dump:
GET /websocket/api/alert HTTP/1.1
Host: www.example.co.za
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://www.example.co.za
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: JSESSIONID=biPOHuOQGRlw59eDqH4nevzt.mpilotech2
Sec-WebSocket-Key: xY36TVE76RzHujuFljtq/w==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
HTTP/1.1 101 Switching Protocols
Server: nginx/1.8.0
Date: Wed, 06 May 2015 08:31:19 GMT
Content-Length: 0
Connection: upgrade
X-Powered-By: Undertow/1
Origin: http://www.example.co.za
Upgrade: WebSocket
Sec-WebSocket-Accept: sxwgjN1BONLj5U5Kjh80fjQWBo4=
Access-Control-Allow-Origin: http://www.example.co.za
Vary: Origin
Sec-WebSocket-Location: ws://127.0.0.1:8180/websocket/api/alert
Access-Control-Allow-Credentials: true
Then i noticed that the failing connection goes through a squid 3 proxy server, reading around on the web revealed that the proxy server does not support websocket.
My temp solution was to create a self signed certificate and switch to using wss which i terminate on my reverse proxy instead of ws for the connection.
Instructions for creating the certificate: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificate-on-nginx-for-ubuntu-14-04
You dont have to be using ubuntu, i use CentOS, most of the instructions are still the same.
Hope that will save someone some hours
Upvotes: 1