Re: Fragmentation for headers: why jumbo != continuation.

I think that stateful compression only affects point #1, and we should
continue that discussion in another thread.
-=R




On Thu, Jul 10, 2014 at 5:12 PM, James M Snell <jasnell@gmail.com> wrote:

> Roberto: This is true only because of the way HPACK's stateful
> compression is currently designed. If we opted for a stateless and
> streaming compression mechanism, there would not be an issue and we
> would not be having to trudge through all of this yet again. You're
> arguing for a solution to a problem caused by your own design.
>
> - James
>
> On Thu, Jul 10, 2014 at 1:27 PM, Roberto Peon <grmocg@gmail.com> wrote:
> > There are two separate reasons to fragment headers
> >
> > 1) Dealing with headers of size > X when the max frame-size is <= X.
> > 2) Reducing buffer consumption and latency.
> >
> > Most of the discussion thus far has focused on #1.
> > I'm going to ignore it, as those discussions are occurring elsewhere,
> and in
> > quite some depth :)
> >
> >
> > I wanted to be sure we were also thinking about #2.
> >
> > Without the ability to fragment headers on the wire, one must know the
> size
> > of the entire set of headers before any of it may be transmitted.
> >
> > This implies that one must encode the entire set of headers before
> sending
> > if one will ever do transformation of the headers. Encoding the headers
> in a
> > different HPACK context would count as a transformation, even if none of
> the
> > headers were modified.
> >
> > This means that the protocol, if it did not have the ability to fragment,
> > would require increased buffering and increased latency for any proxy by
> > design.
> >
> > This is not currently true for HTTP/1-- the headers can be sent/received
> in
> > a streaming fashion, and implementations may, at their option, choose to
> > buffer in order to simplify code.
> >
> > -=R
>