Re: [hybi] Sec-WebSocket-Protocl

Ian Fette (イアンフェッティ) <ifette@google.com> Thu, 23 June 2011 06:43 UTC

Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A1321F84AB for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 23:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.515
X-Spam-Level:
X-Spam-Status: No, score=-105.515 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdYSbUl11HZa for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 23:43:30 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id CF99421F84A9 for <hybi@ietf.org>; Wed, 22 Jun 2011 23:43:29 -0700 (PDT)
Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p5N6hS2W012604 for <hybi@ietf.org>; Wed, 22 Jun 2011 23:43:28 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308811408; bh=+mvKiKkjwcYSw3Zrbyd8UfHttaw=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=SFOJkwYLPWQBvL6hDBwBISfh8LkkyqKDhV8APisolOhv+7HCZtAV4COeYA0HeTKL+ B5ktlbUoqiez7wtLcTvmg==
Received: from qyk32 (qyk32.prod.google.com [10.241.83.160]) by hpaq7.eem.corp.google.com with ESMTP id p5N6gw8N031074 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 22 Jun 2011 23:43:27 -0700
Received: by qyk32 with SMTP id 32so2349838qyk.7 for <hybi@ietf.org>; Wed, 22 Jun 2011 23:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qxeQb3e1EJ2yV0sO+ipxDYDYZkBTijx0rjX/h+OSSyo=; b=kAdcWz6f9S9uHbtRwG5P8GYNtqDsB5HsB/oAiGn7n2uikq+YI6EScNdVPEl3P5xVV3 wPbIUtsaWl/PXvwYvDpQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=MZEqAi1uxzw0U2BgpPwL/rhvjhqNZKksrGUR3Y6wmV5weCh6SnHB0hNHNfD8i/lUwP mszuxRWTWuj6dRptpwxA==
MIME-Version: 1.0
Received: by 10.229.8.138 with SMTP id h10mr1200510qch.105.1308811406628; Wed, 22 Jun 2011 23:43:26 -0700 (PDT)
Received: by 10.229.137.137 with HTTP; Wed, 22 Jun 2011 23:43:26 -0700 (PDT)
In-Reply-To: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com>
References: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com>
Date: Wed, 22 Jun 2011 23:43:26 -0700
Message-ID: <BANLkTinda0p+gsc+qjYUB40gXjHxsoDoNg@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Dan Adkins <dadkins@google.com>
Content-Type: multipart/alternative; boundary=0015176f0d70f8591204a65b66f4
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Sec-WebSocket-Protocl
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2011 06:43:30 -0000

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 <dadkins@google.com> wrote:

> 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
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>