Re: [hybi] Sec-WebSocket-Protocl

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6A1321F84AB for <>; Wed, 22 Jun 2011 23:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.515
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tdYSbUl11HZa for <>; Wed, 22 Jun 2011 23:43:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CF99421F84A9 for <>; Wed, 22 Jun 2011 23:43:29 -0700 (PDT)
Received: from ( []) by with ESMTP id p5N6hS2W012604 for <>; Wed, 22 Jun 2011 23:43:28 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; 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 ( []) by with ESMTP id p5N6gw8N031074 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <>; Wed, 22 Jun 2011 23:43:27 -0700
Received: by qyk32 with SMTP id 32so2349838qyk.7 for <>; Wed, 22 Jun 2011 23:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id h10mr1200510qch.105.1308811406628; Wed, 22 Jun 2011 23:43:26 -0700 (PDT)
Received: by with HTTP; Wed, 22 Jun 2011 23:43:26 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 22 Jun 2011 23:43:26 -0700
Message-ID: <>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <>
To: Dan Adkins <>
Content-Type: multipart/alternative; boundary=0015176f0d70f8591204a65b66f4
X-System-Of-Record: true
Subject: Re: [hybi] Sec-WebSocket-Protocl
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 -

On Fri, Jun 17, 2011 at 1:53 PM, Dan Adkins <> 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