- From: <bugzilla@jessica.w3.org>
- Date: Wed, 25 Apr 2012 19:20:21 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16703 --- Comment #7 from Takeshi Yoshino <tyoshino@google.com> 2012-04-25 19:20:20 UTC --- (In reply to comment #6) > From server-side application developer point of view, this may cause issues... (snip) > developer forgets to specify code, what then? There can be number of similar > scenarios. I understand your concern. But even if we have close() send 1000, the situation won't be so better. Client developer may forget to specify code on close method call, and now send 1000 unconsciously instead of 1005. Server takes it as successful even if there some issue happened on client side. I think it's easier to find such broken client and report to the client developer if close() results 1005. Such clients leave 1005 in your server log together with origin. If close() sends 1000, you cannot take this way. You need to investigate bug reports and escalate it to the client developer who use close() for failure case by mistake. > And for every application you would have to specify what 1005 means, just > because someone is lazy to write down approx. 4 digits... As long as application spec is well defined, it's not a problem, I believe. Developer can just take 1005 as an error. I agree that the frequency you get 1005 will be negligible once API spec disallow sending a close frame w/o code. But thinking of broken clients which mistakenly use close(), we still can't be relieved. > There's no generic meaning to it, it cannot mean that you should proceed as > normal close, because this is not normal close; you cannot proceed as this is > abort, because WS RFC does not specify application level codes... Hmm... That's just up to application developer, I think... (snip) > This essentially requires specifying some meaning to this protocol level code > on application level. It's inevitable. Since a close frame w/o code is valid in RFC 6455, it does happen. (by non conforming browser, non-browser client, etc.) Server developer needs to write some code to handle it as error, success, or some regardless we allow sending it on the browser API spec or not. > > 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. > > I could live with that (I would probably prefer that). Yes. This is the only option that makes you feel easy, but is still not perfect... -- 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 19:20:24 UTC