Bug 81072 - [WebSocket]Browser should use 1000 as status code when WebSocket API close is called without status code parameter.
Summary: [WebSocket]Browser should use 1000 as status code when WebSocket API close is...
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-13 20:26 PDT by Li Yin
Modified: 2012-05-08 00:17 PDT (History)
6 users (show)

See Also:


Attachments
Patch (2.42 KB, patch)
2012-03-13 20:33 PDT, Li Yin
abarth: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Li Yin 2012-03-13 20:26:56 PDT
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.
Comment 1 Li Yin 2012-03-13 20:33:25 PDT
Created attachment 131776 [details]
Patch
Comment 2 Adam Barth 2012-03-13 21:14:05 PDT
Comment on attachment 131776 [details]
Patch

Can you provide a link to the spec that requires this change?  Also, changes in behavior require tests.
Comment 3 Li Yin 2012-03-13 21:54:13 PDT
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.
Comment 4 Adam Barth 2012-03-13 22:07:43 PDT
Thanks.  That's good information to include in the ChangeLog.  (The patch still needs a test, of course.)
Comment 5 Li Yin 2012-03-13 23:35:30 PDT
(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.
Comment 6 Takashi Toyoshima 2012-03-14 10:05:10 PDT
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.
Comment 7 Li Yin 2012-04-22 01:14:07 PDT
(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?
Comment 8 Takashi Toyoshima 2012-04-22 22:39:13 PDT
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.
Comment 9 Takashi Toyoshima 2012-05-07 23:59:49 PDT
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.
Comment 10 Li Yin 2012-05-08 00:17:53 PDT
(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.