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

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