Bug 81072 – [WebSocket]Browser should use 1000 as status code when WebSocket API close is called without status code parameter.

• Status: RESOLVED
• Resolution: INVALID
• Component: WebCore Misc.

[Li Yin]

When WebSocket API close was called like this "ws.cloes()", chromium didn't send the close frame to WebSocket server.
And WebSocket server still sent frame to browser unexpectedly, it didn't produce some error, but maybe it's not friendly.

Firefox used the status 1000 as the default value, when the close api had no the parameter.

[Li Yin]

Created attachment 131776 [details]
Patch

[Adam Barth]

Comment on attachment 131776 [details]
Patch

Can you provide a link to the spec that requires this change?  Also, changes in behavior require tests.

[Li Yin]

http://dev.w3.org/html5/websockets/#dom-websocket-close
   If the WebSocket closing handshake has not yet been started,
   Start the WebSocket closing handshake and...

Here, from RFC6455 http://tools.ietf.org/html/rfc6455#section-7.4, 
   Start the WebSocket Closing Handshake, should send the close frame.

[Adam Barth]

Thanks.  That's good information to include in the ChangeLog.  (The patch still needs a test, of course.)

[Li Yin]

(In reply to comment #0)
> When WebSocket API close was called like this "ws.cloes()", chromium didn't send the close frame to WebSocket server.
> And WebSocket server still sent frame to browser unexpectedly, it didn't produce some error, but maybe it's not friendly.
> 

I'm sorry for my previous misleading.
From the newest code, chromium indeed sent close frame, when the close api was called without parameter. 
but it just had no body(status code and reason), which seemed to be allowed by RFC6455.

> Firefox used the status 1000 as the default value, when the close api had no the parameter.

The only difference is that Firefox used normal closure as the default value.

[Takashi Toyoshima]

Hi joey, thank you for a patch.
Originally, I implemented this WebSocket::close method for new hybi/rfc protocol.

Before hybi-06, the WebSocket protocol didn't have the status code and the reason. At that time, the WebSocket API doesn't allow any argument for close method.
From the viewpoint of protocol and API history, I decided to send close frame with empty body when user call close without any argument.

[Li Yin]

(In reply to comment #6)
> Hi joey, thank you for a patch.
> Originally, I implemented this WebSocket::close method for new hybi/rfc protocol.
> 
> Before hybi-06, the WebSocket protocol didn't have the status code and the reason. At that time, the WebSocket API doesn't allow any argument for close method.
> From the viewpoint of protocol and API history, I decided to send close frame with empty body when user call close without any argument.

From the bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16703
It still have no obvious definition about the default status code in the spec, but it seems that 1000 should be.
Do you think it is necessary to use 1000 instead of no status code?

[Takashi Toyoshima]

Hi, Li.

I post a similar comment on the w3c thread, too.

[from RFC6455 7.1.5.]
> a Close control frame may contain a status code indicating a reason for closure.
> (snip)
> If this Close control frame contains no status code, _The WebSocket
> Connection Close Code_ is considered to be 1005.  If _The WebSocket
> Connection is Closed_ and no Close control frame was received by the
> endpoint (such as could occur if the underlying transport connection
> is lost), _The WebSocket Connection Close Code_ is considered to be
> 1006.

Actually, RFC said code and reason are optional. It uses 'MAY' in normative sections. I understand that this is because the API allow to omit them. As a result, pseudo code 1005 is needed for representing this case. 1005 doesn't represent any unexpected or error case.

[Takashi Toyoshima]

API spec author said in the w3c thread in https://www.w3.org/Bugs/Public/show_bug.cgi?id=16703,

> Ian 'Hixie' Hickson 2012-05-02 20:09:29 UTC
> As far as I can tell, the spec is clear on this. If there's no argument, then
> no close code is passed to the protocol. The protocol spec defines what to do
> in that case.

And Firefox is going to fix the behavior.
https://bugzilla.mozilla.org/show_bug.cgi?id=748580

So, I'd like to close this issue.

[Li Yin]

(In reply to comment #9)
> API spec author said in the w3c thread in https://www.w3.org/Bugs/Public/show_bug.cgi?id=16703,
> 
> > Ian 'Hixie' Hickson 2012-05-02 20:09:29 UTC
> > As far as I can tell, the spec is clear on this. If there's no argument, then
> > no close code is passed to the protocol. The protocol spec defines what to do
> > in that case.
> 
> And Firefox is going to fix the behavior.
> https://bugzilla.mozilla.org/show_bug.cgi?id=748580
> 
> So, I'd like to close this issue.

Okay, thanks.