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: "\"William Chan (陈智昌)\"" <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. >> > >> > >
- Proposal: New Frame Size Text (was: Re: Design Is… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… William Chan (陈智昌)
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… Roberto Peon
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… William Chan (陈智昌)
- Re: Proposal: New Frame Size Text (was: Re: Desig… Martin Thomson
- Re: Proposal: New Frame Size Text (was: Re: Desig… Martin Thomson
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… Martin Thomson
- Re: Proposal: New Frame Size Text (was: Re: Desig… William Chan (陈智昌)
- Re: Proposal: New Frame Size Text (was: Re: Desig… William Chan (陈智昌)
- Re: Proposal: New Frame Size Text (was: Re: Desig… Poul-Henning Kamp
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… Roberto Peon
- Re: Proposal: New Frame Size Text (was: Re: Desig… William Chan (陈智昌)
- Re: Proposal: New Frame Size Text (was: Re: Desig… Roberto Peon
- Re: Proposal: New Frame Size Text (was: Re: Desig… Poul-Henning Kamp
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text Martin J. Dürst
- Re: Proposal: New Frame Size Text (was: Re: Desig… Roberto Peon
- Re: Proposal: New Frame Size Text (was: Re: Desig… Martin Thomson
- Re: Proposal: New Frame Size Text (was: Re: Desig… Roberto Peon
- Re: Proposal: New Frame Size Text Poul-Henning Kamp
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… William Chan (陈智昌)
- Re: Proposal: New Frame Size Text (was: Re: Desig… Ben Niven-Jenkins
- Re: Proposal: New Frame Size Text (was: Re: Desig… Poul-Henning Kamp
- Re: Proposal: New Frame Size Text (was: Re: Desig… William Chan (陈智昌)
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… Poul-Henning Kamp
- Re: Proposal: New Frame Size Text (was: Re: Desig… Martin Thomson
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… James M Snell
- Re: Proposal: New Frame Size Text (was: Re: Desig… Patrick McManus