Re: HTTP router point-of-view concerns

[Roberto Peon <[e-mail]>]

If one doesn't care about number of bytes on the wire, or if one doesn't
care about user-perceived latency, then obviously compression is a waste.
If one does care, then, especially on slower links, header compression does
a great deal to reduce latency as the HTTP metadata eats up a significant
fraction of available bandwidth on those links.

-=R


On Thu, Jul 11, 2013 at 10:21 AM, Sam Pullara <[e-mail]> wrote:

> How sure are we that the entire idea of header compression isn't a bad
> idea? I implemented something similar in the WebLogic T3 protocol
> (BubblingAbbrevTable, probably still in there) and it was mostly just a
> pain. If I were to go back I would just use gzip with some agreed upon seed
> dictionary. Thought I would bring this up since it seems like it is a very
> controversial feature to begin with.
>
> Sam
>
> On Jul 11, 2013, at 10:14 AM, James M Snell <[e-mail]> wrote:
>
> > Yes, the ability to set compression context size to 0 is very useful.
> > My fears around this area are:
> >
> > 1. In order to achieve maximum throughput, Intermediaries may opt to
> > *always* set compression context to 0, forcing the headers to always
> > be passed as Literals, killing the utility of having the header
> > compression mechanism there in the first place.
> >
> > 2. The assumption of a non-zero default compression context size when
> > the connection is established opens a race condition that a malicious
> > sender could exploit in a denial of service attack. Yes, the receiver
> > could opt to terminate the connection once it detects bad behavior,
> > but there is still a potential window of time there where the receiver
> > could be forced to do significant additional work.
> >
> >  (This is particularly bad given that header continuations are
> unbounded.)
> >
> > 3. Setting the compression context size to 0 does not stop the sender
> > from sending the Indexed Literal instructions anyway. The receiving
> > endpoint would still be required to process those instructions even if
> > the data is not actually being indexed, causing CPU cycles to be
> > consumed. For any individual block of headers it may not be a
> > significant load, but it's something that needs to be addressed.
> >
> >  (This can be fixed in the spec by stating that any attempt to Index
> > any individual (name,value) whose size is greater than the available
> > header table size results in a Compression Error. Making this change
> > would mean that when Compression Context size is 0, the only operation
> > that would not result in an error is Literal without Indexing. This
> > was discussed on the list but as far as I can tell it's not yet
> > captured in the spec).
> >
> > 4. The fact that header continuations can be unbounded is deeply
> > troubling, especially given that the endpoint is required to buffer
> > and process the complete header block (well.. that's only half true,
> > the encoding does allow for incremental processing of the HEADERS
> > frame payloads but the spec requires that the complete header block is
> > always processed). Sure, the recipient is free to terminate the
> > connection as soon as it detects bad behavior, but the sender could
> > end up forcing the recipient to do a significant amount of extra
> > processing with a never ending sequence of HEADERS frames. Smart
> > implementations will know how to deal with this, yes, but overall it
> > adds to the already growing list of "New Complex Things" that an
> > HTTP/2 implementer needs to know about.
> >
> >  (In the implementation I've done, I provide a configuration
> > parameter that allows a developer to cap the number of the
> > continuations and the total size of the header block)
> >
> > I know that we're in "implementation" phase right now and that
> > everyone is busy getting their code ready for testing in August, but
> > after updating my implementation to the latest version of the draft,
> > my concerns with regards to stateful header compression definitely
> > remain.
> >
> > On Thu, Jul 11, 2013 at 9:36 AM, Martin Thomson
> > <[e-mail]> wrote:
> >> On 10 July 2013 21:20, Amos Jeffries <[e-mail]> wrote:
> >>> It seems not to be negotiable from the recipients side.
> >>
> >> Compression context size = 0 is entirely negotiable from the recipient
> >> end, with a small wrinkle, that I know some folks are working on.
> >> Which is, a client can start using a default compression context size
> >> prior to learning that a server has no space (substitute intermediary
> >> as appropriate there).
> >>
> >
>
>
>