[hybi] Subprotocol semantics. How SHOULD/MUST user-agent and server deal with it

[Takeshi Yoshino <[e-mail]>]

We should make it clear whether WebSocket layer (code of user-agent, server
framework) must verify only grammar (i.e. follows ABNF or not) or also check
some condition beyond grammar checking. If we do latter, we should also
define what bad req/res is clearly.

Conditions sound bad I can come up with are:

For user-agent
a) Sec-WebSocket-Protocol in response is not an element of
Sec-WebSocket-Protocol in request
b) the number of elements in Sec-WebSocket-Protocol in response is two or
more
c) sent Sec-WebSocket-Protocol but no Sec-WebSocket-Protocol in response
d) didn't send Sec-WebSocket-Protocol but response contained
Sec-WebSocket-Protocol

For server
e) supports multiple subprotocols but the user-agent didn't send
Sec-WebSocket-Protocol
f) supports multiple subprotocols but Sec-WebSocket-Protocol in request
didn't contain any of them

According to the normative section 5.2.2.2, a), b) and c) mean the server is
misbehaving. Current The WebSocket API
<http://dev.w3.org/html5/websockets/>cannot handle case b) so,
user-agent can do nothing but drop the connection
for now. But I also think some application may benefit from having multiple
values in Sec-WebSocket-Protocol in response.

How we should handle case d) is not defined clearly in the current spec.
This can be considered as "the client don't care protocol, but the server
explicitly declare the protocol it talks". Here, we come down to a question
"what absence of Sec-WebSocket-Protocol in the handshake request means.
Wanna talk default subprotocol? Don't care subprotocol?"

e) is a kind of server application framework design issue. Maybe server
frameworks pass received subprotocol request to application code to ask
decision. This is related to d). I can imagine use case like these.
- developer uses "absence of Sec-WebSocket-Protocol" as "default please".
Server application code decides some default subprotocol from the list of
subprotocols it can talk and silently starts talking it by not sending
Sec-WebSocket-Protocol in response.
- developer uses "absence of Sec-WebSocket-Protocol" as "don't care". Known
subprotocols are superchat and chat. User-agent sends no
Sec-WebSocket-Protocol. The server sends the best subprotocol that is
superchat as Sec-WebSocket-Protocol in response.

It sounds clear to me that we should drop the request in case f).

----

I think it's also an option that we leave judgement to upper layer
(JavaScript running on the user-agent, application code implemented on the
server framework) for case a), c), d), f). i.e. we don't perform any
validation other than grammar checking in WebSocket layer.

If we decide to check these condition and drop req/res in WebSocket protocol
layer, we must give clear semantics for "absence of Sec-WebSocket-Protocol".

----

The followings are some related suggestions from me on the spec text
(assuming we allow only one subprotocol in Sec-WebSocket-Protocol in
response).

5.2.2.2 (normative section)

       /subprotocol/
>           A (possibly empty) list representing the subprotocol the
>
          server is ready to use.  If the server supports multiple

          subprotocols, then the value should 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.


- Here in a normative section, "must" became "should" from non-normative
section 1.3 and 1.9. I think this should be "MUST".
- In the first sentence, we should say that the size of list must be 1.
- The last sentence is correct but misleading. It sounds that empty string
which means a list of one element "" is allowed as Sec-WebSocket-Protocol.
- The grammar for Sec-WebSocket-Protocol is not specified in this section,
but I think it's just missing. We may say here that it also follows (token |
quoted-string).

Takeshi