Re: [hybi] Comments about draft-13

[Alexey Melnikov <[e-mail]>]

Hi Iñaki,

Iñaki Baz Castillo wrote:

>2011/9/2 Iñaki Baz Castillo <[e-mail]>:
>  
>
>>3) Section 4.2.2 does include nothing about a 4XX HTTP response code
>>for the case in which the WS clients offers N WS subprotocols and the
>>server supports no one of them. Current text states that the server
>>MUST reply 101 without Sec-WebSocket-Protocol, so the client would
>>then MUST Fail_The_Connection.
>>
>>There has been a long thread recently suggesting that in that case
>>(and just in *that* case) the server whould *reject* the GET request
>>with a *specific* HTTP status code which would mean "I don't support
>>any of your suggested WS protocols, so I cannot accept the WS session
>>because I have no idea what we are supposed to speak".
>>
>>This is a new protocol, so feel *free* to create a new "HTTP" response
>>code for this case, maybe:
>>
>> 488 WebSocket SubProtocol Not Supported
>>
>>As I explained in other thread, this status code could help the human
>>user and the client application developer to realize that his software
>>is not up-to-date with the service requeriments ("your programm is too
>>old, upgrade please").
>>    
>>
>
>
>Hi, any new consideration about this?
>Thanks a lot.
>
After thinking more about this: I would prefer to leave the current 
behaviour as is:

C: I would like to use either subprotocol "foo" or "bar"
S: 101 (WebSocket handshake), but speak neither

at this point the client can decide to close the connection, or decide 
that it can cope with lack of the subprotocols.

You propose:
C: I would like to use either subprotocol "foo" or "bar"
S: 488 speak neither

At this point if the client can cope with lack of support for both "foo" 
and "bar", it has to redo the handshake without mentioning them.
Otherwise it can close the connection.

I don't think there is a significant difference between 2 cases: the 
number of round trips is the same and the same behaviour can be achieved 
easily in either case.

I would also like to keep handling of subprotocols the same as handling 
of extensions, i.e. client can always list them as optional for the 
server to handle.