Re: [hybi] Handshake was: The WebSocket protocol issues.

Willy Tarreau <w@1wt.eu> Wed, 29 September 2010 20:44 UTC

Return-Path: <w@1wt.eu>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F278F3A6D08 for <hybi@core3.amsl.com>; Wed, 29 Sep 2010 13:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.746
X-Spam-Level:
X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGw8CAXPSn2i for <hybi@core3.amsl.com>; Wed, 29 Sep 2010 13:44:41 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id 68A0C3A6C84 for <hybi@ietf.org>; Wed, 29 Sep 2010 13:44:40 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id o8TKjIeR010228; Wed, 29 Sep 2010 22:45:18 +0200
Date: Wed, 29 Sep 2010 22:45:18 +0200
From: Willy Tarreau <w@1wt.eu>
To: Maciej Stachowiak <mjs@apple.com>
Message-ID: <20100929204518.GD10026@1wt.eu>
References: <20100928052501.GD12373@1wt.eu> <CA8029B0-71A3-44ED-88C6-934FE833BBA2@apple.com> <AANLkTim+fXj-h6OS3OdcfVfh3Q1UwxD8NLVawb=AWHX+@mail.gmail.com> <4FAC5C93-9BDF-4752-AFBC-162D718397AB@apple.com> <AANLkTikcH1W3bQwumqHbe-Yqa3XdoJqCa2b-mZuvoQ7g@mail.gmail.com> <9746E847-DC8B-45A7-ADF3-2ADB9DA7F82E@apple.com> <AANLkTik9igUwoxVrktoBoZrPoUW=Tjh7HyVbGJgQYes-@mail.gmail.com> <9F595226-FA0A-4C38-A6D0-0F4214BD7D21@apple.com> <20100929171550.GB8583@1wt.eu> <D82A525D-5F37-4392-AE8A-A5246E5694F3@apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D82A525D-5F37-4392-AE8A-A5246E5694F3@apple.com>
User-Agent: Mutt/1.4.2.3i
Cc: hybi <hybi@ietf.org>
Subject: Re: [hybi] Handshake was: The WebSocket protocol issues.
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 29 Sep 2010 20:44:43 -0000

On Wed, Sep 29, 2010 at 12:33:05PM -0700, Maciej Stachowiak wrote:
> > Except that you have the Upgrade header which requires a 101 in
> > response. A normal HTTP server will either :
> >  - ignore the Upgarde and return a classical code (200, 404, 403, ...)
> >  - consider the Upgrade header and either return 101 because it matches
> >    the protocol it supports (WebSocket) or return an error code because
> >    it does not support the WS protocol.
> 
> A standalone WebSocket server may well ignore the presence/absence of the Upgrade header, since performing the rest of the handshake does not depend on it in any way. Since checking it is not technologically required, it's likely some servers won't check it.

OK now I see your point. However I disagree with the need to protect
such a broken implementation. We're back to the "and what if the
server-side implementation is buggy ?". A publicly accessible server
returning 101 to random requests will just get tons of unwanted requests
from random HTTP scans which will cause it major trouble anyway. The
presence of the Upgrade header *is* the only element that can dictate
a valid response. However I agree that the handshake should ensure
that a client can quickly escape from such a broken implementation,
the same way as right now a browser should reject responses which do
not look like HTTP.

Regards,
Willy