No gzip compression for HTTP status code 202
mdounin at mdounin.ru
Tue Dec 4 12:39:01 UTC 2018
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?
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
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:
> What do you think about making the status codes that will get compressed
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.
More information about the nginx