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

[William Chan (陈智昌) <[e-mail]>]

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 <[e-mail]> 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 (陈智昌) <[e-mail]> 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 <[e-mail]> wrote:
>>>
>>> On 21/01/2013, at 10:38 AM, "Adrien W. de Croy" <[e-mail]> 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/
>
>
>