Subject: [hybi] Sec-WebSocket-Protocl

From: Dan Adkins <[email-masked]>
Date: Fri, 17 Jun 2011 13:53:23 -0700

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 19 Jun 2011 17:14:25 +0200

> question: if the client doesn't specify a subprotocol, can the server

I agree. And I expect that subprotocol field will have not to much
real usage. Instead, a webdeveloper will make JavaScript to open a WS
connection with his server and start speaking the subprotocol even
without negociating it (as both the client side and server side will
be coded by same provider). It will be much like the web world, in
which each page is an independent world.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 21 Jun 2011 20:01:54 +0900

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

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

> > "we're speaking this protocol, like it or not," as the client has no

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.

> > question: if the client doesn't specify a subprotocol, can the server

That's not well specified yet.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Jun 2011 13:47:30 +0200

> URL string and replying by the first frame from server).

In fact, if Sec-WebSocket-Protocol header was not exist, I expect
nobody would miss it. WebSocket services will be served by providers
also providing the JavaScript code. Maybe a webpage includes a
JavaScript code to connect to a chat and other code to connect to a
like-RSS system. Webdevelopers will just enable two different WS URI
(ws://mydomain.org/chat and ws://mydomain.org/rss) and the JavaScript
client will just connect to each one. No need of negotiation.

Honestly I don't see the benefict of standarizing or negotiating
subprotocols on top of WebSocket. Or maybe what I want to say is that
I don't believe it will succeed (as web developers are anarchic by
nature and they want to know exacty *nothing* about standars,
protocols, IANA registry names and so on).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Philipp Serafin <[email-masked]>
Date: Tue, 21 Jun 2011 15:10:54 +0200

> protocols, IANA registry names and so on).
Wasn't the whole idea of WS sub-protocols that they are *not* maintained
by IANA or any other registry?

I agree that registration would be a burden that very few non-evangelist
web developers would take on for an arguably very small benefit.
However, if developers are allowed to use their own names "ad-hoc" (and
hopefully adhering to some kind of namespacing scheme), I believe this
could be very useful for frameworks and standardized web APIs developed
on top of WS - think of "OAuth-over-WS", "OpenID-over-WS" or
"XMPP-over-WS".

I believe there are strong use-cases for both using WS with sub
protocols and without, so both should be possible.

Regards,
Philipp Serafin

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 21 Jun 2011 15:19:46 +0200

> protocols and without, so both should be possible.

Then the spec should improve *a lot* the usage case of the
Sec-WebSocket-Subprotocol header (i.e. what happens when the HTTP
handshake request does not contain such a header?).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Wed, 22 Jun 2011 23:43:26 -0700

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 <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>