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

Greg Wilkins <gregw@webtide.com> Tue, 07 December 2010 11:07 UTC

Return-Path: <gregw@intalio.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 160B73A6961 for <hybi@core3.amsl.com>; Tue, 7 Dec 2010 03:07:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.823
X-Spam-Level:
X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 H6dBotdvuUsY for <hybi@core3.amsl.com>; Tue, 7 Dec 2010 03:07:52 -0800 (PST)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 0F3B93A6949 for <hybi@ietf.org>; Tue, 7 Dec 2010 03:07:51 -0800 (PST)
Received: by qwg5 with SMTP id 5so12462148qwg.31 for <hybi@ietf.org>; Tue, 07 Dec 2010 03:09:17 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.174.8 with SMTP id r8mr5630088qaz.332.1291720156962; Tue, 07 Dec 2010 03:09:16 -0800 (PST)
Sender: gregw@intalio.com
Received: by 10.220.167.203 with HTTP; Tue, 7 Dec 2010 03:09:16 -0800 (PST)
In-Reply-To: <C51C08FD-989E-43AC-A17B-EA4483CC2F9C@mnot.net>
References: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com> <20101126000352.ad396b9a.eric@bisonsystems.net> <AANLkTimzQyG4hugOvHqoNrBrZFA4fGbGXQ7MZ2i+68dO@mail.gmail.com> <BB947F6D-15AA-455D-B830-5E12C80C1ACD@mnot.net> <81870DB1-B177-4253-8233-52C4168BE99D@apple.com> <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> <C51C08FD-989E-43AC-A17B-EA4483CC2F9C@mnot.net>
Date: Tue, 07 Dec 2010 12:09:16 +0100
X-Google-Sender-Auth: IOhXXuR6CVyBYExddcvs9SViyGU
Message-ID: <AANLkTin2ZqsLxCe-oQfY7e5nFOP0P5adsQXFZ07PKb04@mail.gmail.com>
From: Greg Wilkins <gregw@webtide.com>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: hybi HTTP <hybi@ietf.org>, 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: Tue, 07 Dec 2010 11:07:53 -0000

On 7 December 2010 11:53, Mark Nottingham <mnot@mnot.net> wrote:
> I fully agree we need to unblock this discussion and ship a protocol.
> I'm trying to understand why people are digging in their heels on a
> design that's supposed to be helping server deployment, when
> AFAICT the server folks are telling them it's not workable.


>From my point of view, the only things in play that are not workable
are the unframed bytes in the current draft and the bogus hosts in
adam/erics proposal.

But from a server implementers point of view, both CONNECT and
GET+Upgrade+Hello are workable handshakes, so I'd really like to see a
draft based on either of them, but with the unframed bytes and space
encoding strangeness removed, maybe also with the robust framing
(invert FIN bit) and Hello frames used.      Either one has hurdles to
overcome, but they can hardly be worse than what we currently have.

My preference is to come up with a draft based on GET+Upgrade+Hell,
but the browser vendors appear more included to go with a CONNECT
bases solution, so if that's what we need to do to get rid of the
deployed -76 implementations, then I think it is a good next step.
The -76 implementations violate HTTP spec to a much greater degree
than the expressed concerns about CONNECT


cheers