[hybi] Yet more additional WebSocket Close Error Codes

Jason Duell <jduell.mcbugs@gmail.com> Fri, 18 May 2012 04:20 UTC

Return-Path: <jduell.mcbugs@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2C621F86A3 for <hybi@ietfa.amsl.com>; Thu, 17 May 2012 21:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIT7KNf2Yhn6 for <hybi@ietfa.amsl.com>; Thu, 17 May 2012 21:20:25 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D98C21F860D for <hybi@ietf.org>; Thu, 17 May 2012 21:20:25 -0700 (PDT)
Received: by qadz3 with SMTP id z3so6197258qad.10 for <hybi@ietf.org>; Thu, 17 May 2012 21:20:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=dVM9vCLP5D94eZF9WadMaN4GtGR1UDL49vheRoc4Y7w=; b=xMOygBtkoqGQtfNQI+xWCLfxHND6eZeUXiBhmFrrlkX/mVEU4ogf7HJoX9DsC4ApHk fXV7OPqKOlUsxG+wpNryqMxw7Pfkw6J4tAg+rZvprbeRTAI7HrdnQM6og9w4xQMcE+bQ YydPxGok7RwBOzGmRoCZ6a+FqGwLMIOhztibXRDlG690u5MrGvXmN+FLkc4Jv0scafzo UQeRzcoH0rJJ6eqfGbN/BZ1lkEshbbU6pGhUbVdTxbamdSbTD4g3JxP9DjwugUiYPWnL lMZQCx0KAHBIAXaU5hMONaA8vQI1nit7wk7IMoWCGAkhdfwVIdBkD1eDp9wfJMET0E+Z zb0A==
Received: by 10.229.173.103 with SMTP id o39mr4656466qcz.111.1337314824693; Thu, 17 May 2012 21:20:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.198.26 with HTTP; Thu, 17 May 2012 21:20:04 -0700 (PDT)
From: Jason Duell <jduell.mcbugs@gmail.com>
Date: Thu, 17 May 2012 21:20:04 -0700
Message-ID: <CAM6mnzJQTLxztd+6CTugRoONKiHNn-MDTJutPBoCtFUNnfBohQ@mail.gmail.com>
To: hybi@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [hybi] Yet more additional WebSocket Close Error Codes
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 May 2012 04:20:25 -0000

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