Re: [hybi] Intermediaries and idle connections (was Re: Technical feedback.)

Justin Erenkrantz <justin@erenkrantz.com> Sun, 31 January 2010 00:58 UTC

Return-Path: <justin.erenkrantz@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 ABF2F3A67B3 for <hybi@core3.amsl.com>; Sat, 30 Jan 2010 16:58:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=-0.024, 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 dtv4LXiFVGew for <hybi@core3.amsl.com>; Sat, 30 Jan 2010 16:58:53 -0800 (PST)
Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id 69A513A67A8 for <hybi@ietf.org>; Sat, 30 Jan 2010 16:58:53 -0800 (PST)
Received: by gxk26 with SMTP id 26so1392686gxk.8 for <hybi@ietf.org>; Sat, 30 Jan 2010 16:59:18 -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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=hBAcKoEYzmMRDGQgIZW3W6+vKq0h22UE2Oz4ZlplOB4=; b=QBukxUPXsfPTjLRWYXGcuc79NXQyDGIIkaXvltWRe45KB+e5/qZX8dcHjT60O/AR6B /LLTAC24a75zBHSjNr+uKLj0OKoVxCVtXXguH7v87NvbBwvczozf/c8v7ozqwYZl3IpR 44TtlWgWexYe9ElV/uwnMAS8V2YrK5Dz8N53Q=
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 :content-transfer-encoding; b=v5HH/32s/DnFrJC3wuTu8t7cNizMRT5SoT5L9zUp90VvCFnE9DUyh9aKu35pNLdpa2 x0TwTzhwtf++TXhZrCNew0nM8VnhQ3dd6f0fIa5SB0dE61G2NzVPQg7g10lC7cT61rWl 8MeJJsg4AgMNrjWzoP4ySu0xcROSxSV5fkvsU=
MIME-Version: 1.0
Sender: justin.erenkrantz@gmail.com
Received: by 10.90.177.9 with SMTP id z9mr2385706age.93.1264899558540; Sat, 30 Jan 2010 16:59:18 -0800 (PST)
In-Reply-To: <D8121C48-82F3-4C87-9A0D-51DC1CBA1593@apple.com>
References: <de17d48e1001280012i2657b587i83cda30f50013e6b@mail.gmail.com> <4B62E516.2010003@webtide.com> <5c902b9e1001290756r3f585204h32cacd6e64fbebaa@mail.gmail.com> <4B636757.3040307@webtide.com> <E379EA13-D58A-4BFB-A62D-2B931A54E276@apple.com> <4B63DD6B.5030803@webtide.com> <E765982E-06B5-48BC-B75D-02E3F9555018@apple.com> <4B64B179.9050502@webtide.com> <5c902b9e1001301600g205fe7cfoc8f314e742ec50c6@mail.gmail.com> <D8121C48-82F3-4C87-9A0D-51DC1CBA1593@apple.com>
Date: Sat, 30 Jan 2010 16:59:18 -0800
X-Google-Sender-Auth: 0755e47007fc70b5
Message-ID: <5c902b9e1001301659w28aca2c8waffc7a1c76024dc6@mail.gmail.com>
From: Justin Erenkrantz <justin@erenkrantz.com>
To: Maciej Stachowiak <mjs@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Intermediaries and idle connections (was Re: Technical feedback.)
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: Sun, 31 Jan 2010 00:58:55 -0000

On Sat, Jan 30, 2010 at 4:48 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> Surely HTTP headers in the handshake are an appropriate place for protocol metadata?

I agree - but, in the current drafts, that's forbidden as you must use
the exact byte sequences specified in the document.  You can't add any
HTTP headers...

According to previous posts, this came from the notion that it is
"best" to treat the HTTP/1.1 upgrade request as a "black box" of bytes
rather than as...a real HTTP/1.1 request that defers to that RFC as to
how it should be interpreted.  There has been significant pushback to
making it a real HTTP request...  And, as Greg has pointed out, by not
permitting any other status codes in a response, it doesn't allow a
server to do primitive SW load-balancing and issue 3xx's to go visit
other servers or do auth before protocol initialization or other
common tricks.

>> Spitballing an idea: if we have some way to multiplex over a single
>> connection (channels, etc.), then we can have a "protocol"
>> meta-channel or similar for exchanging hop-by-hop capabilities.  --
>
> This doesn't help you with detecting unaware intermediaries, or with letting intermediaries participate if you are going over SSL.

Prior to initialization - correct, but this extra channel was only
about what you do after you have successfully initiated the WS
protocol.  -- justin