Re: [hybi] Subprotocol semantics. How SHOULD/MUST user-agent and server deal with it

Andy Green <andy@warmcat.com> Thu, 14 April 2011 07:19 UTC

Return-Path: <andy.warmcat.com@googlemail.com>
X-Original-To: hybi@ietfc.amsl.com
Delivered-To: hybi@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 61066E0861 for <hybi@ietfc.amsl.com>; Thu, 14 Apr 2011 00:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjuzClmkt-ST for <hybi@ietfc.amsl.com>; Thu, 14 Apr 2011 00:19:34 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id F3E91E0845 for <hybi@ietf.org>; Thu, 14 Apr 2011 00:19:33 -0700 (PDT)
Received: by wyb29 with SMTP id 29so1262120wyb.31 for <hybi@ietf.org>; Thu, 14 Apr 2011 00:19:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=byYPHvFc6lhZJf/ZQX+zyhCSQWInwkigHAedlzXmURA=; b=Fj/uaCSAb6VPdjDPh8NRBBpHLGxJiAFyd4d04cTP7vTkSNbDyhBCFXf6oEwI4jBL4+ t+kNIAcfHJ9Gj3ln10GTtQqDwPP9KAsHcaJ61z7moCLBmEv3LeQa8pVuPCkb3qNix7Zg T72aLM99Ixa5Kg7g979wyanmCaZwKoTdcHb9s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qyLaIiFS0KwaQOqRL0hr0fTkUe8tdwXvgEtqO1aEQnOUdXRUdx4fd6SN8oAQTXwwjE kCGiCdxQx5gMOCbOlfxuh7us9cFH/dNlHOvEhV+okCbDXrRVfKMH81KTrGiHcCSiLEo9 UoHcHZL+oaEl2dlhxYi/oFhR+nF96SUX2EVBM=
Received: by 10.227.61.16 with SMTP id r16mr444377wbh.24.1302765573321; Thu, 14 Apr 2011 00:19:33 -0700 (PDT)
Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id e13sm794380wbi.40.2011.04.14.00.19.31 (version=SSLv3 cipher=OTHER); Thu, 14 Apr 2011 00:19:32 -0700 (PDT)
Sender: Andy Green <andy.warmcat.com@googlemail.com>
Message-ID: <4DA6A003.3070308@warmcat.com>
Date: Thu, 14 Apr 2011 08:19:31 +0100
From: Andy Green <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110403 Fedora/3.1.9-6.fc16 Thunderbird/3.1.9
MIME-Version: 1.0
To: Takeshi Yoshino <tyoshino@google.com>
References: <BANLkTimN3LK=nwhnWheVnhw4Ax4KmLWOgA@mail.gmail.com>
In-Reply-To: <BANLkTimN3LK=nwhnWheVnhw4Ax4KmLWOgA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Subprotocol semantics. How SHOULD/MUST user-agent and server deal with it
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: Thu, 14 Apr 2011 07:19:35 -0000

On 04/14/2011 07:57 AM, Somebody in the thread at some point said:

Hi -

> f) supports multiple subprotocols but Sec-WebSocket-Protocol in request
> didn't contain any of them

> It sounds clear to me that we should drop the request in case f).

Right... whatever the plan was for no explicit protocol being 
negotiated, it no longer makes any sense.

The protocol should always have to be explicitly requested by the client 
even if the server only supports that one, you don't know if a different 
client who assumes it is a different protocol is connecting to you 
otherwise.  There'd be no error and if the protocols were similar the 
failure mode might take a long time to show or be subtle.

-Andy