Re: Proposal: New Frame Size Text (was: Re: Design Issue: Frame Size Items)

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Mon, 13 May 2013 19:59 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6F021F85E8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 12:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.902
X-Spam-Level:
X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnM+-8fMls9H for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 12:59:12 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id B49EC21F8BBA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 13 May 2013 12:59:12 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Ubysk-0000wt-F8 for ietf-http-wg-dist@listhub.w3.org; Mon, 13 May 2013 19:58:02 +0000
Resent-Date: Mon, 13 May 2013 19:58:02 +0000
Resent-Message-Id: <E1Ubysk-0000wt-F8@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <ben@niven-jenkins.co.uk>) id 1UbysY-0000wA-N5 for ietf-http-wg@listhub.w3.org; Mon, 13 May 2013 19:57:50 +0000
Received: from mailex.mailcore.me ([94.136.40.61]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <ben@niven-jenkins.co.uk>) id 1UbysV-0003qT-Cd for ietf-http-wg@w3.org; Mon, 13 May 2013 19:57:50 +0000
Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.2]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1Ubys8-0001jG-Vp; Mon, 13 May 2013 20:57:25 +0100
References: <CABP7RbcfTjN5QFFuGm-P-rQMpAR3FGSC58WCy3qKn+29YCjn+w@mail.gmail.com> <CAA4WUYiwNSzvrY1LF_Sex_82TSDwMbTvYqo7LyKfBAOu0j4pfQ@mail.gmail.com> <CABP7RbdqnH0JK-UaMiaR5rLvZo8txywEcXXSUXa_y95hrLC5yA@mail.gmail.com> <CABP7Rbd-VfTFYurZ-JEKjHKOeKvZCKoYLGMXf+0mi-_wbdKYqA@mail.gmail.com> <CAA4WUYgfu=rcji-bdxNPsE9KCE4T67+vN9b0iojnvycx5R-StA@mail.gmail.com> <CABkgnnX=AemYGrBzWGX1VEUgKKrk+hR6YV0jg9qVMSdPiimBAA@mail.gmail.com> <CAFA1p16FHaSf7b1=mhe_Cb=ZqV1m0HVwkQNdW+pkJ0OkA9L-5A@mail.gmail.com> <CAP+FsNdifoF3aqQLB-EZjYqL3O2_uNEmNJ_+zAktu9zapKmT7w@mail.gmail.com> <CABP7RbcF3VXuhvP5StN9hHVj4K-2WMvBr37ur3iHmH-=2WAbHw@mail.gmail.com> <CAA4WUYgFccqU5-65mFPF_3i4OOROZQCdS+tEUeDMk4HP4JJX5Q@mail.gmail.com> <CABP7RbcQMEhu9ciuTQoR1dRw3UiUB=E_AeMjaNrhFgMPmmi+EQ@mail.gmail.com> <CAA4WUYjFgJ28O5Jb58a5eodJMWe+CSe18Ow1wpETWJcjmedXRQ@mail.gmail.com> <CABP7RbdnnCiDSDt5CwPfRYx-BGgz8eoMUDa2J4xaWztHkCbe+w@mail.gmail.com> <CAP+FsNfHEUsdqQaAg8-g6vLb=AikHQG4Y5BywJ2w1FQEon+LrQ@mail.gmail.com> <CABkgnnXVMn L=i2p_mDzcWLP0TNpV_wp7XhsuOTA+Tayv1aBv3Q@mail.gmail.com> <CAP+FsNda_dzPqe1+e3DJsAtvi=xRH=dtdr0tnOJvCoWdF6MCjg@mail.gmail.com> <CABP7RbcYMzGEWG3yL-sRA+HHsO+7JcMmRkHU=tvQW62k72XeCQ@mail.gmail.com> <CAA4WUYijhOjJ1fo7VhUD6ezsOGO9P5q9M=q_p8J3CiDawG3bjg@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAA4WUYijhOjJ1fo7VhUD6ezsOGO9P5q9M=q_p8J3CiDawG3bjg@mail.gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-0B3C7ED0-C583-41B8-8D65-D4E8074FB946
Content-Transfer-Encoding: 7bit
Message-Id: <4137D4E7-F0A9-4F83-8B13-07FC46E5B863@niven-jenkins.co.uk>
Cc: James M Snell <jasnell@gmail.com>, Roberto Peon <grmocg@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Hasan Khalil <hkhalil@google.com>
X-Mailer: iPhone Mail (10B329)
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Date: Mon, 13 May 2013 20:57:21 +0100
To: =?utf-8?Q?"William_Chan_=28=E9=99=88=E6=99=BA=E6=98=8C=29"?= <willchan@chromium.org>
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Received-SPF: none client-ip=94.136.40.61; envelope-from=ben@niven-jenkins.co.uk; helo=mailex.mailcore.me
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-2.502, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: maggie.w3.org 1UbysV-0003qT-Cd 2ffc3454e4cc4b56fed69b36b22c4847
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Proposal: New Frame Size Text (was: Re: Design Issue: Frame Size Items)
Archived-At: <http://www.w3.org/mid/4137D4E7-F0A9-4F83-8B13-07FC46E5B863@niven-jenkins.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17971
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

<hat="proxy implementer">
I can see utility in recommending (or even mandating) that certain header fields be placed at the beginning of a HEADERS frame for expedited processing by an intermediary.

I'd expect the set of headers fields to be a small finite set (if folks later find utility in always placing other header fields early in HEADERS frames they can always publish best practice guidance to that effect). 

I don't see a use case for anything more complicated than that. 

HTH
Ben

On 13 May 2013, at 19:03, William Chan (陈智昌) <willchan@chromium.org> wrote:

> I guess I didn't really buy the argument about breaking headers frames up into smaller chunks. I kinda feel like, at least in typical HTTP semantics use cases, you need the majority of headers before you can handle/route anyway, so this chunking seems kinda ineffective.
> 
> My stance is this is added complexity to the spec. If we want more complexity, then we need implementers asking for this. I'd like to see a proxy/server implementer (PHK has already voiced some support) champion this. What do others like Willy/Amos/Jeff/etc think about this proposal? If proxy/server implementers think this is worth the extra complexity in the spec, then fine by me.
> 
> 
> On Sat, May 11, 2013 at 2:21 PM, James M Snell <jasnell@gmail.com> wrote:
>> I generally find it safer not to make any assumptions here about what
>> any given random implementation will or will not do. The best we can
>> do is provide some degree of protection against abuse in the protocol
>> definition itself. It doesn't have to be perfect, by any means, but it
>> does have to be somewhat reasonable. I'm perfectly fine with not
>> including HEADERS/PUSH_PROMISE in flow control but we ought to at
>> least place limits on exactly how much data is being passed in those
>> frames at any given time -- precisely because we don't know exactly
>> how those are going to end up being used long term and we do not want
>> to inadvertently encourage abuse.
>> 
>> If you want a sender to still be able to send HEADERS frames even if
>> the window size is 0 (or lower than we can reasonably encode a minimal
>> header block), then a compromise here is pretty simple:
>> 
>> For data frames, max frame size is min(WINDOW_SIZE, 65k) ...
>> For control frames (including HEADERS), max frame size is max(4k,
>> min(WINDOW_SIZE, 65k)) ...
>> 
>> This ought to give us a reasonable range to work within. It basically
>> just states that while control frames are not subject to flow control,
>> when constructing headers frames, the sender needs to take into
>> consideration whatever load the recipient may currently be
>> experiencing as expressed through flow control.
>> 
>> 
>> 
>> On Fri, May 10, 2013 at 8:15 PM, Roberto Peon <grmocg@gmail.com> wrote:
>> > For implementations that don't care about memory efficiency, you're right
>> > that they'll unencode the huffman-encoded strings. :)
>> >
>> > The majority of non-efficiency-oriented APIs I've used treated the overhead
>> > of HTTP and IO as insignificant, and likely just wouldn't care about this at
>> > all.
>> > -=R
>> >
>> >
>> > On Fri, May 10, 2013 at 8:01 PM, Martin Thomson <martin.thomson@gmail.com>
>> > wrote:
>> >>
>> >> On 10 May 2013 18:30, Roberto Peon <grmocg@gmail.com> wrote:
>> >> > The memory needed for header interpretation will, for a decent
>> >> > implementation, be at worst the sum of the size of the compression
>> >> > context
>> >> > and the size of the receive buffer-- it will not expand once
>> >> > decompressed
>> >> > unless a lot of useless copying is being done.
>> >>
>> >> I was going to say the same thing until I realized that most APIs will
>> >> be forced to decode Huffman-encoded strings to present.  Some
>> >> implementations might avoid this entirely, others might defer
>> >> decompression, or something along those lines, but there is probably
>> >> going to be at least some exposure to the decompressed data.
>> >
>> >
>