Revision 1107973 of Transfer-Encoding

<div>{{HTTPSidebar}}</div>

<p>The <strong><code>Transfer-Encoding</code></strong> header specifies the form of encoding used to safely transfer the {{Glossary("Entity header","entity")}} to the user.</p>

<p><code>Transfer-Encoding</code> is a hop-by-hop header, that is applying to a message between two nodes, not to a ressource itself. Each segment of a multi-node connection can use different <code>Transfer-Encoding</code> values. If you want to compress data over the whole connection, use the end-to-end header {{HTTPHeader("Content-Encoding")}} header instead.</p>

<p>When present on a response to a {{HTTPMethod("HEAD")}} request that has no body, it indicates the value that woule have applied to the corresponding {{HTTPMethod("GET")}} message.</p>

<table class="properties">
 <tbody>
  <tr>
   <th scope="row">Header type</th>
   <td>{{Glossary("Response header")}}</td>
  </tr>
  <tr>
   <th scope="row">{{Glossary("Forbidden header name")}}</th>
   <td>yes</td>
  </tr>
 </tbody>
</table>

<h2 id="Syntax">Syntax</h2>

<pre class="syntaxbox">
Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip
Transfer-Encoding: identity

<em>// Several values can be listed, separated by a comma</em>
Transfer-Encoding: gzip, chunked</pre>

<h2 id="Directives">Directives</h2>

<dl>
 <dt><code>chunked</code></dt>
 <dd>Data is sent in a series of chunks. The {{HTTPHeader("Content-Length")}} header is omitted in this case and at the beginning of each chunk you need to add the length of the current chunk in hexadecimal format, followed by '<code>\r\n</code>' and then the chunk itself, followed by another '<code>\r\n</code>'. The terminating chunk is a regular chunk, with the exception that its length is zero. It is followed by the trailer, which consists of a (possibly empty) sequence of entity header fields.</dd>
 <dt><code>compress</code></dt>
 <dd>A format using the <a class="external" href="https://en.wikipedia.org/wiki/LZW">Lempel-Ziv-Welch</a> (LZW) algorithm. The value name was taken from the UNIX <em>compress</em> program, which implemented this algorithm.<br />
 Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is used by almost no browsers today, partly because of a patent issue (which expired in 2003).</dd>
 <dt><code>deflate</code></dt>
 <dd>Using the <a class="external" href="https://en.wikipedia.org/wiki/Zlib">zlib</a> structure (defined in <a class="external" href="https://tools.ietf.org/html/rfc1950">RFC 1950</a>), with the <a class="external" href="https://en.wikipedia.org/wiki/DEFLATE"><em>deflate</em></a> compression algorithm (defined in <a class="external" href="https://tools.ietf.org/html/rfc1952">RFC 1951</a>).</dd>
 <dt><code>gzip</code></dt>
 <dd>A format using the <a class="external" href="https://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77">Lempel-Ziv coding</a> (LZ77), with a 32-bit CRC. This is originally the format of the UNIX <em>gzip</em> program. The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize <code>x-gzip</code> as an alias, for compatibility purposes.</dd>
 <dt><code>identity</code></dt>
 <dd>Indicates the identity function (i.e. no compression, nor modification). This token, except if explicitly specified, is always deemed acceptable.</dd>
</dl>

<h2 id="Examples">Examples</h2>

<h3 id="Chunked_encoding">Chunked encoding</h3>

<p>Chunked encoding is useful when larger amounts of data are sent to the client and the total size of the response may not be known until the request has been fully processed. For example, when generating a large HTML table resulting from a database query or when transmitting large images. A chunked response looks like this:</p>

<pre>
HTTP/1.1 200 OK 
Content-Type: text/plain 
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n 
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n 
\r\n</pre>

<h2 id="Specifications">Specifications</h2>

<table class="standard-table">
 <tbody>
  <tr>
   <th scope="col">Specification</th>
   <th scope="col">Title</th>
  </tr>
  <tr>
   <td>{{RFC("7230", "Transfer-Encoding", "3.3.1")}}</td>
   <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td>
  </tr>
 </tbody>
</table>

<h2 id="Browser_compatibility">Browser compatibility</h2>

<p class="hidden">The compatibility table in this page is generated from structured data. If you’d like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data/README.md">https://github.com/mdn/browser-compat-data/README.md</a> and send us a pull request</p>

<p>{{Compat}}</p>

<h2 id="See_also">See also</h2>

<ul>
 <li>{{HTTPHeader("Accept-Encoding")}}</li>
 <li>{{HTTPHeader("Content-Encoding")}}</li>
 <li>{{HTTPHeader("Content-Length")}}</li>
 <li>Header fields that regulate the use of trailers: {{HTTPHeader("TE")}} (requests) and {{HTTPHeader("Trailer")}} (responses).</li>
 <li>
  <p><a href="https://en.wikipedia.org/wiki/Chunked_transfer_encoding">Chunked transfer encoding</a></p>
 </li>
</ul>