HTTP Headers
Content Encoding
The HTTP Content-Encoding
representation header lists the encodings and the order in which they have been applied to a resource.
This allows the recipient to understand how to decode the data to retrieve the original content format specified in the Content-Type
header.
Content encoding is primarily used to compress content efficiently without losing information about the original media type.
Servers should compress data as much as possible and should utilize content encoding when suitable.
Compressing media types that are already compressed, such as .zip or .jpeg files, is generally not recommended since it can lead to increased file size.
If the original media is already encoded (for example, as a .zip file), this information is not included in the Content-Encoding
header.
When the Content-Encoding
header is included, other headers like Content-Length
typically refer to the size of the encoded data rather than the original resource, unless explicitly specified.
It is important to distinguish content encoding from Transfer-Encoding
, as the latter governs how HTTP messages are transmitted across the network on a hop-by-hop basis.
Syntax
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br
Content-Encoding: zstd
Content-Encoding: dcb
Content-Encoding: dcz
// Multiple, in the order in which they were applied
Content-Encoding: deflate, gzip
Directives
Directives
gzip
This format uses the Lempel-Ziv coding (LZ77), combined with a 32-bit CRC for error checking.
It is the original format implemented by the UNIX gzip program.
The HTTP/1.1 standard recommends that servers supporting this content encoding should also recognizex-gzip
as an alias for compatibility.compress
This format employs the Lempel-Ziv-Welch (LZW) algorithm.
The name derives from the UNIX compress program, which first implemented this algorithm.
Although this encoding is less common today, partly due to a patent that expired in 2003, some browsers and servers may still support it.deflate
This method uses the zlib structure (defined in RFC 1950) combined with the deflate compression algorithm (defined in RFC 1951).
br
A format utilizing the Brotli compression algorithm structure, as specified in RFC 7932.
zstd
This format applies the Zstandard compression algorithm, as described in RFC 8878.
dcb
This is an experimental format employing the Dictionary-Compressed Brotli algorithm. For more details, refer to Compression Dictionary Transport.
dcz
This experimental format uses the Dictionary-Compressed Zstandard algorithm. Additional information is available under Compression Dictionary Transport.
Example
Compressing with gzip
On the client side, you can advertise a list of compression schemes that will be sent along in an HTTP request. The Accept-Encoding
header is used for negotiating content encoding.
Example of an HTTP request:
<code>Accept-Encoding: gzip, deflate</code>
The server responds with the scheme used, indicated by the Content-Encoding
response header.
Example of an HTTP response:
<code>Content-Encoding: gzip</code>
Whether a server uses compression methods requested by the client depends on server configuration and capabilities.
How to Modify Header using Requestly
This is especially useful for testing how your application handles different content encodings like gzip or deflate during development or debugging. Steps to Modify the Content-Encoding Header:
- Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
- Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
- Add a new header modification:
- Under “Action”, select “Add” or “Override”.
- In the “Header Name” field, enter Content-Encoding.
- In the “Header Value” field, enter your preferred encoding type (e.g., gzip).
- Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-api.com/*).
- Save the rule.
Once set up, Requestly will inject the Content-Encoding: gzip header into all matching requests, allowing you to simulate different server responses and test how your client deals with encoded content. You might need to modify the Content-Encoding header to test if your application correctly decodes compressed responses or to debug issues related to data compression and decompression in your web requests.
Table of Contents
- No headings found.