- From: <bugzilla@jessica.w3.org>
- Date: Wed, 25 Apr 2012 16:45:37 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16703 --- Comment #5 from Takeshi Yoshino <tyoshino@google.com> 2012-04-25 16:45:34 UTC --- (In reply to comment #4) > There is not so many WS apps so there would be some big issue with legacy, do > not also forget, that going from Hixie to RFC required rewrite/upgrade of the > server, either the whole WS or at least server's application logic, probably (snip) I misunderstood that you were concerned with transition from HyBi 00. Never mind. > I specifically used the word "strange", because it is not an error, warning, > confusing or ambiguous... It's just strange, that connection has been closed > properly by close frame, but for no reason at all. That simply should not It depends on the way one looks at things. 1000, 1005 and 3000-3999 clearly correspond to the situation that the connection has been closed after receiving closing handshake without any WebSocket protocol level error in its life. Application developers choose codes to use from them and give meaning for each of them. In RFC 6455, status code field is optional. Use of close() implies that the application is not interested in variable status code (for clean close) feature and reduces two octets. You suggest that we remove 1005 from webapp developers' options for simplicity. I can live with your suggestion, too. But I don't see any definitive argument to take it and drop the former. > happen. Given the fact, that we have close codes in our disposal, sending no > code at all is bad practice, and although I'm usually not a fan of Why? > specification telling what the good programming practice is, allowing to close > WS without any reason at all does not make any sense... To force users to know close code and understand what he/she is doing by close() call, we should make code argument mandatory rather than having close() send 1000. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 25 April 2012 16:45:39 UTC