- From: <bugzilla@jessica.w3.org>
- Date: Wed, 25 Apr 2012 05:43:39 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16703
Takeshi Yoshino <tyoshino@google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tyoshino@google.com
--- Comment #3 from Takeshi Yoshino <tyoshino@google.com> 2012-04-25 05:43:36 UTC ---
(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 ... (*)
> 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.
> 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.
----
If it turned out that (*) is false, Your suggestion might make more sense.
--
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 05:43:42 UTC