Hello!

On Tue, Dec 04, 2018 at 07:09:48AM -0500, hpuac wrote:

> > http://mailman.nginx.org/pipermail/nginx/2012-September/035338.html
>
> Thank you for the quick answer!
> Would it make sense to add that information to the documentation?
> https://nginx.org/en/docs/http/ngx_http_gzip_module.html

I don't think so. It is an implementation detail.

> You named some examples why not to compress 206, 304, 400, 500, but is there
> any particular reason to not compress 202?
> Status codes like 201 and 202 should like 200 be common and safe response
> codes that could be compressed.
> I had a quick look and for example undertow is also compressing 202
> responses.

Both 201 and 202 are very rare, and aren't expected to be big.
E.g., 201 as returned by nginx's DAV module contains an empty entity
body, and certainly won't benefit from compression.

Also, with status codes specific for non-browser clients it is a
good idea to test if various popular clients using these status
codes can actually handle compression of these codes. And this
turns to be a problem, see ticket #394 which is still waiting for
tests on Windows / macOS builtin DAV clients:

https://trac.nginx.org/nginx/ticket/394

> What do you think about making the status codes that will get compressed
> configurable?

I don't think this is needed. Moreover, I would expect this to
result in problems, as people will inevitably try to compress
responses with codes certainly not to be compressed, simply
because they can.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx