Re: [hybi] Impact of mandatory chunking (was Re: Background info: Properties of sendfile())

Maciej Stachowiak <mjs@apple.com> Fri, 06 August 2010 21:53 UTC

Return-Path: <mjs@apple.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 9F53C3A688D for <hybi@core3.amsl.com>; Fri, 6 Aug 2010 14:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.534
X-Spam-Level:
X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ll7PbbOJq5KN for <hybi@core3.amsl.com>; Fri, 6 Aug 2010 14:53:31 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id C7B073A67D4 for <hybi@ietf.org>; Fri, 6 Aug 2010 14:53:31 -0700 (PDT)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id AC30CA7AAE36 for <hybi@ietf.org>; Fri, 6 Aug 2010 14:54:03 -0700 (PDT)
X-AuditID: 11807137-b7c08ae00000377a-9e-4c5c847b27a0
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id B0.38.14202.B748C5C4; Fri, 6 Aug 2010 14:54:03 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.151.100.119] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L6R00D4C3I24U40@elliott.apple.com> for hybi@ietf.org; Fri, 06 Aug 2010 14:54:03 -0700 (PDT)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <AANLkTin+GJSDVdfDXmov5aPeTKeaB7=Aa_uZxcMsPW9o@mail.gmail.com>
Date: Fri, 06 Aug 2010 14:54:02 -0700
Message-id: <3CD6099C-B932-476A-893E-83E05DC5C624@apple.com>
References: <4C5B1695.6070704@gmx.de> <F8E2F702-9F74-4316-B3B2-D5A731409ABF@apple.com> <4C5B2029.90403@gmx.de> <AANLkTim1WeCRfcPxXUNQcVhb4+t_TtDQDv2bXaxOQ=bk@mail.gmail.com> <01098AD0-FBF4-4A61-B565-947C95722BAA@apple.com> <AANLkTi=qQSND5BvUP5+P=wJ7E8SG6NncGZH8U8+VYwZ0@mail.gmail.com> <20100806004907.GF27827@shareable.org> <C0FC87B7-C51C-4B36-BC16-DBDB0B00A20F@gbiv.com> <20100806012845.GI27827@shareable.org> <AANLkTimuvuj87qwQi_1Gjg47-gGrCsDCQ5TDd5zvOw1N@mail.gmail.com> <20100806062928.GF20057@1wt.eu> <AANLkTimUkx8_Ssiuh4vJsgiQb2xmUzr5uAb-TgG=bjyh@mail.gmail.com> <F6D37A7E-C176-4F79-962D-7DF61FB16492@apple.com> <AANLkTin+GJSDVdfDXmov5aPeTKeaB7=Aa_uZxcMsPW9o@mail.gmail.com>
To: Jack Moffitt <jack@collecta.com>
X-Mailer: Apple Mail (2.1081)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: "Roy T. Fielding" <fielding@gbiv.com>, "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Impact of mandatory chunking (was Re: Background info: Properties of sendfile())
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: Fri, 06 Aug 2010 21:53:32 -0000

On Aug 6, 2010, at 2:14 PM, Jack Moffitt wrote:

>> It's not only the sender and intermediaries that are affected by mandatory chunking. The receiver is affected too. In the case of the browser as receiver, it is highly valuable to have the length up front, so the browser can either pre-allocate a memory buffer of the appropriate size, or decide to start spooling to disk right away if it knows the message will be too large to fit in memory. I imagine this will be useful in at least some cases of the server as receiver too.
> 
> Having a length is orthogonal to chunking. There's little reason not
> to include it with the first chunk when it is known. Several of the
> proposals have added that now.
> 
> If the field is dynamic and we have the machinery for chunking, then
> everything is possible. It becomes only a question of whether both
> methods will be reliably implemented. It seems feasible to believe
> that they will, and so I hope everyone will be satisfied by this
> compromise.

I agree that supporting both chunking and large lengths is reasonable.

Regards,
Maciej