While Nginx's HttpGzipModule excels at compressing responses, handling incoming gzip-compressed requests requires a different approach. Many developers coming from Apache (where mod_deflate handles this seamlessly) are surprised to find this gap in Nginx's default capabilities.

When clients send requests with Content-Encoding: gzip headers, Nginx doesn't automatically decompress them. This becomes problematic for:

• APIs accepting compressed payloads
• Proxy scenarios where upstream services send gzipped data
• Webhook handlers receiving compressed notifications

We'll implement a solution using Lua scripting with OpenResty or the ngx_http_gunzip_module. Here's the complete configuration approach:

# In your nginx.conf or virtual host configuration
http {
    lua_package_path "/path/to/lua/?.lua;;";
    
    init_by_lua_block {
        local zlib = require "zlib"
        function gunzip_request_body()
            local content_encoding = ngx.req.get_headers()["Content-Encoding"]
            if content_encoding == "gzip" then
                local body = ngx.req.get_body_data()
                if body then
                    ngx.req.set_body_data(zlib.inflate()(body))
                    ngx.req.set_header("Content-Encoding", nil)
                end
            end
        end
    }
    
    server {
        listen 80;
        
        location /api/ {
            access_by_lua_block {
                gunzip_request_body()
            }
            
            proxy_pass http://backend;
        }
    }
}

For compiled solutions, add this third-party module:

./configure --add-module=/path/to/ngx_http_gunzip_module
make
make install

Then configure:

location /upload {
    gunzip on;
    client_max_body_size 100m;
    proxy_pass http://backend;
}

When implementing gzip request handling:

• Monitor memory usage - compressed bodies inflate in memory
• Set appropriate client_max_body_size limits
• Consider CPU overhead for high-traffic services

Verify with curl:

curl -X POST -H "Content-Encoding: gzip" --data-binary @file.gz http://yourserver/api

Check your access logs for proper handling:

log_format compressed '$remote_addr - $request_length/$bytes_received $request';

While Nginx's HttpGzipModule is well-documented for compressing responses, handling incoming GZIP-compressed requests requires additional configuration. This is particularly relevant for API servers receiving compressed POST/PUT payloads.

The key directive is gunzip in the ngx_http_gunzip_module (built by default since Nginx 1.3.9):

http {
    gunzip on;
    gunzip_buffers 16 8k;
    
    server {
        listen 80;
        server_name api.example.com;
        
        location /upload {
            client_max_body_size 100m;
            proxy_set_header Content-Encoding "";
            proxy_pass http://backend;
        }
    }
}

• gunzip: Enables decompression of requests with Content-Encoding: gzip
• gunzip_buffers: Sets number and size of buffers for decompression
• client_max_body_size: Must account for uncompressed size

For JSON APIs expecting compressed payloads:

location /api {
    gunzip on;
    gunzip_proxied any;
    
    if ($http_content_encoding = gzip) {
        set $should_gunzip 1;
    }
    
    proxy_set_header X-Uncompressed-Length $content_length;
    proxy_pass http://app_server;
}

When benchmarking with 1MB JSON payloads:

Check the error log when troubleshooting:

tail -f /var/log/nginx/error.log | grep gunzip

Common issues include missing Content-Length headers or buffers being too small for the uncompressed data.

For selective decompression based on request characteristics:

map $http_content_encoding $should_gunzip {
    default 0;
    "gzip" 1;
}

server {
    gunzip $should_gunzip;
    ...
}