RESOLVED INVALID 81072
[WebSocket]Browser should use 1000 as status code when WebSocket API close is called without status code parameter.
https://bugs.webkit.org/show_bug.cgi?id=81072
Summary [WebSocket]Browser should use 1000 as status code when WebSocket API close is...
Li Yin
Reported 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.
Attachments
Patch (2.42 KB, patch)
2012-03-13 20:33 PDT, Li Yin
abarth: review-
Li Yin
Comment 1 2012-03-13 20:33:25 PDT
Adam Barth
Comment 2 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.
Li Yin
Comment 3 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.
Adam Barth
Comment 4 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.)
Li Yin
Comment 5 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.
Takashi Toyoshima
Comment 6 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.
Li Yin
Comment 7 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?
Takashi Toyoshima
Comment 8 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.
Takashi Toyoshima
Comment 9 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.
Li Yin
Comment 10 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.
Note You need to log in before you can comment on or make changes to this bug.