Subject: [hybi] Treatment of invalid close status codes by browser

From: Adam Rice <[email-masked]>
Date: Thu, 15 Aug 2013 13:49:17 +0900

I was interested in the handling of invalid status codes sent by the server
to the browser, so I did some investigation. I am posting my results here
in case anyone finds them useful.

My methodology was simple: I used a pywebsocket server configured to
respond to any message by closing the connection with the status code in
the payload of the message, and then manually tested a range of browsers.
All tested browsers were on Windows 7, except for Mac Safari.

The behaviour for status codes blocked by the browser was consistent across
all browsers: they reported status code 1006 with an empty reason string to
Javascript.

Firefox and Mac Safari block no status codes at all. Chrome and Opera block
codes 1005 (no status code provided) and 1015 (TLS error). IE also blocks
these codes, and also blocks codes <1000 and between 1015 and 1999
inclusive. No tested browser blocks any status code >=2000, up to and
including 65535. All tested browsers correctly treat status codes as
unsigned.

I have included a table summarising my results below. If it appears mangled
in your email client, you can view it at
https://docs.google.com/a/chromium.org/spreadsheet/pub?key=0AuDUFVM2fijadEJETlozbDZ1a2FldnFwZEYybzhZMGc

Thanks,
Adam Rice

BrowserVersion testedCode on network09991005100610151999499965535Chrome
27.0.1453.116
Javascript CloseEvent.code
09991006100610061999499965535Firefox2209991005100610151999499965535IE
10.0.9200.16618100610061006100610061006499965535Opera15.0.1147.13009991006
100610061999499965535Safari5.1.7 (7534.57.2)Not availableSafari (Mac)6.0.5
(8536.30.1)09991005100610151999499965535

---

From: Joakim Erdfelt <[email-masked]>
Date: Thu, 15 Aug 2013 05:20:12 -0700

Safari 5.x's websocket implementation is the Hixie-76 draft implementation.
 Very old.
Not worth including in this testing.

Status Code 1005 (No Status Code Provided), and Status Code 1015 (TLS
error) are not allowed to be sent over the network per spec.
Chrome and Opera are following the letter of the spec.  The other browsers
are not.
I would even say that pywebsocket has a bug if it even allows you to send
status code 1005 or 1015 over the wire.

Note, the autobahn protocol tests include all of these status code tests
and a few dozen more.

Also, did you test the 2 close codes that were added to the IANA registry
(after RFC6455 was finalized?)
https://www.iana.org/assignments/websocket/websocket.xhtml#close-code-number
1012 (Service Restart)
1013 (Try Again Later)

--
Joakim Erdfelt <[email-masked]>
webtide.com <http://www.webtide.com/> - intalio.com/jetty
Expert advice, services and support from from the Jetty & CometD experts
eclipse.org/jetty - cometd.org

On Wed, Aug 14, 2013 at 9:49 PM, Adam Rice <[email-masked]> wrote:

> I was interested in the handling of invalid status codes sent by the
> server to the browser, so I did some investigation. I am posting my results
> here in case anyone finds them useful.
>
> The behaviour for status codes blocked by the browser was consistent
> across all browsers: they reported status code 1006 with an empty reason
> string to Javascript.
>
> Firefox and Mac Safari block no status codes at all. Chrome and Opera
> block codes 1005 (no status code provided) and 1015 (TLS error). IE also
> blocks these codes, and also blocks codes <1000 and between 1015 and 1999
> I have included a table summarising my results below. If it appears
> mangled in your email client, you can view it at
> Browser Version tested Code on network 0 999 1005 1006 1015 1999 499965535Chrome27.0.1453.116
> 0 999 1006 1006 1006 1999 4999 65535 Firefox 22 0 999 1005 1006 1015 1999499965535IE10.0.9200.16618100610061006100610061006499965535Opera15.0.1147.13009991006100610061999499965535Safari5.1.7 (7534.57.2)Not availableSafari (Mac)6.0.5 (8536.30.1)09991005100610151999499965535
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 21 Aug 2013 15:36:27 +0900

> Chrome and Opera are following the letter of the spec.  The other browsers

Yes. I think it's fine to handle such input as error and return 1006 to app.

I think:
- 0-999 and 5000-65535: should be handled as error
- not-yet-defined ones in 1000-2999 range: it's ok either to pass through
them to app or convert them into 1006 (update to accept when registered
with IANA)
- 3000-4999: should be passed to app as-is

> status code 1005 or 1015 over the wire.

pywebsocket raises an exception for such code. Adam used modified one.

> Note, the autobahn protocol tests include all of these status code tests
Thanks. Chrome, Firefox and IE are covered by Section 7.
http://autobahn.ws/testsuite/reports/clients/index.html

> https://www.iana.org/assignments/websocket/websocket.xhtml#close-code-number
Oh. We should accept them.