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

Re: #466 segment compression

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Thu, 1 May 2014 23:12:38 -0400
Message-ID: <CAEn92Tpu_k9iyHDh8PfWzmWwQNQR=xtggZiARCKTVYAMrSHWyA@mail.gmail.com>
To: K.Morgan@iaea.org
Cc: Roberto Peon <grmocg@gmail.com>, Matthew Kerwin <matthew@kerwin.net.au>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
The HTTP/1.1 pipelined case is equivalent to using MAX_CONCURRENT_STREAMS
of 1. That also guarantees a single compression context. Many HTTP/2
implementations are likely willing to deal with N > 1 simultaneous
compression contexts in exchange for better compression, so long as they
can dictate the upper bound (and indeed they can).

On Thu, May 1, 2014 at 6:42 PM, <K.Morgan@iaea.org> wrote:

> On 02 May 2014 00:01, I wrote:
> > On 29 April 2014 21:57, grmocg@gmail.com wrote:
> >> If compression is per-segment as opposed to per-frame
> >>    AND we wish to restrict the amount of state the server must keep
> around
> >>    AND the sender wishes to have all the data in the segment compressed
> >>   THEN then the segment being compressed must be sent in its entirety
> in a contiguous series of frames with > no muxing of other streams in the
> middle.
> >
> > The exact same problem exists for dynamic compression with C-E.  How are
> you going to solve that?
> Sorry to reply to my own e-mail, but I really think this does apply to
> dynamic C-E compression and is a DoS vector.
> Suppose a client sends N request for various entities that are dynamically
> compressed, where N=MAX_CONCURRENT_STREAMS and suggests an equal priority
> for each. If the server gives equal priority to serving each stream, it
> will have N outsanding compression contexts until all requests are
> serviced. By contrast, in HTTP/1.1, even with pipelining, a single client
> on a single connection would only ever require one compression context on
> the server to service its requests.
> This is an argument in favor of using frame-by-frame compression for
> dynamic compression since frame-by-frame compression _can_ be implemented
> with only one outstanding compression context at any given time.  It's also
> an argument for mandating client *support* for frame-by-frame gzip (i.e.
> non-optional) because it always gives servers a way out from this DoS
> vector.
> Has anybody implemented a native HTTP/2 server with dynamic compression
> support that can speak to this problem?
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
Received on Friday, 2 May 2014 03:13:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC