Catching the error: "WebSocket is closed before the connection is established."

8,863 views
Skip to first unread message

Micheil Smith

unread,
Oct 24, 2011, 6:05:43 PM10/24/11
to Chromium HTML5
Hi all,

I've noticed that in most recent Chrome releases (dev and main
channel), if you close a websocket connection before it has handshaked
then you get an error in the javascript console which cannot be caught
by any means.

I work for Pusher.com, and as I'm providing to my users with a
JavaScript library on top of the websocket object, it's kind of
annoying if the user sees this error when we are deliberately closing
the connection. In the Pusher JavaScript, we try to establish a
connection in the following fashion:

1. Try to connect using standard websockets (not over TLS), within
2000 milliseconds
2. If we do not get the "onopen" event on the WebSocket object in
that time frame, then:
2a. We close that websocket connection (this produces the error).
2b. We try to reconnect with different connection parameters
(toggling tls, and increasing timeouts).

I've got a test case that shows this error: https://gist.github.com/1310463

I would expect that I would be able to catch and prevent this error
some how, or that it should be logged as a 'warning' type, instead of
an 'error' type.

– Micheil

Support Remote

unread,
Oct 25, 2011, 2:46:04 PM10/25/11
to Chromium HTML5
Hi Micheil,

You can try null the onopen, onmessage, onclose handler before you
close the WebSocket. I got same error and it's gone after doing this.
Not really sure if that worked, but you can give it a try.

Walter

Micheil Smith

unread,
Oct 26, 2011, 6:26:48 AM10/26/11
to Micheil Smith, Chromium HTML5
I'm updating the gist mentioned, but you can get the original gist here:

https://gist.github.com/1310463/344d83a8bb9a325a4c28a477c1bb8624303539c7

– Micheil

Micheil Smith

unread,
Oct 26, 2011, 6:27:05 AM10/26/11
to Chromium HTML5
Hi Walter,

I just tried this, and it doesn't remove the error for me in Chrome
Canary 17.0.918.0.

See: https://gist.github.com/1310463/87b9cc4814a3408526b0124be7472837f2f20faa

Do you have some example code if this works for you?

Regards,
Micheil Smith
--
Pusher.com

> --
> You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.
> To post to this group, send email to chromiu...@chromium.org.
> To unsubscribe from this group, send email to chromium-html...@chromium.org.
> For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.
>

Yuta Kitamura

unread,
Oct 27, 2011, 3:27:26 AM10/27/11
to Micheil Smith, Chromium HTML5, Takeshi Yoshino, Takashi Toyoshima
Hi Micheil,

I'm a developer of WebSocket in Chromium/WebKit. Let me clarify some of your point:

On Tue, Oct 25, 2011 at 7:05 AM, Micheil Smith <micheil...@gmail.com> wrote:
Hi all,

I've noticed that in most recent Chrome releases (dev and main
channel), if you close a websocket connection before it has handshaked
then you get an error in the javascript console which cannot be caught
by any means.

The error message you got is provided for informational purposes only (same as console.error("foobar")). Scripts cannot (and should not) get any information about these messages, and these messages do not affect script execution. Thus you can safely ignore these messages if you are intentionally closing the socket before onopen().

 
(snip)


I would expect that I would be able to catch and prevent this error
some how, or that it should be logged as a 'warning' type, instead of
an 'error' type.

I agree that these error messages may be too noisy.

Technically speaking, Chromium always emits an error message to JS console when it has to "Fail the WebSocket Connection" (terminology defined in WebSocket protocol draft spec). Many events, such as protocol violation, can fail the connnection, and your case is one of them. However, it looks like your case is different from other cases: scripts can invoke the connection failure *intentionally*.

So, in this case, I think it makes sense to convert this message to a warning (I don't want to remove the message though). I'm going to work on fixing this.

Thank you for your report.

Regards,
Yuta

Yuta Kitamura

unread,
Oct 27, 2011, 3:45:21 AM10/27/11
to Micheil Smith, Chromium HTML5, Takeshi Yoshino, Takashi Toyoshima
On Thu, Oct 27, 2011 at 4:27 PM, Yuta Kitamura <yu...@chromium.org> wrote:

So, in this case, I think it makes sense to convert this message to a warning (I don't want to remove the message though). I'm going to work on fixing this.

PhistucK

unread,
Oct 27, 2011, 3:52:27 AM10/27/11
to Yuta Kitamura, Pavel Feldman, Micheil Smith, Chromium HTML5, Takeshi Yoshino, Takashi Toyoshima
I think this should go into the "Log XMLHttpRequests" bucket (right click on the console and it will show that option).
Maybe change its name to "Log network request states" (or any better name you can imagine). I would add any AppCache logs to that bucket, as well (they are currently always shown as well, look at Angry Birds, over 500 log messages of resource loading).
Or maybe create multiple context menu options for every such feature (sounds like an overkill, unless there are only three or four, but it does not really scale).
That way you can disable these messages (some or altogether) when they are irrelevant to you.
This console dirt/noise hinders debugging when it is not relevant.

PhistucK



--

Micheil Smith

unread,
Oct 27, 2011, 8:25:37 AM10/27/11
to Yuta Kitamura, Micheil Smith, Chromium HTML5, Takeshi Yoshino, Takashi Toyoshima
Okay, Awesome stuff Yuta, I had a look in the code to it, but couldn't really work it out.

Regards,
Micheil Smith
--
Pusher.com

Reply all
Reply to author
Forward
0 new messages