# Gzip compression not taken into account?

**URL:** <https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949>\
**Category:** NGINX\
**Created:** [May 13, 2011, 10:09pm UTC](https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949 "2011-05-13T22:09:37Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [May 13, 2011, 10:09pm UTC](https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949/1 "2011-05-13T22:09:37Z")

</div>

Hi, I have enabled gzip compression following the wiki instructions like  
this:

location / {  
#…

gzip on;  
gzip\_min\_length 1000;  
gzip\_proxied expired no-cache no-store private auth;  
gzip\_types text/plain application/xml text/javascript text/css  
application/x-javascript;  
gzip\_disable “MSIE [1-6].”;

#…  
}

unfortunately, both Yahoo’s yslow and Google’s pagespeed tell me that I  
should enable compression for better performance.

How can I find out why compression doesn’t seem to happen? I’ve  
selected the mime-types after having looked at them in chrome’s web  
inspector.

Thank you in advance,  
Jakob.

Posted at Nginx Forum:

> **[gzip compression not taken into account?](https://forum.nginx.org/read.php?2,197898,197898#msg-197898)**
>
> Hi, I have enabled gzip compression following the wiki instructions like this: location / { #.... gzip on; gzip\_min\_length 1000; gzip\_proxied expired no-cache no-store private auth; gzip\_types text/plain application/xml text/javascript t

---

<div class="post-metadata">

**Author:** ![jfix](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ce73a5/32.png) [@jfix](https://www.ruby-forum.com/u/jfix)\
**Post date:** [May 13, 2011, 10:20pm UTC](https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949/2 "2011-05-13T22:20:43Z")

</div>

Hi -

Are those tools misreporting? What does the content-encoding: header  
say?  
On May 13, 2011 1:09 PM, “jfix” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> application/x-javascript;  
> inspector.
> 
> Thank you in advance,  
> Jakob.
> 
> Posted at Nginx Forum:  
> [http://forum.nginx.org/read.php?2,197898,197898#msg-197898](http://forum.nginx.org/read.php?2,197898,197898#msg-197898)

---

<div class="post-metadata">

**Author:** ![jfix](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ce73a5/32.png) [@jfix](https://www.ruby-forum.com/u/jfix)\
**Post date:** [May 14, 2011, 1:00am UTC](https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949/3 "2011-05-14T01:00:39Z")

</div>

Hi,

Maybe you’are encountering what Steve Souders call the “Turtle Tapping”.

You need to check the Accept-Encoding HTTP header from the browser side  
(need to be: Accept-Encoding: gzip, deflate). In some cases (in order to  
analyse faster the content of the traffic), web-proxies and Antivirus  
are  
mangled the Accept-Encoding HTTP header.

–  
Regards  
Jocelyn Mocquant

---

<div class="post-metadata">

**Author:** ![jfix](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ce73a5/32.png) [@jfix](https://www.ruby-forum.com/u/jfix)\
**Post date:** [May 14, 2011, 11:36pm UTC](https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949/4 "2011-05-14T23:36:27Z")

</div>

The --compressed flag is adding “Accept-Encoding: deflate, gzip” to the  
request.

Your test shows that nginx is working fine. It is compressing the  
content if  
it receives an Accept-Encoding: gzip field, and doesn’t if not. This is  
valid behaviour.

However, Chrome _should_ be sending an Accept-Encoding field just like  
curl  
–compressed. You can confirm this using the dev tools. If it is, and  
you  
don’t get a Content-Encoding: gzip header in the response on Chrome  
(indicating compression), and if that curl test you performed was run on  
local interface to nginx, then it is almost certainly an HTTP proxy  
that’s  
interfering.

If otoh, you got those results running the curl test remotely so that it  
too  
went through the proxy (a useful confirmation test if you didn’t), then  
I’m  
not so sure.

Cheers  
Thomas

---

<div class="post-metadata">

**Author:** ![jfix](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ce73a5/32.png) [@jfix](https://www.ruby-forum.com/u/jfix)\
**Post date:** [May 14, 2011, 6:22pm UTC](https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949/5 "2011-05-14T18:22:52Z")

</div>

Thanks for your replies, I will try to provide more information (I’m  
quite new with nginx).

Traffic passes through the company firewall/proxy server, so potentially  
things could get mangled there. I guess there is no way to inspect the  
requested headers as received by the server? I set the error\_log level  
to debug\_http, but it doesn’t seem to log headers.

One interesting detail: Using curl and explicitly requesting a  
compressed response like this, I get this result:

M:\>curl -v --compressed [http://example.org/](http://example.org/)

- About to connect() to [example.org](http://example.org) port 80 (#0)
- Trying xx.xx.xx.xx… connected
- Connected to [example.org](http://example.org) (xx.xx.xx.xx) port 80 (#0)

> GET / HTTP/1.1  
> User-Agent: curl/7.19.7 (i386-pc-win32) libcurl/7.19.7 OpenSSL/0.9.8l  
> zlib/1.2.3  
> Host: [example.org](http://example.org)  
> Accept: _/_  
> Accept-Encoding: deflate, gzip

\< HTTP/1.1 200 OK  
\< Server: nginx  
\< Date: Sat, 14 May 2011 16:10:06 GMT  
\< Content-Type: text/html; charset=UTF-8  
\< Transfer-Encoding: chunked  
\< Connection: keep-alive  
\< Vary: Accept-Encoding  
\< Content-Encoding: gzip  
\<  
10.107.145.6 - - [14/May/2011:18:10:06 +0000] “GET / HTTP/1.1” 200 2671  
“-” "curl/7.19.7 (i386-pc-win32) libcurl/7.19.7 OpenSSL/0.9.81  
zlib/1.2.3 “-” “0.031” “2.53”

where the last item “2.53” is the compression ratio.

M:\>curl -v --compressed [http://example.org/resource/style/global.css](http://example.org/resource/style/global.css)

- About to connect() to [example.org](http://example.org) port 80 (#0)
- Trying xx.xx.xx.xx… connected
- Connected to [example.org](http://example.org) (xx.xx.xx.xx) port 80 (#0)

> GET /resource/style/global.css HTTP/1.1  
> User-Agent: curl/7.19.7 (i386-pc-win32) libcurl/7.19.7 OpenSSL/0.9.8l  
> zlib/1.2.3  
> Host: [example.org](http://example.org)  
> Accept: _/_  
> Accept-Encoding: deflate, gzip

\< HTTP/1.1 200 OK  
\< Server: nginx  
\< Date: Sat, 14 May 2011 16:14:38 GMT  
\< Content-Type: text/css  
\< Transfer-Encoding: chunked  
\< Connection: keep-alive  
\< Vary: Accept-Encoding  
\< Last-Modified: Fri, 13 May 2011 16:00:36 GMT  
\< Expires: Thu, 31 Dec 2037 23:55:55 GMT  
\< Cache-Control: max-age=315360000  
\< Content-Encoding: gzip

10.107.145.6 - - [14/May/2011:18:14:38 +0000] “GET / HTTP/1.1” 200 7917  
“-” "curl/7.19.7 (i386-pc-win32) libcurl/7.19.7 OpenSSL/0.9.81  
zlib/1.2.3 “-” “0.000” “5.48”

So, this means that compression does work in theory, but it doesn’t  
unless I request it. The following example is the same as the previous  
one, but without the --compressed:

M:\>curl -v [http://example.org/resource/style/global.css](http://example.org/resource/style/global.css)

- About to connect() to [example.org](http://example.org) port 80 (#0)
- Trying xx.xx.xx.xx… connected
- Connected to [example.org](http://example.org) (xx.xx.xx.xx) port 80 (#0)

> GET /resource/style/global.css HTTP/1.1  
> User-Agent: curl/7.19.7 (i386-pc-win32) libcurl/7.19.7 OpenSSL/0.9.8l  
> zlib/1.2.3  
> Host: [example.org](http://example.org)  
> Accept: _/_

\< HTTP/1.1 200 OK  
\< Server: nginx  
\< Date: Sat, 14 May 2011 16:16:59 GMT  
\< Content-Type: text/css  
\< Connection: keep-alive  
\< Vary: Accept-Encoding  
\< Content-Length: 43345  
\< Last-Modified: Fri, 13 May 2011 16:00:36 GMT  
\< Expires: Thu, 31 Dec 2037 23:55:55 GMT  
\< Cache-Control: max-age=315360000

10.107.145.6 - - [14/May/2011:18:16:59 +0000] “GET / HTTP/1.1” 200 43345  
“-” "curl/7.19.7 (i386-pc-win32) libcurl/7.19.7 OpenSSL/0.9.81  
zlib/1.2.3 “-” “0.000” “-”

I’m not sure what the --compressed option translates to in terms of  
headers, but it makes a difference. The last examples is what I get when  
I user a browser (Chrome and Firefox tested).

Thanks for your help,  
Jakob.

Posted at Nginx Forum:  
[http://forum.nginx.org/read.php?2,197898,198024#msg-198024](http://forum.nginx.org/read.php?2,197898,198024#msg-198024)

---

<div class="post-metadata">

**Author:** ![jfix](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ce73a5/32.png) [@jfix](https://www.ruby-forum.com/u/jfix)\
**Post date:** [May 16, 2011, 1:09pm UTC](https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949/6 "2011-05-16T13:09:02Z")

</div>

Hello!

On Sat, May 14, 2011 at 05:51:33PM -0400, jfix wrote:

> - Connected to [wsg-proxy.oecd.org](http://wsg-proxy.oecd.org) (10.101.128.15) port 80 (#0)  
> \< Date: Sat, 14 May 2011 21:46:49 GMT  
> for your help.  
> Please note that by default nginx only returns compressed response  
> to HTTP/1.1 requests. By using proxy you may be in fact using  
> HTTP/1.0 in request to nginx.

Additionally, nginx will look though request headers to find out  
if request was from proxy, and by default won’t return compressed  
response to proxies. With gzip\_proxied as set in your config it  
won’t return response in question compressed as well.

See here for more details:

> **[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki...](https://github.com/nginxinc/nginx-wiki)**
>
> ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com

> **[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki...](https://github.com/nginxinc/nginx-wiki)**
>
> ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com

Please also note that unconditionally enabling gzip for everything  
may not be a good idea. If enabling gzip for proxied requests,  
please at least make sure that (a) gzip\_vary set to on and (b)  
gzip for HTTP/1.0 is disabled (default).

Maxim D.

---

<div class="post-metadata">

**Author:** ![jfix](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ce73a5/32.png) [@jfix](https://www.ruby-forum.com/u/jfix)\
**Post date:** [May 14, 2011, 11:51pm UTC](https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949/7 "2011-05-14T23:51:52Z")

</div>

Thanks Thomas for your reply.

I’ve redone the test by explicitly supplying the proxy, and indeed it  
seems to remove the Accept-encoding header, as even with --compressed  
option, the response is now uncompressed:

M:\>curl --compressed -v -x wsg-proxy.example.org:80  
[http://example.org/resource/style/global.css](http://example.org/resource/style/global.css)

- About to connect() to proxy [wsg-proxy.example.org](http://wsg-proxy.example.org) port 80 (#0)
- Trying 10.101.128.15… connected
- Connected to [wsg-proxy.oecd.org](http://wsg-proxy.oecd.org) (10.101.128.15) port 80 (#0)

> GET [http://example.org/resource/style/global.css](http://example.org/resource/style/global.css) HTTP/1.1  
> User-Agent: curl/7.19.7 (i386-pc-win32) libcurl/7.19.7 OpenSSL/0.9.8l  
> zlib/1.2.3  
> Host: [example.org](http://example.org)  
> Accept: _/_  
> Accept-Encoding: deflate, gzip  
> Proxy-Connection: Keep-Alive

\< HTTP/1.1 200 OK  
\< Server: nginx  
\< Date: Sat, 14 May 2011 21:46:49 GMT  
\< Content-Type: text/css  
\< Vary: Accept-Encoding  
\< Last-Modified: Fri, 13 May 2011 16:00:36 GMT  
\< Expires: Thu, 31 Dec 2037 23:55:55 GMT  
\< Cache-Control: max-age=315360000  
\< Content-Length: 43345  
\< Age: 0  
\< Via: 1.1 localhost.localdomain

So, it looks like I have to talk to my company’s IT people … Thanks  
for your help.

Jakob.

Posted at Nginx Forum:  
[http://forum.nginx.org/read.php?2,197898,198083#msg-198083](http://forum.nginx.org/read.php?2,197898,198083#msg-198083)

---

<div class="post-metadata">

**Author:** ![jfix](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ce73a5/32.png) [@jfix](https://www.ruby-forum.com/u/jfix)\
**Post date:** [May 16, 2011, 3:58pm UTC](https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949/8 "2011-05-16T15:58:03Z")

</div>

That you’ve added those directives with no fix makes me more confident  
that  
your proxy is simply not forwarding your Accept-Encoding: gzip header.

I’m not sure if nginx can log request headers, but if you have it  
configured  
for PHP, you can request a simple test script:

var\_dump($\_SERVER[“HTTP\_ACCEPT\_ENCODING”]);

Thomas

---

<div class="post-metadata">

**Author:** ![jfix](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/ce73a5/32.png) [@jfix](https://www.ruby-forum.com/u/jfix)\
**Post date:** [May 16, 2011, 1:30pm UTC](https://www.ruby-forum.com/t/gzip-compression-not-taken-into-account/206949/9 "2011-05-16T13:30:07Z")

</div>

Hi Maxim, thanks for your input.

I had, in the meantime, added the directives

gzip\_http\_version 1.0  
gzip\_vary on

Does the fact that the response contains this header

Via:1.1 localhost.localdomain

mean that HTTP 1.1 is being used? Having changed temporarily the  
gzip\_proxied directive to

gzip\_proxied any

hasn’t changed a thing, unfortunately. I will look in more detail at  
the gzip\_proxied values and see how they are applicable or not.

Thanks,  
Jakob.

Posted at Nginx Forum:

> **[Re: gzip compression not taken into account?](https://forum.nginx.org/read.php?2,197898,198433#msg-198433)**
>
> Hi, I have enabled gzip compression following the wiki instructions like this: location / { #.... gzip on; gzip\_min\_length 1000; gzip\_proxied expired no-cache no-store private auth; gzip\_types text/plain application/xml text/javascript t