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
