- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 21 Jan 2013 11:50:01 +1100
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: "Adrien W. de Croy" <adrien@qbik.com>, Pablo <paa.listas@gmail.com>, HTTP Working Group <ietf-http-wg@w3.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. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Monday, 21 January 2013 00:50:29 UTC