Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#172 closed defect (invalid)

gzip returning bigger response bodies than uncompressed

Reported by: Jens Rantil Owned by: somebody
Priority: minor Milestone:
Component: nginx-module Version:
Keywords: Cc:
uname -a: Linux XXXXXXX 2.6.32-5-amd64 #1 SMP Sat May 5 01:12:59 UTC 2012 x86_64 GNU/Linux
nginx -V: nginx version: nginx/0.7.67
TLS SNI support enabled
configure arguments: --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gzip_static_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-ipv6 --with-mail --with-mail_ssl_module --add-module=/tmp/buildd/nginx-0.7.67/modules/nginx-upstream-fair

Description

I have just enabled gzip compression, and $gzip_ratio logging, in a nginx server. Skimming through my access logs I notice that some of the response bodies are larger than uncompressed. In this case, wouldn't it be reasonable to return a non-compressed body instead? Should this be considered a bug?

Change History (3)

comment:1 by Ruslan Ermilov, 8 years ago

In general, you don't know what the ratio will be until you compute it. Having it computed in nginx means that the server already sent the compressed data to a client. You can play with gzip module settings like gzip_min_length and gzip_comp_level.

As an aside, could you please stop sending (what you think are) bug reports, and instead consult with the mailing list first? :)

comment:2 by Maxim Dounin, 8 years ago

Resolution: invalid
Status: newclosed

Closing this as this is clearly not a bug.

comment:3 by Valentin V. Bartenev, 8 years ago

Moreover, even if body hasn't been sent yet (was fully buffered), then headers were.

I recommend you to specify the proper MIME types and do not try to compress already compressed data (like png images and so).

Note: See TracTickets for help on using tickets.