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

[Mark Nottingham <[e-mail]>]

On 21/01/2013, at 11:41 AM, William Chan (陈智昌) <[e-mail]> 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.

Cheers,

--
Mark Nottingham   http://www.mnot.net/