W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: #285: Strength of requirements on Accept re: 406

From: Brian Pane <brianp@brianp.net>
Date: Wed, 22 Jun 2011 16:11:44 -0700
Message-ID: <BANLkTi==GHSxA7acrYo=s56TUg-6pEdnuA@mail.gmail.com>
To: httpbis Group <ietf-http-wg@w3.org>
On Wed, Jun 22, 2011 at 2:59 PM, Adrien de Croy <adrien@qbik.com> wrote:
>
> Some versions of WinGate removed Accept-Encoding.
>
> If the server ignored that, and sent say gzipped back, it would cause
> problems, esp with caching.
>
> I think it's a really bad idea to ignore it.  It would have been removed for
> a reason.
>
> Some plug-in filters also remove it (e.g. they can't handle certain
> encodings, but need to scan the data).  So ignoring again causes problems.
>
> In general I think ignoring Accept-Encoding or sending an encoded response
> when there was no Accept-Encoding received is a very bad idea.

>From a server-side perspective, though, allowing a client or
intermediary to quadruple the server operator's egress network transit
cost by removing the Accept-Encoding seems undesirable - I'm inclined
to call it a vulnerability, in fact.

Thus my preference would be to add something like "implementations
MUST accept a Content-Encoding of 'gzip' for requests and responses,"
but unfortunately that would cause some formerly HTTP/1.1-compliant
implementations to suddenly be noncompliant, so it's out of scope for
HTTPbis.  For the next version of HTTP, though, I think it's
worthwhile to consider requiring that implementations support one or
more specified compression mechanisms.

-Brian
Received on Wednesday, 22 June 2011 23:12:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:41 GMT