Re: [hybi] Sec-WebSocket-Protocl

Takeshi Yoshino <> Tue, 21 June 2011 11:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69B1A11E80C1 for <>; Tue, 21 Jun 2011 04:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.569
X-Spam-Status: No, score=-105.569 tagged_above=-999 required=5 tests=[AWL=0.107, 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 ptGx+nlVrnOn for <>; Tue, 21 Jun 2011 04:02:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A456411E807C for <>; Tue, 21 Jun 2011 04:02:17 -0700 (PDT)
Received: from ( []) by with ESMTP id p5LB2GIU031256 for <>; Tue, 21 Jun 2011 04:02:16 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=beta; t=1308654136; bh=0QqNjS1xY6Kt5FntR23r6ZG/q2U=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=iTNIyJ+8JOWnNzHqTpf3t6GleeNHBWTFcCKvm17Vlzse9+G+j45D5LNg9f4gKDP62 SETyGnmpvt4U/KbkxvE7A==
Received: from gye5 ( []) by with ESMTP id p5LB2FdU024732 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <>; Tue, 21 Jun 2011 04:02:15 -0700
Received: by gye5 with SMTP id 5so2420828gye.15 for <>; Tue, 21 Jun 2011 04:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=24DTqg5E2Qsnxj38fkcyLJ51qbWQ8spTAYJ3uiU1qxQ=; b=Dph74dR1FWCNlQ+fx3EgJ3Ts5XZMUMzHG3/VU5cRdmTIGggREVRSbr4cGpKmA7/m+0 42pwyQMq2Hqf0YWPwteg==
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Hr8miJJ5s4mCtCT2JoOOrkLi4JmkxvA+pJXO1OOoFFJK5xfT2/kFKbNkAQrRPs9aZ6 Iq1y/cyJu2Z4swJ/g9mA==
Received: by with SMTP id n17mr1384561ybk.342.1308654134993; Tue, 21 Jun 2011 04:02:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 21 Jun 2011 04:01:54 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Takeshi Yoshino <>
Date: Tue, 21 Jun 2011 20:01:54 +0900
Message-ID: <>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Content-Type: multipart/alternative; boundary=000325553b56d9a32f04a636c8a9
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: Tue, 21 Jun 2011 11:02:18 -0000


I think we should keep subprotocol negotiation optional to allow user who is
not interested in subprotocol to exclude it.
I would
- allow absence of "Sec-WebSocket-Protocol" from client to server
- give it meaning of "client won't use opening handshake's subprotocol

As I listed in this thread some of
endpoint behavior are still a bit under-specified.

As Iñaki noted, subprotocol negotiation can also be done over application
layer. The only benefit of subprotocol field in the opening handshake is
that we can finish subprotocol negotiation in the first round-trip time (in
an extreme case, this can also be done by embedding subprotocol choice in
URL string and replying by the first frame from server).

On Mon, Jun 20, 2011 at 00:14, Iñaki Baz Castillo <> wrote:

> 2011/6/17 Dan Adkins <>om>:
> > 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

That's not well specified yet. The following sentence in 5.2.2 seems to be
implying that if the server supports multiple subprotocols, the client must
send Sec-WebSocket-Protocol.

          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

> > 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.

I think the server would
- reject the connection or
- speak some pre-specified default subprotocol (but doesn't send out

It's up to the design of the application.

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

That's not well specified yet.