W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

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

From: 陈智昌 <willchan@chromium.org>
Date: Sun, 20 Jan 2013 18:32:14 -0800
Message-ID: <CAA4WUYhRLAwpvWvB0uNkJB_S5XjtUJzsKbnag27AtmZVSzuP2w@mail.gmail.com>
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>
On Sun, Jan 20, 2013 at 6:04 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
> On 21/01/2013, at 12:42 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:
>>>
>>> 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".
>
> Nope; if you want to say that the client doesn't accept compression, you have to do so explicitly;
>
> https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#header.accept-encoding
>
> "If no Accept-Encoding field is in the request, any content-coding is considered acceptable by the user agent."

Sorry, I was inexact. I should have said stripping of A-E values that
allow for compression. My understanding is that the knob that
intermediaries use here is exactly the knob you describe of "the
sender choosing not to compress", for the explicit purpose of
receiving uncompressed content, for reasons that include scalability.

Oops, wait, I think I did indeed misunderstand. I believe I was
conflating sender with client. You're talking about the request
headers in this case. Brain fart, sorry.

>
>
>>> 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.
>
> Lots of virus scanning happens in intermediaries :)
>
>
>>>> 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.
>
>
> Absolutely.
>
> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
Received on Monday, 21 January 2013 02:32:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 21 January 2013 02:32:44 GMT