IETF Logo Mail Archive

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

Justin Erenkrantz <justin@erenkrantz.com> Sat, 30 January 2010 07:15 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 3B86A3A677D for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 23:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.13
X-Spam-Level:
X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=-0.152, 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 DMyQcBxGcmlN for <hybi@core3.amsl.com>; Fri, 29 Jan 2010 23:14:59 -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 75C663A6405 for <hybi@ietf.org>; Fri, 29 Jan 2010 23:14:59 -0800 (PST)
Received: by yxe32 with SMTP id 32so2376017yxe.5 for <hybi@ietf.org>; Fri, 29 Jan 2010 23:15:22 -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=fvd2P2m+a2rkoczodlq+ifgLM3M4lpH7Jlu1d/abe9Y=; b=x4XQp01u9mODDPupm0KAHdeBtzM1wuzDcZwTZZoU2WMkDdCVM/R5SL2pAyBQzfVrUG 78b3y1Tnc2I5XI+8DMqyPmYmyEyBSboz3S/sqOzyCXQ9A2WbRB2JbufK9Q/vW4ECAfPm WwQ6PvdtWdLeFWG7mF8MvJJ+BVHrEmlFCRypY=
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=v1eqEh/Qogr13yA0dQqEcr7H6Fuw0SPJ+/OB/pw41wJlYnOVnXH2m1FwkCr47cJ9+o mxKHDPdGnGFr7pzF1JJvL2HLs4PAkKUe+tIkCQSv0b3AOGaprgVRRYg9C4v7uinG4d8D ffI+rn5hdO5fkCGsa7g6NcTcCNvAeQw2AHG5w=
MIME-Version: 1.0
Sender: justin.erenkrantz@gmail.com
Received: by 10.91.145.11 with SMTP id x11mr1813325agn.86.1264835721926; Fri, 29 Jan 2010 23:15:21 -0800 (PST)
In-Reply-To: <E379EA13-D58A-4BFB-A62D-2B931A54E276@apple.com>
References: <de17d48e1001280012i2657b587i83cda30f50013e6b@mail.gmail.com> <4B625733.2020907@webtide.com> <6.2.5.6.2.20100128225542.06fa8d68@resistor.net> <Pine.LNX.4.64.1001290817520.22020@ps20323.dreamhostps.com> <4B62C5FE.8090904@it.aoyama.ac.jp> <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>
Date: Fri, 29 Jan 2010 23:15:21 -0800
X-Google-Sender-Auth: 559b8efad4f12974
Message-ID: <5c902b9e1001292315r62d68f8fs5143b0d40c3241b7@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: Sat, 30 Jan 2010 07:15:00 -0000

On Fri, Jan 29, 2010 at 10:28 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> both the client and server to know that, and to be able to make certain
> default assumptions, for instance how long the connection is held open even
> if completely idle. Do you have a concrete proposal?

It should be possible to exchange parameters on keep-alive as the
connection is established.  httpd has some extensions that expose
Keep-Alive parameters in an OPTIONS response - serf tries take
advantage of this information as a hint - otherwise, it heuristically
determines the keepalive parameters based upon the default httpd
configs.

My concern is that - a la HTTP - is that you should not conflate
content-related metadata with protocol metadata.  For something akin
to BWTP, that could be exchanged as part of the channel create process
without affecting the content itself.  -- justin

v2.23.0 | Report a Bug | By Email