- From: Johnny Graettinger <jgraettinger@chromium.org>
- Date: Thu, 1 May 2014 23:12:38 -0400
- 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>
- Message-ID: <CAEn92Tpu_k9iyHDh8PfWzmWwQNQR=xtggZiARCKTVYAMrSHWyA@mail.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