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

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

Received on Saturday, 11 May 2013 17:22:23 UTC