Subject: [hybi] Yet more additional WebSocket Close Error Codes

From: Jason Duell <[email-masked]>
Date: Thu, 17 May 2012 21:20:04 -0700

I'm wondering if there are two more close codes that would be useful,
to indicate

  1) remote server not reachable

  2) client/browser has too many websockets open already (try later)

Re: #1: Both Web Socket specs are a little vague IMO on how JS is
notified when the targeted web socket server is down/nonexistent/etc.

Firefox is firing an 'error' event when this happens, based AFAICT on
the language here in the W3C spec:

  "if the status code received from the server is not 101 (e.g. it is
a redirect), the user agent must fail the websocket connection"

Chrome is not calling onerror for this, so we have a difference here.
The language in the spec isn't really clear if this covers the
connection-never-happened case.

Both Chrome and Firefox (haven't tested other browsers/clients) are
then calling close with code=1006, which seems the best code available
in RFC 6455, but the language there isn't great either:

   "to indicate that the connection was closed abnormally, e.g.,
without sending or receiving a Close control frame."

Of course the connection wasn't actually "closed" at all, normally or
not. There's essentially no mention in either spec of what happens
when there never was any connection to the server..

It would be useful to be clear about whether onerror should be called
here.   I'm also wondering if it would be useful to have a dedicated
error code for this case ("server not available').

Re: #2: I expect every browser that implements websockets will have
some limit on the number of websockets it allows to be open at once
(to prevent DoS attacks if nothing else).    I'm not sure of what the
right close code for this is.  Ideas?  Perhaps we could also use a
dedicated code for this case too.

Jason Duell
Mozilla

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 May 2012 12:54:33 +0200

> a redirect), the user agent must fail the websocket connection"

Well, no status code was received at all; so this doesn't seem to help :-)

> connection-never-happened case.

I think it is; but I agree that the behavior for the other case should 
be specified at all.

> ...

Anyway; I think this should be raised as a WSAPI problem.

Best regards, Julian

---

From: Jason Duell <[email-masked]>
Date: Fri, 18 May 2012 14:53:45 -0700

> I think it is;

So you think the behavior for "server not available" is clear in the
spec?  Which flavor (call onerror or not)?

> but I agree that the behavior for the other case should be
> specified at all.

I couldn't quite parse this either.   Is that support (or the
opposite) for a code for "too many websockets open", or something
else?

> Anyway; I think this should be raised as a WSAPI problem.

Yes, most of the wordsmithing needs to happen there  (and as soon as
their mail server starts accepting my mail I'll have a post about this
there).   But the list of close codes (including pseudo-codes that
never go on the net) has so far been maintained more on this list, so
I figured I'd ask here too.

best,

Jason

---

From: Jason Duell <[email-masked]>
Date: Fri, 18 May 2012 16:36:01 -0700

>>> connection-never-happened case.

Perhaps you were referring to

"If the establish a WebSocket connection algorithm fails, it triggers
the fail the WebSocket connection algorithm, which then invokes the
close the WebSocket connection algorithm."

That clearly implies onerror should be called when the remote server
connection fails.

It looks like Chromium is going to change to call onerror here too:

  http://code.google.com/p/chromium/issues/detail?id=128057

But: I still don't see any clear language in either spec on what error
code should be used, and think that this is a common enough case to
merit it's own code, or at least clearer language that 1006 should be
used.

Jason

---

From: Julian Reschke <[email-masked]>
Date: Sat, 19 May 2012 10:38:09 +0200

> spec?  Which flavor (call onerror or not)?

I think it is clear in that it talks about a response code, so does not 
deal with the case you are referring to.

> opposite) for a code for "too many websockets open", or something

It's support for defining the API behavior for connection problems.

> I figured I'd ask here too.

Agreed.

Best regards, Julian