GZIP does not compress 201 Created Responses
|Reported by:||Craig Minihan||Owned by:|
|uname -a:||Linux 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux|
|nginx -V:||nginx version: nginx/1.4.3|
I have NGiNX running as a proxy for CouchDB. The CouchDB REST API returns 201 in response to document create requests. These responses can be large therefore gzip compression greatly increases performance.
I've noticed that gzip is fine on all requests except where the response is a 201. This is easy to reproduce even in a browser:
1) Setup CouchDB with NGiNX handling requests as a proxy.
2) Access CouchDB's Futon web site from a browser. Create a database, create a document and set the id of the document as a long string.
3) Clicking 'Save Document' in the UI prompts the browser to call onto NGiNX/CouchDB with the PUT request below:
PUT /tb_fct_agent_logout2/A_VERY_LONG_ID_APPEARS_HERE HTTP/1.1
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
HTTP/1.1 201 Created
Date: Thu, 19 Dec 2013 12:55:03 GMT
THE RAW JSON BODY APPEARS HERE, 3126 CHARS IN LENGTH AS YOU WOULD EXPECT FROM THE CONTENT-LENGTH ABOVE. IT IS NOT COMPRESSED.
All other requests using the browser accessing the Futon site via NGiNX are compressed as you would expect.
NGiNX is built from source not an RPM.
Since CouchDB is has a REST API they make heavy use of response codes you wouldn't typically see from a standard web site. Therefore the loss of compression on 201 responses presents a major issue in my use case. Thanks!