Hello!
2012/11/4 朱茂海:
> gzip开启了，但ngx.say输出的内容没有压缩。
>
如果我是你，我会直接在报告问题的邮件中附上我实际使用的不能工作的 nginx 配置文件片段，以及相关的软件信息，以便节约沟通的成本。
于是我现在只好代你做了：
gzip on;
gzip_min_length 1;
gzip_types text/plain;
location /t {
default_type text/plain;
content_by_lua '
ngx.say("hello world")
';
}
我们可以用 curl 来验证一下这个例子的实际效果：
$ curl -i --compressed localhost:8080/t
HTTP/1.1 200 OK
Server: nginx/1.2.4
Date: Mon, 05 Nov 2012 03:27:19 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive
Content-Encoding: gzip
hello world
注意响应头中的 Content-Encoding: gzip 这一行。这里 curl
显示出的响应体之所以不是二进制数据是因为它自动替我们进行 gzip 解压了。
当然，我们也可以不让 curl 替我们进行 gzip 解压：
$ curl -i -H 'Accept-Encoding: gzip' localhost:8080/t
HTTP/1.1 200 OK
Server: nginx/1.2.4
Date: Mon, 05 Nov 2012 03:29:02 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive
Content-Encoding: gzip
�H���W(�/�I�-�
我们可以看到，这一次确实响应体部分是二进制乱码了，即进行 gzip 压缩过后的二进制数据。
当然，我们也可以使用 Firefox 这样的浏览器进行测试，并用 Firebug 这样的工具检查响应头中的 Content-Encoding
头的值是否为 gzip.
配置 ngx_gzip 模块的常见陷阱是
1. 实际响应的 Content-Type 头与 gzip_types 配置的 MIME 类型不匹配；
2. gzip_min_length 设置过大而实际输出的响应体又较小（同时实际响应也提供了 Content-Length 响应头）。
Best regards,
-agentzh
