W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: James M Snell <jasnell@gmail.com>
Date: Thu, 10 Jul 2014 17:12:49 -0700
Message-ID: <CABP7RbdHMPhTNbeO4eGfvJ3dgz3A3GASkyBRa7fgN+yXiX8FuA@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC