On 1/31/13 6:06 PM, Scott Ferguson wrote:
> On 1/31/13 5:13 PM, Danny Coward wrote:
>> Hi folks,
>>
>>
>>
>> * Container closing connection / onClose() and connection timeouts
>> (http://java.net/jira/browse/WEBSOCKET_SPEC-80 ,
>> http://java.net/jira/browse/WEBSOCKET_SPEC-117 )
>>
>> I think the container should always call onClose() on the (local)
>> endpoint if the connection is being closed (for whatever reason). I
>> think its a central part of the programming model. So, yes on 80.
>>
>> Second, I'd rather not invent new CloseCodes for various situations
>> where a container needs to close a connection: I think RFC 6455
>> already defines a useful range of options sufficient for the needs of
>> the websocket developer. After all, all they are going to do with the
>> CloseCode is document it: there is little specific action they can
>> take based on the category of closure. I think 1001 works well for
>> timeouts, and 1005 is perfectly ok if the reason for the closure
>> doesn't fit any of the given options.
>
> Ok. It looks like 1006 is exactly for this purpose. (I just reread
> that part of the spec. I'd never noticed it.)
>
> I think any other code would be a mistake, because we'd lose the key
> information about whether the client sent a close frame. 1006 means
> the client didn't send a close frame (the client cannot send a 1006.)
>
> 1006 is a reserved value and MUST NOT be set as a status code in a
> Close control frame by an endpoint. It is designated for use in
> applications expecting a status code to indicate that the
> connection was closed abnormally, e.g., without sending or
> receiving a Close control frame.
>
OK that sounds good -for a 'local close' the implementation should use
as 1006.
> -- Scott
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation