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

Re: #466 segment compression

From: Roberto Peon <grmocg@gmail.com>
Date: Fri, 2 May 2014 14:13:02 -0700
Message-ID: <CAP+FsNcg25PYK+i+dt9i_pNG_QA22=9tJABpWiSwaRUF3eV6Ew@mail.gmail.com>
To: K.Morgan@iaea.org
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>, Matthew Kerwin <matthew@kerwin.net.au>, John Graettinger <jgraettinger@chromium.org>
On Fri, May 2, 2014 at 1:51 PM, <K.Morgan@iaea.org> wrote:

> Once again, intermediaries never _have_ to put themselves in a situation
> where they have to decompress t-e. If the downstream requestor didn't
> support t-e, the intermediary is stupid to request t-e upstream (unless it
> wants to decompress).

So, that effectively says that one can never use t-e, since the majority of
downstream entities don't support it (or as spec'd, didn't send it to begin
That would mean that t-e was practically useless, then.

This is as compared to c-e gzip, which almost all endpoints support, and
which can thus give the benefit of payload compression on almost everything.

> (Roberto) your main point on this thread was that the DoS potential was on
> the _sender_.

I was worried about proxies. The DoS potential is on the receiver, not the
sender. It just so happens that for proxies, they're both receivers and

> Furthermore you said it was so bad it would require getting rid of
> multiplexing to reduce the DoS surface area. Johnny disagreed because you
> can bound the problem by setting max_concurrent_streams appropriately. Do
> you agree with Johnny? If so, then there's also no such DoS for per-segment
> t-e.
Johnny and I are saying the same thing, though: Reducing
MAX_CONCURRENT_STREAMS *is* getting rid of multiplexing... at
MAX_CONCURRENT_STREAMS == 1, there is no multiplexing. At any level under
that which we'd otherwise be happy to support, you're partially getting rid
of it.

> -Keith
> P.S. Roberto, I'm really interested in your response to my questions
> regarding your proposal to keep implicit c-e gzip.
I'm a bit lost in the thread-- would you mind repeating the questions you
want me to address here again? There are a mountain of quotes and it gets
very difficult to read. :/

Received on Friday, 2 May 2014 21:13:30 UTC

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