Re: [hybi] Sec-WebSocket-Protocl

I have tried to address the ambiguity, change checked in to svn -
http://trac.tools.ietf.org/wg/hybi/trac/changeset/118/websocket/draft-ietf-hybi-thewebsocketprotocol.xml

On Fri, Jun 17, 2011 at 1:53 PM, Dan Adkins <dadkins@google.com> wrote:

> If the client does not specify a subprotocol, is the server allowed to
> respond with one?
>
> Section 1.3:
>   The |Sec-WebSocket-Protocol| request-header field can be used to
>   indicate what subprotocols (application-level protocols layered over
>   the WebSocket protocol) are acceptable to the client.  The server
>   selects one of the acceptable protocols and echoes that value in its
>   handshake to indicate that it has selected that protocol.
> ...
>  Option fields can also be included.  In this version of the protocol,
>   the main option field is |Sec-WebSocket-Protocol|, which indicates
>   the subprotocol that the server has selected.  Web browsers verify
>   that the server included one of the values as was specified in the
>   WebSocket client's handshake.  A server that speaks multiple
>   subprotocols has to make sure it selects one based on the client's
>   handshake and specifies it in its handshake.
>
> From this, it appears not.  But there's some ambiguity with the
> mention of multiple subprotocols.
>
> Section 5.2.2:
>       /subprotocol/
>          Either a single value or null, representing the subprotocol
>          the server is ready to use.  If the server supports multiple
>          subprotocols, then the value MUST be derived from the client's
>          handshake, specifically by selecting one of the values from
>          the "Sec-WebSocket-Protocol" field.  The absence of such a
>          field is equivalent to the null value.  The empty string is
>          not the same as the null value for these purposes, and is not
>          a legal value for this field.  The ABNF for the value of this
>          header is (token), where the definitions of constructs and
>          rules are as given in [RFC2616].
>
> So, we know what the server MUST do if the server supports multiple
> subprotocols.  But what if the client didn't include that field?  Is
> the server free to respond with the protocol of its choice?  That
> seems strange that the server would be allowed to say to the client,
> "we're speaking this protocol, like it or not," as the client has no
> opportunity to respond.
>
> Maybe I'm reading too much into this, but it does seem like there's a
> bit of a hole in the spec as I can't find the answer to my original
> question: if the client doesn't specify a subprotocol, can the server
> dictate one?
>
> -Dan
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>