I just tried this on an nginx server I have sitting in front of an Apache backend.
curl -H "Content-Encoding: gzip" --include -d @testfile.gz http://example.com/upload_file.php
curl automatically added:
to the request headers.
nginx sent back a
HTTP/1.1 100 Continue
response and curl followed up by sending the gzipped data. nginx passed the whole lot back to Apache, still compressed and still with the
Content-Encoding: header intact.
If I didn't add the
Content-Encoding: gzip header with curl, I didn't get the HTTP 100 response but everything else was the same.
This doesn't answer your question yet but it does imply that nginx either doesn't handle this by default or doesn't uncompress the body of the request when it is proxying. I'm interested in the answer to this one so I'll see if I can try it out on a non-proxying nginx server a bit later on.
Presumably you could solve the bandwidth problem by proxying those requests to an Apache backend with mod_deflate but that ignores the reason you chose nginx in the first place.