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