W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: The use of binary data in any part of HTTP 2.0 is not good

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 21 Jan 2013 11:50:01 +1100
Cc: "Adrien W. de Croy" <adrien@qbik.com>, Pablo <paa.listas@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <B2A83604-183E-49BF-A962-238AF5F19DA9@mnot.net>
To: William Chan (陈智昌) <willchan@chromium.org>

On 21/01/2013, at 11:41 AM, William Chan (陈智昌) <willchan@chromium.org> wrote:

> Many times these intermediaries / 3rd party software are trying to do
> "legitimate" things like sniffing headers so they can do filtering
> based on that. If we add a sender-configured option to enable
> disabling header encoding/compression at the client, it's very likely
> that 3rd party software will take advantage of that option for popular
> client software (popular browsers). Thus, even if such an option
> existed in the spec, I would be nervous about exposing it within
> Chromium in such a way that 3rd party software could force it on.

Roberto mentioned that the sender could just choose not to compress their output; how would you stop that?

> And if such a mechanism existed sender-side, I still don't see what
> (beyond a secured transport like TLS) prevents an ISP or corporate
> network administrator who has filtering software he/she wants to run
> from adding a hop that enables this debug option to make it easier to
> pass through to 3rd party authored filtering software running within
> the ISP / corporate network.
> My concerns are admittedly erring on the side of paranoia, but it is
> definitely advised by our (Google Chrome) previous experience in this
> area. Please see
> https://developers.google.com/speed/articles/use-compression where we
> provide data on the prevalence of the aforementioned Accept-Encoding
> stripping issue. "There are a handful of ISPs, where the percentage of
> uncompressed content is over 95%. One likely hypothesis is that either
> an ISP or a corporate proxy removes or mangles the Accept-Encoding
> header." Accept-Encoding is a sender-side controlled header, so unless
> the proposed option is protected somehow via TLS or something, I would
> imagine that it likewise would expose us to the issue we've seen with
> Accept-Encoding stripping.

Again, this isn't negotiation (as currently discussed); it's the sender choosing not to compress.

Even if it were a negotiation, I suspect you'd find that the dynamics that you saw in play with compressing payloads doesn't play out the same way as it does with headers. Intermediaries strip accept-encoding because decompressing and recompressing the response bodies coming through them presents a scalability challenge; if we do our job right with header compression, it shouldn't be nearly as much of a problem for them.

Besides which, if we design HTTP/2 to be unpalatable to middleboxes, they'll merely block it and force all traffic to HTTP/1, meaning that those users won't see *any* benefits from the new protocol.

> All options are ripe for abuse. We should be very careful to make sure
> the option is truly necessary, rather than just potentially useful, in
> order to counterbalance the downside of possible abuse.

To counter that -- I'm somewhat wary of approaching protocol design as an exercise in controlling how the result is used; people *will* work around your intent. While we can do some social engineering in this process, it's very soft, and very limited, power.


Mark Nottingham   http://www.mnot.net/
Received on Monday, 21 January 2013 00:50:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC