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

William Chan (陈智昌) <willchan@chromium.org> Mon, 13 May 2013 18:05 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 0EDBB21F8D00 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 11:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.676
X-Spam-Level:
X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 7Wvq3aUlu7AJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 13 May 2013 11:05:20 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3B921F854E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 13 May 2013 11:05:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Ubx6V-0004ej-Qs for ietf-http-wg-dist@listhub.w3.org; Mon, 13 May 2013 18:04:07 +0000
Resent-Date: Mon, 13 May 2013 18:04:07 +0000
Resent-Message-Id: <E1Ubx6V-0004ej-Qs@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1Ubx6K-0004dz-1m for ietf-http-wg@listhub.w3.org; Mon, 13 May 2013 18:03:56 +0000
Received: from mail-qa0-f51.google.com ([209.85.216.51]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1Ubx6I-0008Rm-Rf for ietf-http-wg@w3.org; Mon, 13 May 2013 18:03:56 +0000
Received: by mail-qa0-f51.google.com with SMTP id hu16so1552150qab.10 for <ietf-http-wg@w3.org>; Mon, 13 May 2013 11:03:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ShhcE8vTVFnX9qMoN3gVMD7+mn1kE4aglRDFA2bGfUU=; b=jLUumpqZ/tYZDCSYda36SL+fQVIuFsF4Q4wE4lzjpeD0z25VsVWuJ06QxVV6XOh+4B bhv23rhz8+NaYgX9Vqv/rz8i0N6HYljBzhoumAqTn6JG+w8F2tnp5vU3OddnBOCDUFKx LeSV8deS/+9vOZA2pYABG+SUO1T88Zo8x9dBVb6oWXdsD+ZAReDFvc6nW89nGoqGXegf /oqO11J/EmA8FBVTjbjRc6bRTyjP2mbOHONGlWCrkP70H3cNEGlSAZs24HAfRqd2p6Fs dNHT7Orm4W9LXl3Y7NlN7LF7X6TBgt7NPjlD/G9Qjm/6D3TrD9ktx8TtihSDZ3oZuNsj iLRQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ShhcE8vTVFnX9qMoN3gVMD7+mn1kE4aglRDFA2bGfUU=; b=iyjQXUrDeiTPFW5F8wyTwjZ5alNq6ANoBzOGgqgt1En0mt7kOaWVc1c91JJLE7Cpha jjRRs2/82Cy948Rt7QXZeL2+pPAcjo44nOiHD7Sth/YC4IwWnhS32+03H8c88gcZ4XVm urFYOSS+LxeqlTGUpCYFyoXua4LLM3jc8YfAQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=ShhcE8vTVFnX9qMoN3gVMD7+mn1kE4aglRDFA2bGfUU=; b=oNMg6WJlfVj5IWgViBhIXu5GpTkgqqXio31/ggrEzCtiNWeHyxm1/L3q1tyRIaxosU VTc7Lq2dnyoi2GNrvA0rIpQDTZLRgjts2pXQcqTrEiKI3uX/5SDjAg6TIB2TwpUieY06 vPeA+R5VwTh6zbBOmO75e+VpAGrJaPbYSRZQPjOBFDiwgA13iyLG9l8qec8FRx/c69Wb hybHpcw9QlKbsXFgzn5/WrEhB1PDBLAlTWjKJG8uykoUTROt9yoAEMh7D+xz+JaOM2ER xfeoiWJL/d5CHzSRUHoqwLnCmShvqWCewd0LJq0r07T644O2DrisNcNK/VW8OG0Cz1el /z3w==
MIME-Version: 1.0
X-Received: by 10.49.104.114 with SMTP id gd18mr17755527qeb.13.1368468208853; Mon, 13 May 2013 11:03:28 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.61.25 with HTTP; Mon, 13 May 2013 11:03:28 -0700 (PDT)
In-Reply-To: <CABP7RbcYMzGEWG3yL-sRA+HHsO+7JcMmRkHU=tvQW62k72XeCQ@mail.gmail.com>
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> <CABkgnnXVMnL=i2p_mDzcWLP0TNpV_wp7XhsuOTA+Tayv1aBv3Q@mail.gmail.com> <CAP+FsNda_dzPqe1+e3DJsAtvi=xRH=dtdr0tnOJvCoWdF6MCjg@mail.gmail.com> <CABP7RbcYMzGEWG3yL-sRA+HHsO+7JcMmRkHU=tvQW62k72XeCQ@mail.gmail.com>
Date: Mon, 13 May 2013 15:03:28 -0300
X-Google-Sender-Auth: RXrkr2XG2PWae_e4mutRtu6523A
Message-ID: <CAA4WUYijhOjJ1fo7VhUD6ezsOGO9P5q9M=q_p8J3CiDawG3bjg@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: James M Snell <jasnell@gmail.com>
Cc: 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>
Content-Type: multipart/alternative; boundary=047d7b6782fc79ceb204dc9d550a
X-Gm-Message-State: ALoCoQkXhSWWah6lZtO2wgNzg73JwgMnrxjDv3CpJXpOSF5PJ28i6dQWq+iuV8zQ3ZX6Ur2aXxAkV59Fc+O0tQhvFsKLZaM8+SocS1tNzeJ2rW/uGzaqk3oOvZFdElyJjrWR6xjjHqq3W1jVoe7zKExubXYXcaHl7hZ3gkDtMwiKWoTcyJYjDrg8zycrtHtuysvi1eadfzzZ
Received-SPF: pass client-ip=209.85.216.51; envelope-from=willchan@google.com; helo=mail-qa0-f51.google.com
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Hub-Spam-Report: AWL=-1.468, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.629, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1Ubx6I-0008Rm-Rf 9302f9d0565aa9bdf8f9fe75f5ec8bf7
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/CAA4WUYijhOjJ1fo7VhUD6ezsOGO9P5q9M=q_p8J3CiDawG3bjg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17969
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>

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.
> >
> >
>