This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The code argument to the close() method [1] should be an unsigned short to match the protocol spec [2]. This should also be reflected in the CloseEvent [3]. The protocol document says: If there is a body, the first two bytes of the body MUST be a 2-byte integer (in network byte order) representing a status code defined in Section 7.4. [1] http://dev.w3.org/html5/websockets/#the-websocket-interface [2] http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#section-4.5.1 [3] http://dev.w3.org/html5/websockets/#closeevent
Why should 65535 throw INVALID_ACCESS_ERR but 66535 send the code 1000? I guess one could ask the same of why 4294967295 should throw INVALID_ACCESS_ERR when 4294968295 sends the code 1000... Maybe the solution is to add [Clamp] to the interface. I've changed it to 'unsigned short' with [Clamp]. cc'ing heycam for sanity check. (Note that this makes the CloseEvent interface less useful, since anyone reusing it now is limited to 2**16 codes instead of 2**32, but I guess that's not a big deal.)
Checked in as WHATWG revision r6268. Check-in comment: WebSocket close code can fit in an unsigned short, so use that instead. http://html5.org/tools/web-apps-tracker?from=6267&to=6268
(Not being overly familiar with the Web Sockets protocol: is the 2-byte integer closing code meant to be signed or unsigned? All other instances of the word "integer" in the Internet-Draft are prefaced with "unsigned", so does that mean the bare "integer" for the code means it is signed?) I introduced [Clamp] in Web IDL to resolve the situation where for compatibility reasons, the way that JS Number values are converted into octets on CanvasPixelArray needed to be different from the default. I don't see why close() needs different conversion behaviour from the default that Web IDL uses.
Bug in the protocol. It should say "unsigned" in the protocol. I will fix that.