With SetInputFilter DEFLATE
I can force the apache to decompress incoming messages. Is there a way to ask the webserver whether it supports decompression of incoming requests. I would expect a specific HEADER information for that. The only HEADER information I know of is: accept-encoding (which is for requests, afaik) and content-encoding (which only tells the client that the response is encoded right?).
![](../../users/profiles/422280.webp)
- 1
- 1
2 Answers
Apache documentation for mod_deflate explains this very clearly:
Input Decompression
The mod_deflate module also provides a filter for decompressing a gzip compressed request body . In order to activate this feature you have to insert the DEFLATE filter into the input filter chain using SetInputFilter or AddInputFilter, for example:
<Location "/dav-area"> SetInputFilter DEFLATE </Location>
Now if a request contains a
Content-Encoding: gzip
header, the body will be automatically decompressed. Few browsers have the ability to gzip request bodies. However, some special applications actually do support request compression, for instance some WebDAV clients.
This means that by setting the input filter to DEFLATE, apache will search the request headers for Content-Encoding: gzip
and will decompress the input only when this header is present.
![](../../users/profiles/30946.webp)
- 16,706
- 4
- 52
- 80
-
Thanks for the hint. But let's say I'am writing a client to send compressed data to the apache but I don't know whether the apache is able to decompress it, is there any way to do that before and decide whether I want to send it compressed or plain ? I am thinking of a header information in the response, so that the client fires a dummy request in the first step to determine whether the apache supports compressed data. – jsalvas Jun 27 '17 at 14:44
Unless specifically configured otherwise, modern browsers and web servers handle the negotiation of the compression scheme automatically. Typically handled in 2 steps whereby the client will advertise supported compression schemes and the server will reply using a compression scheme that both support.
See this article for a fair treatment.
If you do wanted to "check" for it first, you could fetch any asset from the server and parse the value of "Content-Encoding" from the response headers
![](../../users/profiles/106226.webp)
- 171
- 4
-
As far as I understand you are referring to the simple case where the server sends compressed data to the client. In this case the client sends a message with accept-encoding and the server answers with content-encoding header - so far so good. But what I am looking for is the other way around. I don't want the client to advertise the supported compression schemes but the server, so that the client decides whether it sends compressed data or not. – jsalvas Jul 01 '17 at 09:06