Subject: [hybi] Please calrify "5.2.2. Sending the Server's Opening Handshake"

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 24 Aug 2011 18:33:08 +0200

/subprotocol/
          Either a single value representing the subprotocol the server
          is ready to use or null.  The value chosen MUST be derived
          from the client's handshake, specifically by selecting one of
          the values from the "Sec-WebSocket-Protocol" field that the
          server is willing to use for this connection (if any).  If the
          client's handshake did not contain such a header field, or if
          the server does not agree to any of the client's requested
          subprotocols, the only acceptable value is null.  The absence
          of such a field is equivalent to the null value (meaning that
          if the server does not wish to agree to one of the suggested
          subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol|
          header field in its response).  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
          field is (token), where the definitions of constructs and
          rules are as given in [RFC2616].

So it's stating that in case the client does not send a
Sec-WebSocket-Protocol header, the server MUST NOT include such a
header in the 101 response. Why?? why cannot the server include
"Sec-WebSocket-Protocol: test.foo.com" in the 101 response meaning
that *that* is the chosen protocol?

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

---

From: Brian McKelvey <[email-masked]>
Date: Wed, 24 Aug 2011 11:04:55 -0700

Because if the client didn't request it, it doesn't know how to speak it.

Sent from my iPhone

On Aug 24, 2011, at 9:33 AM, Iñaki Baz Castillo <[email-masked]> wrote:

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 24 Aug 2011 20:11:25 +0200

> Because if the client didn't request it, it doesn't know how to speak it.

So then, which protocol is supposed to be established? no one??

If the client does not suggest a protocol(s) then the server should do
it in the response. If then the client does not support it, just close
the connection (same case as when the 101 response contains a WS
protocol not supported by the client).

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

---

From: Joe Mason <[email-masked]>
Date: Wed, 24 Aug 2011 14:52:12 -0400

It's perfectly valid for the client and server to not use a named subprotocol, just an ad-hoc anonymous one.  I'd expect most web sites to work like this.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Iñaki Baz Castillo
> Sent: Wednesday, August 24, 2011 2:11 PM
> To: Brian McKelvey
> Cc: [email-masked]
> Subject: Re: [hybi] Please calrify "5.2.2. Sending the Server's Opening
> Handshake"
> 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Brian McKelvey <[email-masked]>
Date: Wed, 24 Aug 2011 12:38:02 -0700

Yes this is the current majority use case.  If the client doesn't request a subprotocol, the server can make an assumption about what subprotocol to speak (current deployments generally only speak one subprotocol) and establish the connection with no defined subprotocol.

Brian

Sent from my iPhone

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 24 Aug 2011 21:44:28 +0200

> Yes this is the current majority use case.  If the client doesn't request a subprotocol, the server can make an assumption about what subprotocol to speak (current deployments generally only speak…

But what is wrong if in that case the server sends a
Sec-WebSocket-Protocol indicating the chosen protocol?

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

---

From: Brian <[email-masked]>
Date: Wed, 24 Aug 2011 14:28:36 -0700

Because that indicates that it's not agreeing to the client's request for
"no protocol."  When the client doesn't request a subprotocol, it's not
requesting "any" protocol -- it's requesting the specific singular unnamed
protocol that they coded server to support.

It's a simplification for developers who don't want to bother with
subprotocols at all.  In this case, the server probably only speaks the one
subprotocol and the application developer didn't want to bother thinking
about the negotiation of it.  In this way, the definition of a subprotocol
is a totally optional concept for the application developer.

Brian

On Wed, Aug 24, 2011 at 12:44 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> > Yes this is the current majority use case.  If the client doesn't request
> a subprotocol, the server can make an assumption about what subprotocol to
> speak (current deployments generally only speak one subprotocol) and
> establish the connection with no defined subprotocol.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 24 Aug 2011 23:47:23 +0200

> is a totally optional concept for the application developer.

Ok, I understand. I still think it's too much
"lazy-developer-oriented" but it's ok.

Thanks.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 30 Aug 2011 11:38:46 +0100

>that *that* is the chosen protocol?
Because the server is not allowed to select something not advertised by 
the client. I think the text is correct as written, so no change.