Re: [hybi] Client offers invalid WS protocols, what must the server do? 101???

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 30 August 2011 11:15 UTC

Return-Path: <alexey.melnikov@isode.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 5F5E321F8C08 for <hybi@ietfa.amsl.com>; Tue, 30 Aug 2011 04:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.396
X-Spam-Level:
X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB+M19If3dW8 for <hybi@ietfa.amsl.com>; Tue, 30 Aug 2011 04:15:36 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id D779E21F8AFA for <hybi@ietf.org>; Tue, 30 Aug 2011 04:15:35 -0700 (PDT)
Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <TlzGrgBpJlnf@rufus.isode.com>; Tue, 30 Aug 2011 12:17:02 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4E5CC6A7.7030304@isode.com>
Date: Tue, 30 Aug 2011 12:16:55 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Iñaki Baz Castillo <ibc@aliax.net>
References: <CALiegfkC9dLOnLfSQApE9OjoSV1RXT7cTumZ6+yCR1tWo_cvmw@mail.gmail.com> <4E5CBEA0.2080605@isode.com> <CALiegfn3dPyZMR3ZZ3CtwOeAmC4sxd0=kos4Z82B2qeh_aZASQ@mail.gmail.com>
In-Reply-To: <CALiegfn3dPyZMR3ZZ3CtwOeAmC4sxd0=kos4Z82B2qeh_aZASQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-transfer-encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101???
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: Tue, 30 Aug 2011 11:15:36 -0000

Iñaki Baz Castillo wrote:

>2011/8/30 Alexey Melnikov <alexey.melnikov@isode.com>:
>  
>
>>Subprotocols are optional in the WebSocket protocols. So the client can't
>>say that a particular extension is required. It can only close the
>>connection after the handshake completes without it.
>>    
>>
>
>That does not answer to all my previous rationale. To summarize:
>
>Why should the WS server accept (so 101) a WS handshake when the
>client offers WS protocols NOT supported by the WS server? I don't
>mean that the client does not provide Sec-WebSocket-Protocol header, I
>mean that the client *provides * it, but offered protocols are NOT
>supported by the server.
>
Because by definition the list of extensions in the 
Sec-WebSocket-Protocol header field is optional for the server to 
support. If we want to have "you must support this extension, or we fail 
the handshake", then we need another mechanism to tell the server.

>Why should the server then accept such WS
>session? what are they supposed to speak? IMHO it's really clear that
>the server should not accept the WS handshake.
>  
>