[hybi] Sec-WebSocket-Protocl

Dan Adkins <dadkins@google.com> Fri, 17 June 2011 20:53 UTC

Return-Path: <dadkins@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3DDB711E80B9 for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 13:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2Wo-c6cvJUXr for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 13:53:25 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 986FF11E80B6 for <hybi@ietf.org>; Fri, 17 Jun 2011 13:53:25 -0700 (PDT)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com []) by smtp-out.google.com with ESMTP id p5HKrOqt016641 for <hybi@ietf.org>; Fri, 17 Jun 2011 13:53:24 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308344004; bh=FeJ9IFhUVSOQKfgpP4WYgqwZ8PA=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=YaO/qxLxTcT13HV0IT08deU/5QnqHXoyauyhOpsEe85m9Vm7xmgio43vm6nGLj+jM vfVpD8Hd1X4WFYn4ESIcw==
Received: from yie30 (yie30.prod.google.com []) by wpaz13.hot.corp.google.com with ESMTP id p5HKrNxC017619 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Fri, 17 Jun 2011 13:53:24 -0700
Received: by yie30 with SMTP id 30so2048636yie.31 for <hybi@ietf.org>; Fri, 17 Jun 2011 13:53:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=CWejoFxArESJUgUQ/lUX/BFCpwaK+CzFWAZttEMAQcw=; b=Dp36VuZnWHZs5j8j3kiOmzLVtVQ9IWXpDavdBBDWnJ3+Yf/cXHPwMpDp89PfIYRAQ2 0o6Z1Evj9u4hxm4+vYnA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; b=UlQGoPfOvBe6KGa84t0FVKs1sTsv9k/rH564HW1bJRaATNdDOcxBStY+nqC+MOniNR L6RNgjcpyt20lvXfQdfw==
MIME-Version: 1.0
Received: by with SMTP id n8mr1951725ybh.415.1308344003582; Fri, 17 Jun 2011 13:53:23 -0700 (PDT)
Received: by with HTTP; Fri, 17 Jun 2011 13:53:23 -0700 (PDT)
Date: Fri, 17 Jun 2011 13:53:23 -0700
Message-ID: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com>
From: Dan Adkins <dadkins@google.com>
To: hybi@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Subject: [hybi] Sec-WebSocket-Protocl
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Fri, 17 Jun 2011 20:53:26 -0000

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:
          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?