- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 21 Jan 2013 13:04:39 +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 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." >> 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:05:08 UTC