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

[Igor Sysoev]

On Fri, Jul 29, 2011 at 08:23:34PM +0100, António P. P. Almeida wrote:
> 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;
>  (...)
> }

The "gzip" directory does not currently support variables.


-- 
Igor Sysoev