Re: [hybi] Client offers invalid WS protocols, what must the server do? 101???

Yes.  This requirement should be in the spec.  Frankly, I implemented my
WebSocket libraries this way as it's the only thing that makes any sense.  I
just assumed that's how it was supposed to be.  It didn't really occur to me
that the protocol was underspecified here.  There is absolutely no
reasonable use case for the server to fall back to an unspecified default
protocol and accept the connection if it doesn't know any of the requested
subprotocols from the client, just like there's no acceptable use case for
the server to accept the connection with a subprotocol not contained in the
list of subprotocols requested by the client.  If the client requests a list
of subprotocols, that is to be taken as the canonical list of the only
subprotocols it knows how to speak.  Anything else will fail.  It should
respond with a 4xx HTTP error code.

The *only* time a server should accept the connection with a default
unspecified subprotocol is when the client doesn't request any subprotocols
at all.  That's really the end of the story.

This minor enhancement to the spec would be trivial and shouldn't hold
anything else up.

Brian

On Wed, Aug 31, 2011 at 1:08 PM, Philipp Serafin <phil127@gmail.com> wrote:

>  Am 31.08.2011 22:05, schrieb Iñaki Baz Castillo:
>
> Me (and others AFAIK) are just proposing that, in **case** the client
> provides a WS protocol in the HTTP GET, and the server **does not**
> support such protocol, then the server MUST reject the WS handshake
> (which means a 4XX error code rather than "101 I don't know what we
> are supposed to speak now but I accept the WS session").
>
>  Exactly.
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>