- From: <bugzilla@jessica.w3.org>
- Date: Wed, 25 Apr 2012 13:22:11 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16703 --- Comment #4 from Bronislav Klučka <bronislav.klucka@bauglir.com> 2012-04-25 13:22:08 UTC --- (In reply to comment #3) > (In reply to comment #1) > > Hi, > > actually 1000 should be the default: > > those close codes are protocol level codes, when using WebSocket API you are > > already using implementation of client within UA, so the WS.close() method > > really means regular/normal close, that should be interpreted as regular/normal > > close. > > Yes, in HyBi 00 (Hixie 76) era, there was not close status feature, so there're > many existing apps using close calls with no argument. But I think those > close()s were not only for normal closure but also for any kind of closure > which include application level errors which are now mapped to 3XXX status > codes in RFC 6455. So, IMO, corresponding close() to 1005 (unknown) makes more > sense. > > So, developers should do either of the followings in RFC 6455 era: > - (want to utilize status) client uses close(1000) and server takes 1005 as an > error > - (not want to utilize status) client uses close() and server ignores contents > in a close frame > -- saves two octets of a close frame > > I think there's some demand for the latter ... (*) 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 done by the same developer / team / company that is behind JS. I doubt there are many JS application that survived going from Hixie to RFC without changes. I have no numbers of course, but it seems quite logical, so I really do not think legacy should be an issue here. And given the state of JS WS, given the fact that this is not specifies at all, legacy isn't an issue here. > > > 1005 should be interpreted at server level as some sort of warning (no error > > code, no 1000 "I'm done" code... strange). > > I slightly prefer leaving what should be taken as strange cases up to users > because of (*). 1005 clearly means the endpoint received the close frame > successfully but there was no status code in it. Not ambiguous/confusing at > all. As far as we make sure that UA sends a close frame without status code for > close call without any argument, it's fully controllable by JavaScript code on > the UA whether to put status code or not. 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 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 specification telling what the good programming practice is, allowing to close WS without any reason at all does not make any sense... > > > No one can manually send 1005 code, in WS.close method, so this defaults would > > require to specify 1000 all the time, always... It would be better to default > > to it from program code and leave 1005 to actual UI/server communication in > > strange cases. > > As far as we keep a way to send a close frame without status code (that might > be close() or close(null)), I think we should make the API be asking developers > to explicitly specify status code not to have close() calls unconsciously > saying "it's successful!" rather than saving typing. > > If we define close(null) (or something else) to send a close frame without > status code instead of close(), it's a bit more confusing than current one. > again, I do not think we should allow any code defined by WS RFC to be sent by programmer directly, except maybe for 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 13:22:14 UTC