Subject: Re: [hybi] Client behavior with blank server Sec-WebSocket-Protocol header

From: Takeshi Yoshino <[email-masked]>
Date: Tue, 18 Feb 2014 15:02:15 +0900

Sorry that none of us hasn't responded to this thread for long time, Peter.

The change which banned this usage is this one:
http://src.chromium.org/viewvc/blink?view=revision&revision=155603

As Joonas pointed, the WebSocket API spec is saying
req:non-empty/resp:empty combination is invalid for long time since this
change in 2010: http://html5.org/tools/web-apps-tracker?from=5172&to=5173

It was non-normative text, but now it has normative one:
http://lists.w3.org/Archives/Public/public-webapps-bugzilla/2013Oct/0215.html

In 2011, I started a thread to discuss what UA and server library should do
with subprotocol values:
http://www.ietf.org/mail-archive/web/hybi/current/msg07241.html. This
question corresponds to (c) in the post. I suggested either we do nothing
or define strict handling algorithm after giving clear semantics for
"absence of Sec-WebSocket-Protocol".

Takeshi

On Sat, Dec 28, 2013 at 8:23 PM, Tobias Oberstein <
[email-masked]> wrote:

> >A quick autobahn server test, it returns no Sec-WebSocket-Protocol if
> there is no match.
> >A quick autobahn client test, the connection still occurs on no match.
>
> Yes, this is the default behavior of Autobahn: if the server does not
> speak any of the subprotocols announced
> by the client, the server won't return a Sec-WebSocket-Protocol header at
> all.
>
> And the client will only automatically fail the handshake if the server
> _did_ return a Sec-WebSocket-Protocol
> _and_ the header value is different from any of the subprotocols initially
> announced.
>
> This behavior can be tuned using the onConnect() hooks on server and
> client side.
>
> The default behavior is designed to follow the spec:
>
> "
>    6.  If the response includes a |Sec-WebSocket-Protocol| header field
>        and this header field indicates the use of a subprotocol that was
>        not present in the client's handshake (the server has indicated a
>        subprotocol not requested by the client), the client MUST _Fail
>        the WebSocket Connection_.
> "
>
> /Tobias
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Peter Thorson <[email-masked]>
Date: Tue, 18 Feb 2014 15:33:04 -0600

Takeshi,

Thanks for the links here. I now see the chain of events that lead to this being clarified in the W3C spec and the resulting change in Chrome that now enforces this. I don’t agree with the decision that was made but it is good to have it clarified one way or the other. I can write some more definitive documentation now to answer all of the “why does your library not work in Chrome anymore?” questions I’ve been getting and offer sane workarounds.

Best,

Peter

On Feb 18, 2014, at 24:02 , Takeshi Yoshino <[email-masked]> wrote:

> The change which banned this usage is this one: http://src.chromium.org/viewvc/blink?view=revision&revision=155603
> 
> As Joonas pointed, the WebSocket API spec is saying req:non-empty/resp:empty combination is invalid for long time since this change in 2010: http://html5.org/tools/web-apps-tracker?from=5172&to=5173
> 
> It was non-normative text, but now it has normative one: http://lists.w3.org/Archives/Public/public-webapps-bugzilla/2013Oct/0215.html
> 
> In 2011, I started a thread to discuss what UA and server library should do with subprotocol values: http://www.ietf.org/mail-archive/web/hybi/current/msg07241.html. This question corresponds to (c) in the post. I suggested either we do nothing or define strict handling algorithm after giving clear semantics for "absence of Sec-WebSocket-Protocol".
> 
> Takeshi
> 
> 
> On Sat, Dec 28, 2013 at 8:23 PM, Tobias Oberstein <[email-masked]> wrote:
> >A quick autobahn server test, it returns no Sec-WebSocket-Protocol if there is no match.
> Yes, this is the default behavior of Autobahn: if the server does not speak any of the subprotocols announced
> by the client, the server won't return a Sec-WebSocket-Protocol header at all.
> 
> And the client will only automatically fail the handshake if the server _did_ return a Sec-WebSocket-Protocol
> _and_ the header value is different from any of the subprotocols initially announced.
> 
> This behavior can be tuned using the onConnect() hooks on server and client side.
>