Gzip compression not taken into account?

Server NGINX
1

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:

2

Hi -

Are those tools misreporting? What does the content-encoding: header
say?
On May 13, 2011 1:09 PM, “jfix” [email protected] wrote:

application/x-javascript;
inspector.

Thank you in advance,
Jakob.

Posted at Nginx Forum:
gzip compression not taken into account?

3

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

4

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

5

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/

  • About to connect() to example.org port 80 (#0)
  • Trying xx.xx.xx.xx… connected
  • Connected to 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
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

  • About to connect() to example.org port 80 (#0)
  • Trying xx.xx.xx.xx… connected
  • Connected to 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
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

  • About to connect() to example.org port 80 (#0)
  • Trying xx.xx.xx.xx… connected
  • Connected to 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
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:

6

Hello!

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

  • Connected to 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:

http://wiki.nginx.org/HttpGzipModule#gzip_http_version
http://wiki.nginx.org/HttpGzipModule#gzip_proxied

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.

7

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

GET 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
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:

8

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

9

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: