- From: 陈智昌 <willchan@chromium.org>
- Date: Sun, 20 Jan 2013 16:41:14 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "Adrien W. de Croy" <adrien@qbik.com>, Pablo <paa.listas@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
I need to consider it longer, since I still have some concerns - namely, client-side intermediaries / 3rd-party software. Note that it's common nowadays for 3rd party software to interact with browser software at a very intimate level. Maybe do it in the form of Winsock LSPs (see https://code.google.com/p/chromium/issues/detail?id=27870 for an example of how we've had to work around bugs here), (oft-times malicious) extensions (https://code.google.com/p/chromium/issues/detail?id=128748#c15), or external applications directly mucking with browser specific data (here are links to examples of Samsung Support Center directly mucking with the browser cache: https://bugzilla.mozilla.org/show_bug.cgi?id=825665 & https://code.google.com/p/chromium/issues/detail?id=167578#c11). 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. 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. 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. On Sun, Jan 20, 2013 at 4:05 PM, Mark Nottingham <mnot@mnot.net> wrote: > It was discussed in terms of disabling it at the sender, not through negotiation, so I don't think the case you're talking about is going to be a problem. > > > On 21/01/2013, at 10:55 AM, William Chan (陈智昌) <willchan@chromium.org> wrote: > >> Maybe it falls upon me to be the voice of concern here :) Depending on >> what a "debug" option entails, I'm worried about it being used to >> disable a performance feature. As an example of how options can be >> dangerous, we've seen intermediaries that strip out Accept-Encoding >> headers in order to force responses to be uncompressed (probably so >> they can inspect the payloads more easily/cheaply), which is an issue >> from a web performance perspective. >> >> Back to the use case, if you're in a position to use the debug option, >> is it likely that you would not also be in a position to capture >> enough to decode? I'd like to understand the use case so I can >> properly weigh the benefit of such an option, in contrast to the cost >> that I highlighted above. >> >> On Sun, Jan 20, 2013 at 3:48 PM, Mark Nottingham <mnot@mnot.net> wrote: >>> >>> On 21/01/2013, at 10:38 AM, "Adrien W. de Croy" <adrien@qbik.com> wrote: >>> >>>> >>>> the thing that will make debugging harder won't be binary vs text, but the inter-dependence of messages. Especially when it comes to looking through debug logs for issues. >>>> >>>> On-the-wire, you already need to piece together a TCP stream to see what's going on, so having http messages effectively split over multiple frames (e.g. delta encoding, or compression) only becomes a problem when you don't capture enough to decode. >>>> >>>> I think it might be worth-while specifying a requirement for a "debug" option for senders of binary messages which turns off all other optimisations, such as caching unchanged headers etc (so they are sent every time). Just an idea. >>> >>> That's been brought up a few times, and the reaction has been pretty positive. >>> >>> Cheers, >>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >> > > -- > Mark Nottingham http://www.mnot.net/ > > >
Received on Monday, 21 January 2013 00:41:41 UTC