

Join them; it only takes a minute:

Sign up
Join the Stack Overflow community to:
  1. Ask programming questions
  2. Answer and help your peers
  3. Get recognized for your expertise

If webserver can send gzip response, why can't browser sent gzip request?

share|improve this question
up vote 52 down vote accepted

The client and server have to agree on how to communicate; part of this is whether the communication can be compressed. HTTP was designed as a request/response model, and the original creation was almost certainly envisioned to always have small requests and potentially large responses. Compression is not required to implement HTTP, there are both servers and clients that don't support it.

HTTP compression is implemented by the client saying it can support compression, and if the server sees this in the request and it supports compression it can compress the response. To compress the request the client would have to have a "pre-request" that actually negotiated that the request would be made compressed OR it would have to require compression as a supported encoding for ALL requests.

share|improve this answer
So a server will simply fail if it doesn't support compression then? – jjxtra Jul 3 '14 at 4:10
"Compression is not required by the spec, there are both servers and clients that don't support it." The client starts by saying, "hey, I speak French, do you?" The server responds, and answers in either English or French, depending on whether it knows French or not. French in this example is compression. If as the OP asked, the client were able to start talking in French immediately, all servers would have to speak French or the system would break. The system only allows compressed responses precisely because it needs to negotiate and both systems agree. – Peter Oehlert Jul 3 '14 at 15:41

A client can't know in advance that a server would understand a gzipped request, but the server can know that the client will accept one.

share|improve this answer
Not true. Content-Encoding is a permissible header for the client to supply. The RFC says: "If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type)." - per Nick Johnson – Pacerier Jul 4 '12 at 6:59
What you're saying is a little different to what I was driving at. You can try to send a gzipped request as you suggest, but there's no way of knowing beforehand that the server will accept it (without talking to the server). That said, your point is well made: if you try to send a gzipped request, you may find the server can support it. – Paul Dixon Jul 4 '12 at 9:43
There are a lot of places where you know in advance that the server supports that. For example and mobile app talking to the backend. – Guillermo Jul 10 '12 at 13:24
Is there a list of servers that actually support a gzipped request? – Eric Dec 27 '12 at 1:52
are there any browsers that would support it? – boomhauer May 15 '13 at 14:38

It could, provided it could guarantee that the server would accept it. This might mean using an OPTIONS request.

There are a lot of things that web browsers could do (for example, pipelining) that they don't do. Web browser developers consider the compatibility implications of a change.

In a heterogeneous environment, there are a lot of different web servers and configurations. Making a change to the way a client works could break some of them.

Perhaps only 1% of servers might accept gzipped requests, but perhaps some of those advertise that they do, but cannot correctly accept it - so users would be denied from uploading files to those sites.

Historically there have been a lot of broken client / server implementations - for a long time, gzipped responses were broken in major web browsers (thankfully those are now mostly gone).

So you'd end up with blacklists of user-agents or servers (or domain names) where those options were automatically turned off, which is nasty.

share|improve this answer

Because it doesn't know that the server can accept it. An HTTP transaction has a single request sent by the client followed by a response. One of the things the client sends is what encoding/compression it can support. The server can then decide how to compress the response. The client does not have this luxury.

share|improve this answer
Well if the server can determine whether browser supports it or not, there CAN be an implementation which browser tries to found if the server can understand the g-zipped content or not; if developers work on that. – DRS David Soft May 29 '14 at 16:27
The server determines that the browser supports gzip because the browser just told it via an Accept-Encoding request header. You need some other way of the browser knowing a priori what the server's capabilities are. Doing that is outside of what HTTP/1.1 gives you. – Yuliy May 30 '14 at 6:48

If you're writing a web application, I'm assuming that you're in control of what is sent to the client and what is sent back from the client.

It would be easy enough to write a gzip implementation in javascript, that compresses the post data being sent to the server. The server could have a filter (j2ee term), that knows client data is sent compressed, this filter decompresses the data and then passes the data to the servlet (or action classes in Struts) that read the data as normal e.g. request.getParameter(...).

This seems perfectly logical and do-able if you're in control. As other posts mention, you couldn't rely on the browser to do this automatically, but since you're writing the web pages, you can get the browser to do the compression you're after (with a little work).


share|improve this answer

Why should it? The requests are usually so small that compression would

  1. probably enlarge it and
  2. take more time than it takes to transfer the uncompressed request.
share|improve this answer
Not always. Consider a file upload. – Yuliy Jan 8 '09 at 16:39
You'll find that the majority of files these days are already compressed. Aside from zip/gz themselves, which are probably the most common files uploaded, PDFs, docx, mp3s, video files etc are all compressed in some way, and trying to re-compress wastes time and could make the file bigger. – DisgruntledGoat May 17 '09 at 11:35
ASP.NET postback requests can be huge, especially with the __VIEWSTATE hidden field value. Interestingly, any part of a request that originated from the server and is transparent to the client CAN be compressed. For example, a value like the hidden __VIEWSTATE field, which is posted back unchanged, is easy to compress, since it's saved/loaded entirely on the server-side. It's just a matter of overriding a pair of methods, and adding a compression/decompression stage to the view state serialization process. See for example: – Triynko Jul 27 '11 at 17:56
If the viewstate in gets so big, that compression is considered, you are doing something wrong. – Waxolunist Dec 6 '13 at 6:55
There are lots of potential use cases. For example, what if the content is being generated by Javascript? You can write JS code to compress data as well, but it would be nicer to have the browser handle it. Time is not the only consideration: if your data is getting big, you may start to care more about bandwidth costs than you do about a little extra time spent processing each request. It really depends on your application. (What if it's an AJAX request and you don't care about response time?) – Nate C-K Mar 28 '14 at 18:48

Your Answer


