This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I don't believe the Web socket spec is clear on this: If there is no close 'reason' passed from the server in the protocol (which on a network frame level is different than sending an empty Unicode string), should we set the close event's 'reason' field to 'undefined', or to an empty string? Right now Firefox is setting it to an empty string. Logically, I feel it ought to be 'undefined'. But I don't see much harm in it being an empty string. Either way the spec should be clear about it.
Rather than undefined I think null would be more appropriate. But I'd be ok either way.
> The reason attribute must return the value it was initialized to. > When the object is created, this attribute must be initialized to > empty string. What's unclear? (Except for the missing 'the')
> attribute must be initialized to empty string. Ah, didn't see that. So the spec is clear then--'reason' will never be null/undefined.
I think this is the relevant part "whose reason attribute is initialized to the WebSocket connection close reason decoded as UTF-8, with error handling, and dispatch the event at the WebSocket object. [WSP]" and then WSP says "If there is no such data in the Close control frame, _The WebSocket Connection Close Reason_ is the empty string." But the result is the same. :-)