IETF Logo Mail Archive

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

Iñaki Baz Castillo <ibc@aliax.net> Tue, 30 August 2011 11:10 UTC

Return-Path: <ibc@aliax.net>
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 59C1B21F8C43 for <hybi@ietfa.amsl.com>; Tue, 30 Aug 2011 04:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.646
X-Spam-Level:
X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 kgVXUhdJ9s4U for <hybi@ietfa.amsl.com>; Tue, 30 Aug 2011 04:10:23 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C901321F8C44 for <hybi@ietf.org>; Tue, 30 Aug 2011 04:10:23 -0700 (PDT)
Received: by qwc23 with SMTP id 23so4581184qwc.31 for <hybi@ietf.org>; Tue, 30 Aug 2011 04:11:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.65.85 with SMTP id h21mr43810qci.46.1314702693573; Tue, 30 Aug 2011 04:11:33 -0700 (PDT)
Received: by 10.229.219.141 with HTTP; Tue, 30 Aug 2011 04:11:33 -0700 (PDT)
In-Reply-To: <4E5CBEA0.2080605@isode.com>
References: <CALiegfkC9dLOnLfSQApE9OjoSV1RXT7cTumZ6+yCR1tWo_cvmw@mail.gmail.com> <4E5CBEA0.2080605@isode.com>
Date: Tue, 30 Aug 2011 13:11:33 +0200
Message-ID: <CALiegfn3dPyZMR3ZZ3CtwOeAmC4sxd0=kos4Z82B2qeh_aZASQ@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: text/plain; charset="UTF-8"
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:10:24 -0000

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

-- 
Iñaki Baz Castillo
<ibc@aliax.net>

v2.23.0 | Report a Bug | By Email