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.
1005 should be interpreted at server level as some sort of warning (no error code, no 1000 "I'm done" code... strange).
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.
From protocol point of view, application should not be able to send 1005 code of it's own (which you suggest)

Hi, I implemented RFC version of WebSocket::close() for WebKit.

Actually, Chrome never send 1005 as a status code.
When user omit close status code and reason, Chrome send a close frame without any body data. It means the close frame doesn't have any code and reason field.
As Bronislav said, 1005 is a pseudo code for the API layer to represent that underlaying framing doesn't contains status code. I guess the contributor see the code as a pseudo code in a server.

AFAIK, close code is not mandatory field for close frames because WebSocket API allow to omit them.

[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.

I understand this section say that 1005 doesn't mean any error case. It just means a pear going to close the connection without a code and reason. This is a case of expected behaviors.

(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.

(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.

(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.

(In reply to comment #5)
> (In reply to comment #4)
> > 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?

I've actually wrote JS WS application and also my own server, and looking at it from server position, connection can be dropped/close on socket level = fine, there might be TCP/IP connection issue; connection can be closed using codes = fine, server know, what is going on; 1005 = server has no clue what have happened.

From server-side application developer point of view, this may cause issues... Imagine sharing files, sender opens WS connection, streams file and then closes connection... 1000 means you can proceed with pushing the file to other connection for download, some application level code can mean that you want abort it, so file should be removed from queue and not pushed... if client side developer forgets to specify code, what then? There can be number of similar scenarios. 

And for every application you would have to specify what 1005 means, just because someone is lazy to write down approx. 4 digits...
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...
Not to mention, that one application could treat it as OK, other application as some sort of rollback, other application as some freeze state (let the file be there but do not stream it yet...)

This essentially requires specifying some meaning to this protocol level code on application level.

> 
> > 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.

I could live with that (I would probably prefer that).

(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...

(In reply to comment #7)

You are right, yet we can limit the occurrences of such scenarios.
I know, we cannot have perfect solution in situation we are dealing with 2 apps (server/client) possibly written by two parties, but we can limit them.

But never the less, though I kind of took your original bug different way, you are correct, what definitively should be done now it to specify, what the default should be, if it is allowed, scenario where close() can produces different results on server based on used browser is most unpleasant.
Creators may not want to remove 1005 or default argument from spec, but there should be at least clear indication what the default is.

So my read of the situation is that Takashi is right, and Firefox should send no close code (which servers can logically interpret as 1005) if the client closes the websocket with no close code passed.  I'm currently implementing this in 

   https://bugzilla.mozilla.org/show_bug.cgi?id=748580

If that's wrong and Chrome should change instead, let me know.

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.