Bug in supporting Quality zero (negate) parameter in Accept-Encoding

[António P. P. Almeida]

On 29 Jul 2011 20h11 WEST, nginx-forum at nginx.us wrote:

>> What really surprises me WHY they send this header at all ?
>
> You would assume that a CDN would clean/normalize the requests to
> the backend, and not use the Q qualifiers at all.  But maybe in some
> cases they just pass the accept-encoding header which they receive
> from the client.
>
> In this case I tracked it down as a large corporation behind a
> Microsoft ISA firewall, which could not access our css/js.  They
> were accessing the cdn with the origin being our nginx servers.  I
> can't comment on the choices that microsoft firewalls make in their
> request headers ( or the companies that use them, or how they
> configure them ), but it appears that they do follow the RFC in this
> case.
>
> In order to guarantee correct delivery via nginx, is the only
> workaround right now to disable compression on all our css/js
> content?  Or can you think of something else?

If you have their IP range you can try using the Geo module,
http://wiki.nginx.org/HttpGeoModule, like this:

geo $gzip_state {
   default on;
   xxx.yyy.zzz.uuu/nm off; # their IP range...those using ISA proxy
}


server {
 (...)
  gzip $gzip_state;
 (...)
}

--- appa