mod_deflate Supported Encodings for Compression - apache

It seems to me, that mod_deflate in Apache 2.2 will always return:
Content-Encoding: gzip
and never:
Content-Encoding: deflate
It was explained to me, that although there may be a deflate algorithm, mod_deflate is named after a file-format, in which the algorithm could be any of:
gzip, bzip. pkzip
Of those three, mod_deflate provides gzip.
It seems as though gzip is the most popular and widely-supported algorithm in web browsers, but I know some web servers and proxies do return Content-Encoding: deflate.
Aside from the confusion of the module's name, it true that mod_deflate will only return Content-Encoding: gzip?
Thank you.

The fact is mod_deflate supports only deflate.

Related

HTTP Compression with Apache besides Deflate and gzip?

I have a server, and I want to set up HTTP Compression. How can I use another compression type for HTTP Compression on my own server? I want to experiment with lzop, lzma or xz, for example.
I know I can use gzip and deflate with mod_gzip and mod_deflate, but I am wondering if there are options to expand this selection.
There are only three algorithms officially supported: deflate (zip), compress (lzw) and gzip. You can compress all you want, but no browser won't be able to read it.
Source: RFC 2616, section 3.5.
You can still offer a download of e.g. a bzip2 file, but I guess that's not what you want.

IIS 7 Dynamic Compression is not consistently compressing responses

I have got Dynamic Compression enabled on IIS for all content types.
Requests to my WCF service are sending the following header:
Accept-Encoding: gzip, deflate
And responses from IIS are nearly always being compressed and show the following content in the header:
Content-Type: application/soap+xml; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
However, when the response to a request is large e.g. 14Mb, I'm finding that the the request is not being compressed. The request header includes the accept-encoding statement and the content type is the same, however, the response does not include the content-encoding or vary headers.
Is there a limit to the size of IIS request that can be compressed? My application is working correctly but performing slowly when the responses are big as a result of this problem.

Why are major web sites using gzip?

I just searched about gzip and Deflate, and found out that Deflate is better.
GZip or Deflate for HTTP compression
Why use deflate instead of gzip for text files served by Apache?
Is there any performance hit involved in choosing gzip over deflate for http compression?
Deflate compression browser compatibility and advantages over GZIP
But when I checked the response headers of Google, Facebook and StackExchange, all of them were using GZIP. Why do they use gzip instead of Deflate?
It is apparently due to a misunderstanding resulting from the choice of the name "Deflate". The http standard clearly states that "deflate" really means the zlib format:
The "zlib" format defined in RFC 1950 [31] in combination with
the "deflate" compression mechanism described in RFC 1951 [29].
However early Microsoft servers would incorrectly deliver raw deflate for "Deflate" (i.e. just RFC 1951 data without the zlib RFC 1950 wrapper). This caused problems, browsers had to try it both ways, and in the end it was simply more reliable to only use gzip.
The impact in bandwidth and execution time to use gzip instead of "Deflate" (zlib), is relatively small. So there we are and there it is likely to remain.
The difference is 12 more bytes for gzip and slightly more CPU time to calculate a CRC instead of an Adler-32.

Can mod_deflate compress the output depending on the "Host" header in the Request Headers?

Can mod_deflate compress the output depending on the "Host" header in the Request Headers?
As far as I understand based on the documentation, it is usually done by looking at the User-Agent etc. in the configuration.
I could not find any example in doc that says -
If Host: header is x.y.z then do compression. Else don't do compression.
Thanks!
From the manual:
Compression is implemented by the DEFLATE filter. The following directive will enable compression for documents in the container where it is placed:
SetOutputFilter DEFLATE
Didn't test it, but "container" should include "<VirtualHost>", so just place it only in those VHs you want to deliver compressed responses.

Enable mod_deflate to send Content-Encoding: gzip

EDIT I have found that the problem is actually php minify. This was sending the deflated content instead of Apache. I'll find more on this.
According to High Performance Web Sites, if I enable mod_deflate in Apache 2.x, by adding the following line, it should send gzipped/delfated content: -
AddOutputFilterByType DEFLATE text/html text/css application/x-javascript
The book also says that gzip is more effective than deflate.
I have enabled in httpd.conf by adding the same line. But Apache sends Content-Encoding: deflate.
I tested with CURL using: -
curl -i -H "Accept-Encoding: gzip" "http://192.168.1.33/s.js" >> e:\curl_log.txt
It returns 'gzipped' content. But when I send the command: -
curl -i -H "Accept-Encoding: gzip, deflate" "http://192.168.1.33/s.js" >> e:\curl_log.txt
It returns 'deflated' content.
So, if the browser supports both deflated and gzipped, Apache send deflated. How to tell Apache to prefer gzip over deflate?
FYI: -
I could not find anything in:
http://httpd.apache.org/docs/2.0/mod/mod_deflate.html.
There is no occurrence of no-gzip in
the Apache conf.
Server: Apache/2.2.9 (Win32) PHP/5.2.6
FF sends request header as: "Accept-Encoding: gzip, deflate"
As I see the cause was already found. To further on help getting out of possible confusions:
mod_deflate despite its name is currently only supporting gzip.
gzip is more "effective" because of the following
deflate - despite its name the zlib compression (RFC 1950) should be used (in combination with the deflate compression (RFC 1951)) as described in the RFC 2616. The implementation in the real world however seems to vary between the zlib compression and the (raw) deflate compression[3][4]. Due to this confusion, gzip has positioned itself as the more reliable default method (March 2011).
gzip and zlib are file/stream formats that by default wrap around deflate and amongst other things add a checksum which make them more secure and a little slower. The increase in size on the other hand should not be of any concern.
Also see HTTP_compression - Wikipedia
deflate would be more "efficient" (Frequently Asked Questions about zlib - What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings)
See http://httpd.apache.org/docs/2.0/mod/mod_deflate.html for all the gory details -- are you sure you don't have occurrences of no-gzip elsewhere in the configuration? What happens as you vary your "browser", e.g. by using wget with various values for -U?
I suspect whatever you're using to test is not sending ...
Accept-Encoding: gzip
... in the request header.