20

I thought this was a simple google search, but apparently I'm wrong on that.

I've seen that you should supply:

Accept-Encoding: gzip;q=0,deflate;q=0

in the request headers. However, the article that suggested it also noted that proxies routinely ignore that header. Also, when I supplied it to nginx, it still compressed the response message body.

http://forgetmenotes.blogspot.ca/2009/05/how-to-disable-gzip-compression-in.html

So, how do I tell a web server to disable compression on the response message body?

Charles
  • 50,943
  • 13
  • 104
  • 142
Homer6
  • 15,034
  • 11
  • 61
  • 81
  • I am confused: do you want to send a directive from the client to the server, do you want something that is guaranteed to pass thru whatever unwilling proxy may be in the way or do you want the directive to tell the server not to compress under any circumstance? – fvu Dec 06 '12 at 22:42
  • the latter... I want the directive to tell the server not to compress under any circumstance – Homer6 Dec 07 '12 at 00:24
  • Note that to prevent all compressions you would probably want to use `*;q=0` instead of just forbidding gzip and deflate. This being said, I'm indeed thinking that many servers don't bother with the Accept-Encoding feature as they should. There is also the `Accept-Encoding: identity`... – Alexis Wilke Dec 11 '13 at 00:58

3 Answers3

21

Many web servers ignore the 'q' parameter. The compressed version of a static resource is often cached and is returned whenever the request accepts it. To avoid getting compressed resources, use

Accept-Encoding: identity

The server should not serve you a compressed representation of the resource in this instance. Nor should any proxy. This is the default accepted encoding if none is given, but your client might add a default that accepts gzip, so explicitly providing 'identity' should do the trick.

Jack Wester
  • 5,170
  • 3
  • 28
  • 47
  • Unfortunately, nginx doesn't seem to respect that. I still get the content back gzipped. – Homer6 Dec 07 '12 at 00:38
  • 1
    Note that no `Accept-Encoding` is not an equivalent to the identity. The documentation clearly says that the server can decide what to do if the encoding was not specified. – Alexis Wilke Dec 11 '13 at 06:13
13

Do you wish encoding to be disabled altogether?
Then skip the Accept-Encoding header itself within http request headers.

Do you wish only gzip compression to be absent in the http response?
Then skip gzip from the values list in the http request header.

Do you wish to prioritize different compression techniques that servers support? then use different values between 0 and 1 along-with q argument for each value in the Accept-Encoding http request header. (Currently you are using conflicting value and indicating by weight=0 that you don't know how you'll manage, but you want response to be encoded anyhow)

Homer6
  • 15,034
  • 11
  • 61
  • 81
Chawathe Vipul S
  • 1,636
  • 15
  • 28
  • 1
    For proxies to consider Accept-Encoding http header for content served from their cache, the Vary http Response header is used with the http request headers such as Accept-Encoding as its values list, so proxy knows cached copy to be served varies as per which http request header. – Chawathe Vipul S Jan 24 '13 at 16:21
  • 3
    NO NO NO. The W3C spec (https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3) CLEARLY states that "If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding." Also "Note: If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred;" – roryhewitt Apr 14 '16 at 18:08
  • 1
    https://tools.ietf.org/html/rfc2616#section-14.3 You missed the interim sentence "In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.", so the note is only last resort at most. Also IETF is the canonical authority on internet protocols including http, and at the time of this answer http1.1 was the norm. For the curious and edge cases like yours, my guess is mentioning the link as in this comment should suffice. – Chawathe Vipul S Apr 15 '16 at 09:10
  • my point is that the canonical way of ENSURING that GZIP responses are disabled is to specify Accept-encoding: identity. As far as I know, any other response (including yours of simply not passing the Accept-encoding header) may not work. – roryhewitt Apr 18 '16 at 15:57
  • As per the sentence quoted from the IETF standard, your assumption about canonical "way" is misplaced same as http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem . – Chawathe Vipul S Apr 19 '16 at 06:40
  • OK, now I'm just lost as to what you are saying, but I'm pretty sure I'm not falling into the XY problem. The OP asked the following question "So, how do I tell a web server to disable compression on the response message body?". The only way to guarantee an uncompressed response is to send Accept-Encoding: identity. Simply not sending the Accept-Encoding request header (as you suggest) will not guarantee that the server might not still send a compressed response. Do you disagree? – roryhewitt Apr 19 '16 at 17:11
  • I've already quoted the specification's applicable sentence, the XY problem is the reason why anyone might want to manually specify Accept-Encoding: Identity . – Chawathe Vipul S Apr 20 '16 at 11:52
4

I think this mod for apache

http://httpd.apache.org/docs/2.2/mod/mod_deflate.html (2)

And this for Nginx

http://wiki.nginx.org/HttpGzipModule (1)

Sounds like what you need depending on which server you plan to use. The rest is up to you!

Please note the nginx module both allows shutting down decompression:

[edit] gzip 
Syntax: gzip on | off  
Default: off 
Context: http
server
location
if in location 
Reference: gzip 



Enables or disables gzip compression.

And dealing with proxies:

[edit] gzip_proxied 
Syntax: gzip_proxied off | expired | no-cache | no-store | private | no_last_modified | no_etag | auth | any ... 
Default: off 
Context: http 
server
location 
Reference: gzip_proxied 



It allows or disallows the compression of the response for the proxy request in the dependence on the request and the response. The fact that, request proxy, is determined on the basis of line "Via" in the headers of request. In the directive it is possible to indicate simultaneously several parameters: 

off - disables compression for all proxied requests 
expired - enables compression, if the "Expires" header prevents caching 
no-cache - enables compression if "Cache-Control" header is set to "no-cache" 
no-store - enables compression if "Cache-Control" header is set to "no-store" 
private - enables compression if "Cache-Control" header is set to "private" 
no_last_modified - enables compression if "Last-Modified" isn't set 
no_etag - enables compression if there is no "ETag" header 
auth - enables compression if there is an "Authorization" header 
any - enables compression for all requests 
[edit] gzip_types

Best wishes!

Sources:

1) http://forum.nginx.org/read.php?11,96472,214303

2) http://httpd.apache.org/docs/2.2/mod/mod_deflate.html#inflate (Section Output Decompression)

DrM
  • 1,092
  • 1
  • 8
  • 11