title: Transfer-Encoding: gzip vs. Content-Encoding: gzip
body: <p>What is the current state of affairs when it comes to whether to do</p>
  
  <pre><code>Transfer-Encoding: gzip
  </code></pre>
  
  <p>or a</p>
  
  <pre><code>Content-Encoding: gzip
  </code></pre>
  
  <p>when I want to allow <strong>clients</strong> with e.g. limited bandwidth to <strong>signal their willingness to accept a compressed response</strong> and the <strong>server have the final say whether or not to compress</strong>.</p>
  
  <p>The latter is what e.g. Apache's mod_deflate and IIS do, if you let it take care of compression. Depending on the size of the content to be compressed, it will do the additional <code>Transfer-Encoding: chunked</code>.</p>
  
  <p>It will also include a <code>Vary: Accept-Encoding</code>, which already hints at the problem. <code>Content-Encoding</code> seems to be part of the entity, so changing the <code>Content-Encoding</code> amounts to a change of the entity, i.e. a different <code>Accept-Encoding</code> header means e.g. a cache cannot use its cached version of the otherwise identical entity.</p>
  
  <p>Is there a definite answer on this that I have missed (and that's not buried inside a message in a long thread in some apache newsgroup)?</p>
  
  <p>My current impression is:</p>
  
  <ul>
  <li>Transfer-Encoding would in fact be the right way to do what is mostly done with Content-Encoding by existing server and client implentations</li>
  <li>Content-Encoding, because of its semantic implications, carries a couple of issues (what should the server do to the <code>ETag</code> when it transparently compresses a response?)</li>
  <li>The reason is chicken'n'egg: Browsers don't support it because servers don't because browsers don't</li>
  </ul>
  
  <p>So I am assuming the right way would be a <code>Transfer-Encoding: gzip</code> (or, if I additionally chunk the body, it <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.41" rel="noreferrer" title="additional">would become</a> <code>Transfer-Encoding: gzip, chunked</code>). And no reason to touch <code>Vary</code> or <code>ETag</code> or any other header in that case as it's a transport-level thing.</p>
  
  <p>For now I don't care too much about the 'hop-by-hop'-ness of <code>Transfer-Encoding</code>, something that others seem to be concerned about first and foremost, because proxies might uncompress and forward uncompressed to the client. However, proxies might just as well forward it as-is (compressed), if the original request has the proper <code>Accept-Encoding</code> header, which in case of all browsers that I know is a given.</p>
  
  <p>Btw, this issue is at least a decade old, see e.g.
  <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=68517" rel="noreferrer">https://bugzilla.mozilla.org/show_bug.cgi?id=68517</a> .</p>
  
  <p>Any clarification on this will be appreciated. Both in terms of what is considered standards-compliant and what is considered practical. For example, HTTP client libraries only supporting transparent "Content-Encoding" would be an argument against practicality.</p>