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

James M Snell <> Sat, 11 May 2013 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F80021F89EB for <>; Sat, 11 May 2013 10:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.924
X-Spam-Status: No, score=-7.924 tagged_above=-999 required=5 tests=[AWL=-2.325, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BcYMmEljQUPa for <>; Sat, 11 May 2013 10:23:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B7E5C21F89CF for <>; Sat, 11 May 2013 10:23:54 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UbDVD-00029Y-IW for; Sat, 11 May 2013 17:22:35 +0000
Resent-Date: Sat, 11 May 2013 17:22:35 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UbDV1-00027X-L8 for; Sat, 11 May 2013 17:22:23 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UbDV0-0005rW-VO for; Sat, 11 May 2013 17:22:23 +0000
Received: by with SMTP id uz6so337280obc.8 for <>; Sat, 11 May 2013 10:21:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=61HuuUbeEnl8D/zCff7lNB/2UcZPC3gs0oHeowGC31s=; b=TXlK6Fcp39QiX8AkTU/ez+WALfh6QwSRyTfoRbyvUzUnWdEw+hHr+FVvbgiwvrlS0c Y+p7+U/r/ceknCNogT2sBKUGxSzg8I/D5pleEzyKP3P4uRIqtN829ftbDqb7qbgQ3jba i8PWG8dfAWPt+a/w6rBYT/ycNa1yz89KTnUfEdgjlq76tpb+0sglE6aXZJf0mIiSFBxf INYmQzoOU2qkcgHRpWr3xnMm8CUp2Sve/30aUEL4yn7GEKx+uQK9ojhP86U0pQ9GuOmE YTOx5bR7BmjatOum03hS2fEXgZ7DVwPHcd1YT8GrLBJT5o07vGVKwLirvjPvouG2zbt+ mQ3g==
X-Received: by with SMTP id cj9mr9378402oeb.31.1368292916516; Sat, 11 May 2013 10:21:56 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 11 May 2013 10:21:36 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: James M Snell <>
Date: Sat, 11 May 2013 10:21:36 -0700
Message-ID: <>
To: Roberto Peon <>
Cc: Martin Thomson <>, "William Chan (陈智昌)" <>, Poul-Henning Kamp <>, "" <>, Hasan Khalil <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.681, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UbDV0-0005rW-VO 2c3b056b610b9b6919eecf8e3390abf7
Subject: Re: Proposal: New Frame Size Text (was: Re: Design Issue: Frame Size Items)
Archived-At: <>
X-Mailing-List: <> archive/latest/17951
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 <> 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 <>
> wrote:
>> On 10 May 2013 18:30, Roberto Peon <> 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.