“Double Compression: The Risks of Compressing Already Compressed HTTP Responses”

We’ll begin by looking into what HTTP response compression is and how it works, as well as some of the most frequently used compression headers in HTTP. We’ll then explore the potential risks of compressing an already compressed response, including its effect on file size and performance. We also provide examples of data types that are commonly compressed, like images, videos, PDFs and ZIP files.

What is HTTP Response Compression?

HTTP response compression works by compressing the data that is sent in the response from the server before it is sent over the internet. The client, then decompresses the data before displaying it to the user. By compressing the data that is sent in the HTTP response, developers can improve the performance of their api’s by reducing the amount of data that needs to be transferred over the internet.

Read more https://developer.mozilla.org/en-US/docs/Web/HTTP/Compression

Enabling compression in your web server involves configuring your server to compress the response data before sending it to the client.

If you are using embedded Tomcat with Spring Boot, you can enable compression by adding the appropriate configuration to your application.properties file.

Here is an example:

server.compression.enabled=true
server.compression.min-response-size=1024
server.compression.mime-types=application/json,application/xml,text/html,text/xml,text/plain

In this example, we enable compression, set the minimum response size to 1024 bytes, and specify the MIME types that should be compressed.

Please note that different application servers may have different ways of enabling compression, so you should consult your server’s documentation for more information on how to configure compression.

What are Compression headers ?

Compression headers are used in HTTP to indicate to the client that the response content has been compressed using a specific compression algorithm. These headers are used to negotiate the compression algorithm used between the client and the server, and to inform the client of the compressed data size.

The most commonly used compression headers in HTTP are “Content-Encoding” and “Vary”. The “Content-Encoding” header specifies the compression algorithm used on the response content, such as gzip or deflate. This header is typically included in the response from the server to the client.

What Happens When You Double Compress an Already Compressed Response?

While HTTP response compression can be an effective technique for improving website performance, it is important to ensure that the response is only compressed once using the most appropriate compression algorithm. If the response is already compressed, compressing it again using gzip or another algorithm may result in a larger file size, rather than a smaller one. This is because compression algorithms work by finding patterns in the data, and if the data is already compressed, there may be fewer patterns to find.

For example, let’s say a server sends a response that is already compressed using the gzip algorithm. If this response is then compressed again using gzip or another algorithm, it may result in a larger file size. This is because the second compression algorithm may not be able to find patterns in the compressed data, and may add additional data that increases the overall file size. In addition, compressing an already compressed response can also have a negative impact on performance, as the additional compression and decompression steps can add extra processing time and consume more server resources.

Dev Notes

If you are testing HTTP response compression , you may not be able to see the compressed response size in Postman because the response will be unzipped by default.

To see the actual compressed response size, you can use tools such as Wireshark to sniff the network layer.

Alternatively, you can monitor the network tab of the browser dev tools to see the compressed response size. When you make a request to your rest application in the browser, you can open the browser dev tools and navigate to the network tab.

With Single Compression(Original response size 2.1 MB)

1.4 MB transfer size after compression.

With Double Compression

2 * compress(message)

    public String compress(String inputString) throws Exception {

        ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
        GZIPOutputStream gzipOutputStream = new GZIPOutputStream(outputStream);
        gzipOutputStream.write(inputString.getBytes("UTF-8"));
        gzipOutputStream.close();

        byte[] compressedBytes = outputStream.toByteArray();
        String compressedString = new String(compressedBytes, "ISO-8859-1");
        
        return compressedString;
    }

Original Response size increased to 3 MB.

here are several types of data that may already be compressed before being sent as an HTTP response. Some examples of already compressed response data include:

1. Image files: Image files, such as JPEG, PNG, and GIF, are often compressed using lossy or lossless compression techniques. Compressing an already compressed image file using a compression algorithm such as gzip or deflate may not result in any significant reduction in file size and may actually increase the file size.
2. Video files: Similar to image files, video files are often compressed using a variety of techniques, such as MPEG, H.264, or VP9. Compressing an already compressed video file may not result in any significant reduction in file size and may actually increase the file size.
3. PDF files: PDF files are often compressed using the Flate compression algorithm, which is a form of lossless compression. Compressing an already compressed PDF file using another compression algorithm may not result in any significant reduction in file size and may actually increase the file size.
4. ZIP files: ZIP files are a type of compressed archive that can contain multiple files. Compressing a ZIP file that has already been compressed may not result in any significant reduction in file size and may actually increase the file size.

Conclusion

In conclusion, HTTP response compression is a powerful technique that can help improve the performance of a website by reducing the amount of data that needs to be transferred over the internet. However, it is important to ensure that the response is only compressed once using the most appropriate compression algorithm. Attempting to compress an already compressed response may result in a larger file size, rather than a smaller one, and can also have a negative impact on performance.

“Do not let the elephant out.” :)