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

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

On Sun, Jan 20, 2013 at 4:50 PM, Mark Nottingham <[e-mail]> wrote:
>
> 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?

TLS + providing no Chromium-configurable option to disable header
compression, at least from our (Chromium's) end :) If the origin
server disables header compression in their responses, we can't help
that, in the same way we can't help if they don't compress their
response bodies. We do what we can. It's possible that, since Google
Chrome includes auto-update capabilities, we can err on the side of
providing an option and revoking it if abused.

>
>
>> 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.

Sorry, I either misunderstood or was unclear. In my understanding,
while A-E is generally a negotiation, if you simply strip A-E, it's
effectively the same as "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.

This is speculation of course, but I suspect that many do it simply
for simplicity's sake. While I think intermediaries like
Varnish/HAProxy/Squid may have legitimate scalability concerns if/when
they disable stuff like compression, I think that many intermediaries,
like virus scanners and what not, simply disable things like
compression to make them easier to process. Maybe I'm more jaded about
the quality of engineering out there than you, but I suspect most
engineers simply consider what's easiest to get their job done, rather
than the overall implications of their actions. Otherwise, I'm pretty
surprised some ISPs strip A-E, since I'd imagine that the bandwidth
costs exceed the scalability costs for implementing their filtering
policies. Of course, I'm no expert here and would love to be educated.

>
> 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.

This is why I asked about the use case, so we could evaluate how
necessary this option is. I'm hoping it is not unpalatable. Adrien's
response leaves me somewhat hopeful, although it's still uncertain.

>
>
>> 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.

Fair enough. I mostly wanted to chime in to provide the "other"
opinion here, since you stated that the previous reaction had been
pretty positive. Please take my comments as a contrary opinion for
people to consider before we draw any conclusions here.

>
> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>