Re: [hybi] Web sockets and existing HTTP stacks

Pieter Hintjens <ph@imatix.com> Mon, 01 February 2010 10:32 UTC

Return-Path: <pieterh@gmail.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 346AD28C0FE for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 02:32:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 LnfAF1JhjPQD for <hybi@core3.amsl.com>; Mon, 1 Feb 2010 02:32:29 -0800 (PST)
Received: from mail-iw0-f184.google.com (mail-iw0-f184.google.com [209.85.223.184]) by core3.amsl.com (Postfix) with ESMTP id 678E23A67F0 for <hybi@ietf.org>; Mon, 1 Feb 2010 02:32:29 -0800 (PST)
Received: by iwn14 with SMTP id 14so4421439iwn.17 for <hybi@ietf.org>; Mon, 01 Feb 2010 02:32:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=SvsaJDrkenAb6xwDzx1kJMfQHDe2k0XYJVh4xhXsoBg=; b=OOuYdViMhzeK3VoVtLNC9829VOyXGEHGkV6mI8zHvQJxbPQJyuNoDAavRowFSHQSoW JhhxWPczXco4P+aWpdmtaYjN/QODCbEuJ3IUfJxfQXklgDlCas0DDIHKwY9KZqvw/XJY pzXHjMMkbXQAAadFLVyTg3OMhmoanvpMFKzp8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=D5aBEpvPsaC4YAyLCOy87LI2PAEMSJu0Eki0bkaR3CVLPDcDnzXR6Bs2J839Ee3Rmk cWj7En8X1dsQ7PM92mxiS8K5bqVnVjibJp5yYki77HYmxf+/ONt//GKKC7ewlZpbCccJ 6Lpl1QIoxSTQArps0z/OGnbPsnXMofse4xemc=
MIME-Version: 1.0
Sender: pieterh@gmail.com
Received: by 10.231.167.208 with SMTP id r16mr4604660iby.46.1265020379090; Mon, 01 Feb 2010 02:32:59 -0800 (PST)
In-Reply-To: <5A8D0931-23AA-4006-B49C-65F3244B76A1@mnot.net>
References: <557ae280911171402v7546e5e7n93a1e57f87dc10e5@mail.gmail.com> <5c902b9e0912181640n497169cdrfa71f9a2908e6ef3@mail.gmail.com> <20091219005442.GA10949@shareable.org> <4B2C287E.1030006@webtide.com> <Pine.LNX.4.64.1001310835410.3846@ps20323.dreamhostps.com> <5821ea241001311219j111d25a3h27fb2d05a2ece32d@mail.gmail.com> <20100201012914.GC20940@shareable.org> <470737.82505.qm@web95410.mail.in2.yahoo.com> <ad99d8ce1001312340y1056d7f6w2c570bdbb724edb1@mail.gmail.com> <5A8D0931-23AA-4006-B49C-65F3244B76A1@mnot.net>
From: Pieter Hintjens <ph@imatix.com>
Date: Mon, 01 Feb 2010 11:32:39 +0100
X-Google-Sender-Auth: e4b77f321ad33637
Message-ID: <5821ea241002010232g7e78f933nc3539019b6de1b47@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: hybi@ietf.org
Subject: Re: [hybi] Web sockets and existing HTTP stacks
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: Mon, 01 Feb 2010 10:32:30 -0000

On Mon, Feb 1, 2010 at 10:58 AM, Mark Nottingham <mnot@mnot.net> wrote:
> Indeed. HTTP is *designed* to allow upgrades to other protocols. If anyone wants to argue against that, they're more than welcome to come argue that in HTTPbis, although I have a feeling they'll be needing an asbestos suit...

HTTPbis sounds like a fun list.  Clearly since port 80 is often the
only way in or out of a network, upgrades over HTTP are essential for
pragmatic reasons.

Reading the discussion here over the last months, I see three sets of concerns:

1. Concerns about the quality of the web socket protocol spec itself,
which are normal and expected.
2. Concerns about the status of this spec as The Official spec for (?)
bidirectional transport over/beside HTTP.
3. Concerns about the impact that this spec has on existing HTTP stacks.

Clearly these concerns are interconnected, and that is a problem.  Us
server implementors become hypersensitive to the quality of the spec
because it appears to have an excessive sense of status AND it plays
too loose with the contracts we've invested years of work in.

It should be trivial to make Web Sockets work *properly* with the HTTP
upgrade mechanism, at which point these concerns become properly
orthogonal, and we can all relax somewhat.

-Pieter