DefaultDecompressHandle() breaks response compression by invoking c.Next()

[wspowell]

I have an app that I am upgrading from v1.0.1 to v1.2.3. After updating, and making no other changes to my app, my gzip tests started failing. I noticed that my test response body would be returned uncompressed but would still have the gzip header appended (for example: {"data":323}���).

I noticed that in v1.0.1, the DefaultDecompressHandle() would simply decompress the request body and then return. This allowed gzipHandler.Handle() to continue immediately and, if it should compress the response, would assign c.Writer with the appropriate gzip writer. After this, it invokes c.Next() which allows the rest of the request handler to proceed and anything written to the response would be gzip compressed.

I noticed that in v1.2.3, the DefaultDecompressHandle() adds extra logic but then crucially at the end of the function invokes c.Next(). This causes the request handlers to be invoked prematurely and thus anything written to the response is not gzip compressed. However, upon returning to gzipHandler.Handle(), it is still processing fn(c) but is now at the end of the request lifecycle instead of the beginning. This causes the rest of the function to erroneously write the trailing gzip bytes, via the defer, which become appended to a non-compressed response.

It appears that the correct fix for this bug is to simply remove the c.Next() at the end of DefaultDecompressHandle().