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

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