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

[Takeshi Yoshino <[e-mail]>]

On Thu, Apr 14, 2011 at 16:19, Andy Green <[e-mail]> wrote:

> On 04/14/2011 07:57 AM, Somebody in the thread at some point said:
> f) supports multiple subprotocols but Sec-WebSocket-Protocol in request
>
>> didn't contain any of them
>>
>
>  It sounds clear to me that we should drop the request in case f).
>>
>
> Right... whatever the plan was for no explicit protocol being negotiated,
> it no longer makes any sense.
>
> The protocol should always have to be explicitly requested by the client
> even if the server only supports that one, you don't know if a different
> client who assumes it is a different protocol is connecting to you
> otherwise.  There'd be no error and if the protocols were similar the
> failure mode might take a long time to show or be subtle.
>

Thanks, Andy.

As no one seems to be interested in usefulness of these strange cases, I'd
suggest explicitly drop these cases a) - d) in the client requirements
normative section. So the resulting spec texts for Sec-WebSocket-Protocol
handling is like this.

====
Sec-WebSocket-Protocol in request
- 1#(token | quoted-string)
- characters in each of element after unquoting must be in the range U+0021
to U+007E

Sec-WebSocket-Protocol in response
- (token | quoted-string)
-- This forbids case b)
- characters in string after unquoting must be in the range U+0021 to U+007E

User agent must
- (if subprotocols is given) format and send subprotocols
- (otherwise) send nothing

User agent fail when
- sent subprotocols but didn't receive subprotocol  # This forbids case c)
- sent subprotocols and received subprotocol but it's not in sent
subprotocols  # This forbids case a)
- didn't send subprotocols but received subprotocol  # This forbids case d)
- received bad formatted subprotocol
Otherwise, pass received subprotocol to upper layer

Server side fail when
- received bad formatted subprotocols
- whenever the server is not satisfied with subprotocols
-- This relegates decision for e) and f) to server implementation

Server
- (if received subprotocols) must choose one subprotocol from subprotocols,
format and send it
- (otherwise) must not send subprotocol
====