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

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

Received on Friday, 11 July 2014 00:13:36 UTC