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

Justin Erenkrantz <justin@erenkrantz.com> Sun, 31 January 2010 00:37 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 4BCA73A683F for <hybi@core3.amsl.com>; Sat, 30 Jan 2010 16:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level:
X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 3qZ12vfylBWI for <hybi@core3.amsl.com>; Sat, 30 Jan 2010 16:37:09 -0800 (PST)
Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.210.194]) by core3.amsl.com (Postfix) with ESMTP id D3E223A67A8 for <hybi@ietf.org>; Sat, 30 Jan 2010 16:37:08 -0800 (PST)
Received: by yxe32 with SMTP id 32so32269yxe.5 for <hybi@ietf.org>; Sat, 30 Jan 2010 16:37:34 -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; bh=LL/OoNm0otLW8CN540ZkNhvR8DyccyXgnDk6tGwitO4=; b=jHI8t1/9iOJEkLCPhElLdkDi96MK4FmPpXUfb2ee9Cc75Y8mfvz78K6EgKWgW5VcMU PXr44tkGqzA6uFilbz/UHmjwR2VN1Y1zYnXW/+MuyQwd6l1QRuB0c65mlTbuKIEkl0q5 u7DABXsRLo/fIwHk7ULknCPVl2G1r6rMGGCD0=
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=PegOWZbjwkiu3266wJnL8YGAnGEshFCPfodtzJ2zbPzOOAYAzji+AtFCAx8KMLvS5Z 4BZpMXpDI8TvjIpzVa+WazcuSOvEGJuCE/m5W0Y6U/lm6gU2dWG2W9QA1d/OKE1+tVZN fIDfva/etXu8MzH/XHwlOexBWBdZMui+W0i9U=
MIME-Version: 1.0
Sender: justin.erenkrantz@gmail.com
Received: by 10.90.42.3 with SMTP id p3mr2375127agp.98.1264898252708; Sat, 30 Jan 2010 16:37:32 -0800 (PST)
In-Reply-To: <2D6C6FEE-2019-44E4-BD82-7BF68B30A518@apple.com>
References: <de17d48e1001280012i2657b587i83cda30f50013e6b@mail.gmail.com> <Pine.LNX.4.64.1001291134350.22020@ps20323.dreamhostps.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> <2D6C6FEE-2019-44E4-BD82-7BF68B30A518@apple.com>
Date: Sat, 30 Jan 2010 16:37:32 -0800
X-Google-Sender-Auth: 54db134a2d42a43d
Message-ID: <5c902b9e1001301637q27028696o8ca9220c52a235e1@mail.gmail.com>
From: Justin Erenkrantz <justin@erenkrantz.com>
To: Maciej Stachowiak <mjs@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"
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:37:10 -0000

On Sat, Jan 30, 2010 at 4:23 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> I don't know whether the hardcoded handshake format it the right tradeoff
> overall. But reasons have been given for it, so I don't think its fair to
> call it "just for giggles". If you can explain how making the HTTP upgrade
> handshake more flexible would help solve specific problems, then it would be
> easier to do a cost-benefit analysis.

For serf (a client library), it can't (easily) produce the exact byte
sequence for the Upgrade request as dictated by the latest drafts
because it has its own optimizations for ordering of the HTTP/1.1
headers and such.  So, if the server is looking for a specific byte
sequence, serf isn't going to produce it in anything close to a
reasonable way.

On the server side, I can't even begin to think of the contortions
we'd have to add to httpd to get it to recognize a specific byte
pattern *on port 80*.  From past emails, I know that Greg had to add
lots of hacks to Jetty to add support for that byte pattern.  I
wouldn't even want to go down that route for httpd - especially when
our philosophy is "leinent in what you accept, strict in what you
send."  So, httpd would likely only do much the same as serf - if the
method is right and the proper Upgrade headers are somewhere in the
request, then it'd perform the upgrade.  -- justin