Re: [hybi] Extensibility mechanisms?

Adam Barth <ietf@adambarth.com> Thu, 22 July 2010 20:25 UTC

Return-Path: <ietf@adambarth.com>
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 8E3D63A687A for <hybi@core3.amsl.com>; Thu, 22 Jul 2010 13:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.659
X-Spam-Level:
X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 TVO+D7mbppKe for <hybi@core3.amsl.com>; Thu, 22 Jul 2010 13:25:48 -0700 (PDT)
Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 9185C3A6829 for <hybi@ietf.org>; Thu, 22 Jul 2010 13:25:48 -0700 (PDT)
Received: by pxi20 with SMTP id 20so4672932pxi.31 for <hybi@ietf.org>; Thu, 22 Jul 2010 13:26:06 -0700 (PDT)
Received: by 10.114.160.2 with SMTP id i2mr3684389wae.110.1279830364581; Thu, 22 Jul 2010 13:26:04 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id n32sm87869077wag.11.2010.07.22.13.26.03 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 13:26:03 -0700 (PDT)
Received: by iwn38 with SMTP id 38so8887859iwn.31 for <hybi@ietf.org>; Thu, 22 Jul 2010 13:26:02 -0700 (PDT)
Received: by 10.231.32.12 with SMTP id a12mr2405216ibd.134.1279830362232; Thu, 22 Jul 2010 13:26:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.143.145 with HTTP; Thu, 22 Jul 2010 13:25:42 -0700 (PDT)
In-Reply-To: <4C48A468.3040009@caucho.com>
References: <h2w5c902b9e1004152345j992b815bz5f8d38f06a19181a@mail.gmail.com> <4BCB7829.9010204@caucho.com> <Pine.LNX.4.64.1004182349240.751@ps20323.dreamhostps.com> <4BCC0A07.9030003@gmx.de> <Pine.LNX.4.64.1004190753510.23507@ps20323.dreamhostps.com> <4BCC111C.90707@gmx.de> <Pine.LNX.4.64.1004190837570.23507@ps20323.dreamhostps.com> <4BCC204D.30004@gmx.de> <z2gad99d8ce1004190822ne4dd36b6v54d63efcc448e840@mail.gmail.com> <Pine.LNX.4.64.1007202204270.7242@ps20323.dreamhostps.com> <AANLkTikkfdlUxQ0MGNvVQKa5gfovkGHWdCgyN9juKSQJ@mail.gmail.com> <4C462F9E.9030207@caucho.com> <Pine.LNX.4.64.1007212153110.7242@ps20323.dreamhostps.com> <AANLkTiku76oSucTNDFdwgsFBNFa_cCpC-YktTnMfX47-@mail.gmail.com> <4C479130.4020500@caucho.com> <AANLkTikLDjBP-Xs5t6TxmJuq4nG8jwThQ=n34B4cEmup@mail.gmail.com> <4C479CE4.6070805@caucho.com> <AANLkTims1er0Rbv0ysP4gRs1Kd0He8hapHeJ3nON=JQa@mail.gmail.com> <4C47C5B0.3030006@caucho.com> <AANLkTi=ND-FOH8OoD=TCbiyeSZ-h0LhxQBXN5w-2hfvj@mail.gmail.com> <4C48A468.3040009@caucho.com>
From: Adam Barth <ietf@adambarth.com>
Date: Thu, 22 Jul 2010 13:25:42 -0700
Message-ID: <AANLkTikeLr325F03bowJu7NeHEqY_+OzEnQcrxHbCwhW@mail.gmail.com>
To: Scott Ferguson <ferg@caucho.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Extensibility mechanisms?
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: Thu, 22 Jul 2010 20:25:49 -0000

On Thu, Jul 22, 2010 at 1:04 PM, Scott Ferguson <ferg@caucho.com> wrote:
> The issue is the number of request/response before the initial payload is
> sent. If we require the client to wait to validate the server before it can
> send its payload, the initial performance will be slower than a HTTP POST.
>
> That delay may be perfectly acceptable, but some people have raised it as an
> issue in the group. I'm fine with the delay myself, but I think it should be
> resolved.

We need to know the server understands web sockets before spamming
them with attacker-controlled bytes.  If we don't, we'll repeat the
long and tragic history of cross-protocol vulnerabilities caused by
HTTP POST.

This is a hard requirement.

Adam