Re: [hybi] Sec-WebSocket-Protocl

[Takeshi Yoshino <[e-mail]>]

Hi

I think we should keep subprotocol negotiation optional to allow user who is
not interested in subprotocol to exclude it.
I would
- allow absence of "Sec-WebSocket-Protocol" from client to server
- give it meaning of "client won't use opening handshake's subprotocol
negotiation"

As I listed in this thread
http://www.ietf.org/mail-archive/web/hybi/current/msg07448.html some of
endpoint behavior are still a bit under-specified.

As Iñaki noted, subprotocol negotiation can also be done over application
layer. The only benefit of subprotocol field in the opening handshake is
that we can finish subprotocol negotiation in the first round-trip time (in
an extreme case, this can also be done by embedding subprotocol choice in
URL string and replying by the first frame from server).

On Mon, Jun 20, 2011 at 00:14, Iñaki Baz Castillo <[e-mail]> wrote:

> 2011/6/17 Dan Adkins <[e-mail]>:
> > 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
>

That's not well specified yet. The following sentence in 5.2.2 seems to be
implying that if the server supports multiple subprotocols, the client must
send Sec-WebSocket-Protocol.

       /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


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

I think the server would
- reject the connection or
- speak some pre-specified default subprotocol (but doesn't send out
"Sec-WebSocket-Protocol")

It's up to the design of the application.


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

That's not well specified yet.