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

Igor Sysoev igor at sysoev.ru
Fri Jul 29 18:07:24 UTC 2011


On Fri, Jul 29, 2011 at 10:53:28AM -0700, Radek Burkat wrote:
> Spent the last day chasing down a corner case with Nginx and Level3
> CDN.  It turns out that some requests that they send have the
> following Accept-Encoding header.
> 
> "Accept-Encoding: compress, gzip;q=0"
> 
> Based on this RFC
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html  this is a
> valid way to say "NO gzip encoding"
> Nginx ignores this and actually sends a gziped version.   This causes
> the CDN to error, as defined by the RFC.
> 
> Example
> 
> This should NOT return compressed data, as defined by the RFC
> 
> curl -I http://cs.pinkbike.org/127/sprt/c/top.css -H "Accept-Encoding: gzip;q=0"
> 
> HTTP/1.1 200 OK
> Server: nginx/1.0.0
> Date: Fri, 29 Jul 2011 17:06:14 GMT
> Content-Type: text/css
> Last-Modified: Fri, 15 Jul 2011 20:13:20 GMT
> Connection: close
> Vary: Accept-Encoding
> Expires: Thu, 31 Dec 2037 23:55:55 GMT
> Cache-Control: max-age=315360000
> Cache-Control: public
> Content-Encoding: gzip
> 
> 
> Is there a parameter/idea that I am missing or is this a bug?

Yes, this is nginx bug.
What really surprises me WHY they send this header at all ?


-- 
Igor Sysoev



More information about the nginx mailing list