Content-Encoding entity header is used to compress the media-type. When present, its value indicates which encodings were applied to the entity-body. It lets the client know how to decode in order to obtain the media-type referenced by the
The recommendation is to compress data as much as possible and therefore to use this field, but some types of resources, such as jpeg images, are already compressed. Sometimes, using additional compression doesn't reduce payload size and can even make the payload longer.
Content-Encoding: gzip Content-Encoding: compress Content-Encoding: deflate Content-Encoding: identity Content-Encoding: br // Múltiplo, em ordem nos quais serão aplicados Content-Encoding: gzip, identity Content-Encoding: deflate, gzip
A format using the Lempel-Ziv coding (LZ77), with a 32-bit CRC. This is the original format of the UNIX gzip program. The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize
x-gzipas an alias, for compatibility purposes.
A format using the Lempel-Ziv-Welch (LZW) algorithm. The value name was taken from the UNIX compress program, which implemented this algorithm. Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is not used by many browsers today, partly because of a patent issue (it expired in 2003).
Indicates the identity function (i.e., no compression or modification). This token, except if explicitly specified, is always deemed acceptable.
A format using the Brotli algorithm.
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.
Accept-Encoding: gzip, deflate
The server responds with the scheme used, indicated by the
Content-Encoding response header.
Note that the server is not obligated to use any compression method. Compression highly depends on server settings and used server modules.
BCD tables only load in the browser