Re: [hybi] workability (or otherwise) of HTTP upgrade

Jack Moffitt <jack@collecta.com> Thu, 09 December 2010 04:09 UTC

Return-Path: <metajack@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 5BE193A66B4 for <hybi@core3.amsl.com>; Wed, 8 Dec 2010 20:09:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.357
X-Spam-Level:
X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
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 UZd9hl+Kbss9 for <hybi@core3.amsl.com>; Wed, 8 Dec 2010 20:09:27 -0800 (PST)
Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 5FCC33A6968 for <hybi@ietf.org>; Wed, 8 Dec 2010 20:09:27 -0800 (PST)
Received: by bwz8 with SMTP id 8so2300368bwz.38 for <hybi@ietf.org>; Wed, 08 Dec 2010 20:10:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=HpKuTKSmjV02lxBrwqeUmIeVhZg6GZ2TJo01ix3hsms=; b=b6kq6v3SoDliF41gixN/5KtyvlZVX1B9Z78vZm6Q2FOHU8xXvkxHkk49aISf7EUxIY hak+namrqX3usQKJ1vsDT3xu9MqfpPCCZQXTE2OuuMWLPbg2T3i2T04rBNNebCoL5BnL paaIRFvkipJWQpCrO1JPMLch5ZuG0Cfe1LZEI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=tgX2g20gHeKWAGYmx2kAmNIQVyIai4pQnm+TGSRGmZj/GS//7Mh8aA08FNMpE3HE8r 26fs3YLl0GZAJiZKp0F+S77ucoiTj2TakKMpiIbHGskv7oGLArbAzXpe3rtzNORCNgY8 iabLEPsrk3zFTuPR7BSiJ7VGhezBAnnc5HQ6I=
MIME-Version: 1.0
Received: by 10.204.74.219 with SMTP id v27mr2755703bkj.178.1291867855043; Wed, 08 Dec 2010 20:10:55 -0800 (PST)
Sender: metajack@gmail.com
Received: by 10.204.119.211 with HTTP; Wed, 8 Dec 2010 20:10:54 -0800 (PST)
In-Reply-To: <25E88686-BE24-4EFD-8330-25916C891664@mnot.net>
References: <F4D1B715-3606-4E9A-BFB2-8B7BC11BE331@mnot.net> <57D4B885-B1D8-482F-8747-6460C0FFF166@apple.com> <37A00E8D-B55C-49AD-A85C-A299C80FFF17@mnot.net> <4F2580A7-79C2-4B0A-BCE5-7FB6D9AA0ED7@apple.com> <BB31C4AB95A70042A256109D461991260583956C@XCH117CNC.rim.net> <EA41A6C7-971C-4EC8-AA6F-96363B7FDC4C@gmail.com> <73E53F19-E0E7-4ADB-B765-ABAF0B4A6736@mnot.net> <r2f0g6d7bj770kg0db5ptr027ninmckns8@hive.bjoern.hoehrmann.de> <20C2FBB9-901F-4235-AF23-EC8262585905@mnot.net> <mgj0g6hseqb6j92au80f8d1ook058nb33m@hive.bjoern.hoehrmann.de> <25E88686-BE24-4EFD-8330-25916C891664@mnot.net>
Date: Wed, 08 Dec 2010 21:10:54 -0700
X-Google-Sender-Auth: AgECoYG5Cv0aG91EnPSSo67rypI
Message-ID: <AANLkTi=k0Czvm_pW=N3zPAGZdKyqZGduGJUp8dk3PByX@mail.gmail.com>
From: Jack Moffitt <jack@collecta.com>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: hybi HTTP <hybi@ietf.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
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, 09 Dec 2010 04:09:28 -0000

One path is to combine the separate port idea along with the
encryption based approach. On the WebSocket port, you could avoid all
the intermediary issues, but perhaps be limited by firewalls.
However, you would not need any obfuscation and could easily use
sendfile().  On the TLS port you use NPN to get a WebSocket that is
not going to cause security problems with intermediaries.

For the short term, we get WebSocket on the port with the highest
success rate, and in the long term, we have firewalls accepting the
new port as killer applications make people care.

If we're going to lose the sendfile(), why not go the rest of the way?
Or is there something I'm missing in the port 80 but just XORed case?

jack.