2

I'm currently experiencing this odd behaviour with WebSockets in JavaScript, which I can't figure out a reason for and which is driving me nuts. I hope that someone here can help me to find out what exactly is happening.

The scenario is as follows:

I have a Java application with a web server (io.Undertow), which provides a connecting client (in this case Chrome or Firefox) with the required resources via HTTP. The client then opens a WebSocket connection (native JavaScript Websocket API of the respective browser) to the server, which initiates a new WebSocket session (javax.websocket.Session) for the communication. Then in case of some certain events the server notifies the connected client about these events with one message per event via the mentioned WebSocket connection. So far so good...

The problem:

When such an event occurs after the (re-)establishment of the WebSocket connection, the server correctly sends the message as expected, but the client (both Chrome and Firefox) seems to somehow buffer the incoming messages and does not fire the onMessage event of the WebSocket API until a total data amount of 8187 bytes has been received. (Besides: This is a strange number in my opinion; am I missing some header bytes here?) When this point is reached suddenly all received messages are processed at once and the onMessage event is fired for all of them at the same time. After that the connection works fine and the onMessage event is fired for every single event.

Another thing to mention: This problem does not occur on the systems of two of my colleagues; on their systems the events are fired correctly from the very beginning. So it has to be something specific to my system.

Does anyone have any idea why this is happening on my system? Is there any system, firewall, browser, other setting that could influence the browser in such a way?

Headers as provided by Chrome:

Request Headers:

Request URL:ws://127.0.0.1:8080/events
Request Method:GET
Status Code:101 Switching Protocols
Accept-Encoding:gzip, deflate, sdch
Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:no-cache
Connection:Upgrade
Cookie:JSESSIONID=...
Host:127.0.0.1:8080
Origin:http://127.0.0.1:8080
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
Sec-WebSocket-Key:...
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.101 Safari/537.36

Response Headers:

Connection:Upgrade
Content-Length:0
Date:Fri, 27 Mar 2015 09:55:01 GMT
Origin:http://127.0.0.1:8080
Sec-WebSocket-Accept:...
Sec-WebSocket-Location:ws://127.0.0.1:8080/events
Set-Cookie:JSESSIONID=...; path=/
Upgrade:WebSocket

Version Information:

  • Chrome Version: 41.0.2272.101 m
  • Firefox Version: 36.0.1
  • Operating System: Windows 8.1 Pro
  • OS of Colleagues: Windows 8.1 Pro / Linux Ubuntu GNOME 14.04.1

Thanks in advance for any advice.

Chris

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
W64BugBear
  • 81
  • 1
  • 6
  • Can't give a definite answer, but it is absolutely possible that a misconfigured proxy would buffer the reply, treating it like a static resource. It certainly happens with HTTP event-streams. Can you dump the TCP trafic to see when your machine is receiving the messages? – Touffy Mar 27 '15 at 11:07
  • @Touffy: As I'm currently running everything on the same machine for testing purposes the clients connect to the server via localhost. I used RawCap to capture the traffic on localhost while I triggered some events until the WebSocket fires the onMessage event. I uploaded the file here: [localhost.pcap](https://drive.google.com/file/d/0ByM1m2rdwFCOWUhySWlnbTdTUWc/view?usp=sharing) As far as I can see there is no significantly large chunk of data in the capture. Additionally I can observe a change for every single event in Chrome's network timeline for the request. – W64BugBear Mar 27 '15 at 12:48
  • @Touffy: ... So it seems to me that every single event is sent and also received separately, but somehow the request is not considered to be finished and therefore the onMessage event is not fired. – W64BugBear Mar 27 '15 at 12:50
  • Strange indeed. Does your server maybe specify a custom framing protocol and forget to re-specify it? When the client reconnects, does it think it's still the same connection? – Touffy Mar 27 '15 at 13:11
  • Strange... To narrow possible causes down, update Undertow to the latest one and test again with other server like Jetty or Tomcat (Node.js if you can do that to check if it is related to JVM). Also you may want to allow protocol extensions listed in handshake request and test it with non-browser client like Node.js as well as Jetty. – Donghwan Kim Mar 28 '15 at 06:13

0 Answers0