Why is GZIP Compression of a Request Body during a POST method uncommon?

Question

I was playing around with GZIP compression recently and the way I understand the following:

1. Client requests some files or data from a Web Server. Client also sends a header that says "Accept-Encoding,gzip"
2. Web Server retrieves the files or data, compresses them, and sends them back GZIP compressed to the client. The Web Server also sends a header saying "Content-Encoded,gzip" to note to the Client that the data is compressed.
3. The Client then de-compresses the data/files and loads them for the user.

I understand that this is common practice, and it makes a ton of sense when you need to load a page that requires a ton of HTML, CSS, and JavaScript, which can be relatively large, and add to your browser's loading time.

However, I was trying to look further into this and why is it not common to GZIP compress a request body when doing a POST call? Is it because usually request bodies are small so the time it takes to decompress the file on the web server is longer than it takes to simply send the request? Is there some sort of document or reference I can have about this?

Thanks!

Vanhomrigh

Answer 1

Very old question but I decided to resurrect it because it was my first google result and I feel the currently only answer is incomplete.

HTTP request compression is uncommon because the client can't be sure the server supports it.

When the server sends a response, it can use the Accept-Encoding header from the client's request to see if the client would understand a gzipped response.

When the client sends a request, it can be the first HTTP communication so there is nothing to tell the client that the server would understand a gzipped request. The client can still do so, but it's a gamble.

Although very few modern http servers would not know gzip, the configuration to apply it to request bodies is still very uncommon. At least on nginx, it looks like custom Lua scripting is required to get it working.

Demit

Answer 2

It's uncommon because in a client - server relationship, the server sends all the data to the client, and as you mentioned, the data coming from the client tends to be small and so compression rarely brings any performance gains.

In a REST API, I would say that big request payloads were common, but apparently Spring Framework, known for their REST tools, disagree - they explicitly say in their docs here that you can set the servlet container to do response compression, with no mention of request compression. As Spring Framework's mode of operation is to provide functionality that they think lots of people will use, they obviously didn't feel it worthwhile to provide a ServletFilter implementation that we users could employ to read compressed request bodies.

It would be interesting to trawl the user mailing lists of tomcat, struts, jackson, gson etc for similar discussions.

If you want to write your own decompression filter, try reading this: How to decode Gzip compressed request body in Spring MVC

Alternatively, put your servlet container behind a web server that offers more functionality. People obviously do need request compression enough that web servers such as Apache offer it - this SO answer summarises it well already: HTTP request compression - you'll find the reference to the HTTP spec there too.

Biweekly

Answer 3

Don't do it, for no other reason than security. Firewalls have a hard or impossible time dealing with compressed input data.

Roundlet

firewalls would have a hardtime decrypting TLS/SSL so I'm not sure what your point is. – Amidships

firewalls often decrypt, it is called deep packet inspection, that's why you install the certificate on the firewall. The point is, they would need to decompress the compressed data to apply their rules, and they don't (and shouldn't for a lot of reasons) Simple example from a common firewall docs.fortinet.com/document/fortigate/6.2.12/cookbook/122078/… – Roundlet