Gzip is a compression encoding format. The server often compresses the response body by this encoding and then responds to the client, thus reducing the data size, increasing the transmission speed and saving bandwidth. The client then decompresses it by Gzip to get the original data. It consumes extra CPU resources because of the compression computation required.
Http Header & Encoding
There are many other ways to encode similar to Gzip. The client and server need to negotiate to determine the encoding method to be used(Some clients do not support Gzip).
This is a response header, and the MDN explains it as follows.
The Content-Encoding representation header lists any encodings that have been applied to the representation (message payload), and in what order. This lets the recipient know how to decode the representation in order to obtain the original payload format. Content encoding is mainly used to compress the message data without losing information about the origin media type.
Note that the original media/content type is specified in the
Content-Typeheader, and that the
Content-Encodingapplies to the representation, or “coded form”, of the data. If the original media is encoded in some way (e.g. a zip file) then this information would not be included in the
Servers are encouraged to compress data as much as possible, and should use content encoding where appropriate. Compressing a compressed media type such as a zip or jpeg may not be appropriate, as this can make the payload larger.
The common understanding is that the server tells the client through this Header what type of encoding is used in the response body.
This is a request header and the MDN is explained below.
The Accept-Encoding request HTTP header indicates the content encoding (usually a compression algorithm) that the client can understand. The server uses content negotiation to select one of the proposals and informs the client of that choice with the
Even if both the client and the server support the same compression algorithms, the server may choose not to compress the body of a response if the
identityvalue is also acceptable. Two common cases lead to this:
- The data to be sent is already compressed, therefore a second compression will not reduce the transmitted data size. This is true for pre-compressed image formats (JPEG, for instance);
- The server is overloaded and cannot allocate computing resources to perform the compression. For example, Microsoft recommends not to compress if a server uses more than 80% of its computational power.
As long as the
*;q=0directives do not explicitly forbid the
identityvalue that means no encoding, the server must never return a
The client uses this request header to tell the server the list of encoding types it accepts, from which the server typically selects one to encode the response body.
Server encoding response body
Using the browser to request this Controller, we will get the following response.
As you can see, the client automatically decodes the response according to the
gzip encoding specified by
Content-Encoding. Since the response itself is so small, using GZIP to compress it increases its size.
RestTemplate decoding response body
The output of the console after running the test code:
If you find that the response data you read via
RestTemplateis incorrect. Then you can check if the server is using a certain encoding through the
Content-Encodingresponse header and you need to decode it manually.
If you are using springboot to develop web applications, you can enable response compression (the server will automatically negotiate with the client on the encoding of the compression) by configuring the following.
||Whether response compression is enabled.||
||Comma-separated list of user agents for which responses should not be compressed.|
||Comma-separated list of MIME types that should be compressed.||
||Minimum “Content-Length” value that is required for compression to be performed.||