nginx gzip enabled but not not gzipping
I have gzip enabled on nginx 1.2.8, but for some reason, it is not gzipping anything.
Nginx install info:
nginx version: nginx/1.2.8
built by gcc 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx-1.2.8 --with-http_ssl_module --with-http_realip_module --with-http_gzip_static_module --with-pcre --conf-path=/etc/nginx/nginx.conf --add-module=../headers-more-nginx-module-0.19rc1
Config:
user www-user;
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
client_max_body_size 10M;
sendfile on;
keepalive_timeout 65;
more_clear_headers "Server";
gzip on;
gzip_types text/plain text/css application/json application/javascript application/x-javascript text/javascript text/xml application/xml application/rss+xml application/atom+xml application/rdf+xml;
server {
server_name test.com;
root /www;
index index.php index.html index.htm;
listen 80 default_server;
rewrite ^/(.*)/$ /$1 permanent; #remove trailing slash
#charset koi8-r;
#access_log logs/host.access.log main;
include general/*.conf;
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
location ~ \.php$ {
fastcgi_intercept_errors on;
fastcgi_pass unix:/run/php/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
}
I am trying to send a simple static css file. In my nginx config, text/css
is included in gzip_types
.
When I attempt to get the file using Firefox, fiddler shows that the received content is not gziped:
Request Headers:
GET http://test.com/test.css HTTP/1.1
Host: nextdreamtest2.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: __utma=237624223.1052931239.1362029000.1365467381.1365469205.16; __utmz=237624223.1362029000.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); __utmc=237624223; __utmb=237624223
Proxy-Authorization: Basic cHJveHk6RTRRWlNlY0JLU3o0OFh4cWpLNkg=
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Response headers:
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2013 01:35:07 GMT
Content-Type: text/css
Last-Modified: Thu, 31 May 2012 08:50:00 GMT
Connection: keep-alive
Content-Length: 1688
Note that there is no Content-Encoding: gzip
header even though gzip is enabled on the server, and the content-type is one that is configured to be gzipped.
After more investigation, I am even more baffled now. I tried FireFox 20.0 on the machine nginx is running on (Ubuntu 12.10), and the files are gzipped correctly:
Connection keep-alive
Content-Encoding gzip <------------------------------
Content-Type text/html
Date Tue, 09 Apr 2013 04:23:08 GMT
Set-Cookie 200ceb26807d6bf99fd6f4f0d1ca54d4=7hjir1h44g3dq8hlsihdsrn9v5; path=/; HttpOnly
Transfer-Encoding chunked <---------------------
However, if I try IE10, FireFox 20 and Chrome 26 and also Fiddler to inspect the headers on my Windows 8 machine to access the server, the response is never gzipped!
Connection keep-alive
Content-Length 2192 <------------------
Content-Type text/html
Date Tue, 09 Apr 2013 04:27:16 GMT
This is incredibly odd, as I do not see anything in my nginx.conf that would discriminate against Windows 8 Machines.
What could be causing this?
After seeing that FireFox 20 on Ubuntu was able to receive gzipped content while my Windows 8 machine was not able to, I became suspicious.
It tried the following on my Windows 8 machine: IE10, FireFox 20, Chrome 26, fiddler and curl. When of them showed that they received non-gzipped content, I immediately suspected my internet security suite.
After uninstalling BitDefender Windows 8 security (it didn't have the best performance either), I can now see my browser and clients on my Windows 8 machine receive gzipped content.
BitDefender was probably unzipping my packets and analysing them for viruses and phishing material before it hits any of the clients.
Nevertheless, after wasting almost a day on this, I won't be installing it again and will be looking at another product.