Question

I saw a report of similar failure here: https://groups.google.com/forum/?fromgroups=#!topic/sockjs/QNtA1_p_arU, but my problem seems to be different.

My setup: clients connects to https://www.mysite.com/sockjs for SockJS, and the actual page is served at https://www.mysite.com/blah/blah/blah. All external elements on the page (e.g. css and js) are served with https, including SockJS-Client (https://d1fxtkz8shb9d2.cloudfront.net/sockjs-0.3.js, which should be 0.3.4 for the latest release). The backend is made with SockJS-Tornado.

Problem 1: I specify the following protocols to use:

var options = {protocols_whitelist: ["websocket", "xhr-streaming", "xdr-streaming", "xhr-polling", "xdr-polling", "iframe-htmlfile", "iframe-eventsource", "iframe-xhr-polling"], debug: true};             
conn = new SockJS("https://www.mysite.com/sockjs", options);

However, it seems that IE9 simply uses the worst-possible protocol iframe-htmlfile, as I see the following in the server log:

INFO:root:200 GET /sockjs/info?t=1353062888578 (127.0.0.1) 0.51ms
INFO:root:200 GET /sockjs/iframe.html (127.0.0.1) 22.21ms

Why doesn’t it use xdr-streaming or xdr-polling? In SockJS doc, it labels these two protocols under ‘IE8, 9 (cookies=no)’, does this mean that SockJS will only use them when the cookies are disabled for the browser?

Problem 2: with the use of protocol iframe-htmlfile, the user will get a 'Only Secure Content is Displayed' warning on the page, which signals a mixed content problem. However, none of other tested browsers reports this warning (e.g. Chrome, FireFox, Safari), and as mentioned before, every external resource on the page is served through https. Why is this? Is it related to this specific protocol iframe-htmlfile used?

At the same time, SockJS struggles to connect to the server and send msgs. This is what I see in the server log:

INFO:root:200 GET /sockjs/info?t=1353062888578 (127.0.0.1) 0.51ms
INFO:root:200 GET /sockjs/iframe.html (127.0.0.1) 22.21ms
INFO:root:200 GET /sockjs/info?t=1353062922712 (127.0.0.1) 0.39ms
connection openned for: 127.0.0.1
INFO:root:200 GET /sockjs/info?t=1353062963868 (127.0.0.1) 0.36ms
WARNING:root:Read error on 12: [Errno 104] Connection reset by peer
WARNING:root:error on read
Traceback (most recent call last):
  File "/home/ml/envs/.virtualenvs/sockapp/local/lib/python2.7/site-packages/tornado/iostream.py", line 355, in _handle_read
    if self._read_to_buffer() == 0:
  File "/home/ml/envs/.virtualenvs/sockapp/local/lib/python2.7/site-packages/tornado/iostream.py", line 422, in _read_to_buffer
    chunk = self._read_from_socket()
  File "/home/ml/envs/.virtualenvs/sockapp/local/lib/python2.7/site-packages/tornado/iostream.py", line 403, in _read_from_socket
    chunk = self.socket.recv(self.read_chunk_size)
error: [Errno 104] Connection reset by peer
subject disconnection from: None
Message handled in: 0 ms
INFO:root:200 GET /sockjs/369/rpf1d1vl/htmlfile?c=_jp.aepnvri (127.0.0.1) 60006.30ms

The last error seems to be a timeout. The connection appears to open when I dismiss the warning dialog in IE9, but afterwards no msg is received from the browser (the browser should send a msg as soon as the connection is open). I wonder if this is related to the mixed content warning before.

Answer 1

I think we were able to identify your problems on SockJS mailing list. Quick recap:

Problem 1 – Your server required client to only use transport that do cookies (for load balancing reasons), that means XDR based transport can’t be used (XDR can’t do cookies).

Problem 2 – you forgot to set sockjs_url parameter on the server side, to include sockjs javascript from https (and not http). That’s why you had mixed content warnings.