According to RFC 2616, Internet HTTP Compression is a method to send, from the Web server, an HTTP response message in compressed format to a requesting Web browser. This technology assumes that the Web server is capable of encoding the outbound content and the Web browser is capable of (automatically) decoding the received content. HTTP Compression saves transfer data volume and speeds ups Web page load time. This short overview discusses various aspects of HTTP compression, suggest proven solutions, and gives hints to further reading.
HTTP Compression is a publicy defined way to compress content (mostly textual) transferred from Web servers across the world wide Web to browsers. The impact of compression is that the number of transmitted bytes is reduced and thus a higher performance is gained. HTTP Compression uses public domain compression algorithms to encode HTML, XML, JavaScript, CSS and other file formats at the server-side. This standards-based method of delivering compressed content is built into HTTP/1.1, and all modern Web browsers support the HTTP/1.1 protocol, i.e. they can decode compressed files automatically at the client-side. This means, in particular, that no additional software or user interaction on the client-side is required.
More information on HTTP:
http://www.w3.org/Protocols/
When a Web browser loads a Web page, it opens a connection to the Web server and sends an HTTP request to the Web server. A typical HTTP request looks like this:
GET /index.html HTTP/1.1
Host: www.http-compression.com
Accept-Encoding: gzip
User-Agent: Firefox/1.0
With this request, the Web browsers asks for the object "/index.html" on host "www.http-compression.com".
The browser identifies itself as "Firefox/1.0" and claims that it can understand HTTP responses in gzip format.
After parsing and processing the client's request, the Web server may send the HTTP response in compressed format. Then a typical HTTP response looks like this:
HTTP/1.1 200 OK
Server: Apache
Content-Type: text/html
Content-Encoding: gzip
Content-Length: 26395
[GZIP COMPRESSED DATA]
With this response, the Web server tells the browser with status code 200 that he could fulfil the request. In the next line, the Web server identifies itself as Apache. The line "Content-Type" says that it's an HTML document. The response header "Content-Encoding" informs the browser that the following data is compressed with gzip. Finally, the length of the compressed data is stated.
More information:
www.gzip.org/zlib/
More information:
www.gzip.org
In Apache 1.x, there is no native support for HTTP compression.
While there exists modules to add this functionality, they are not offical part of Apache and are not stable.
In Apache 2.x, there is a module named "mod_deflate" that can compress outgoing data.
As this is a relativly simple module that uses standard zlib, it has average performance while lacking flexibility.
httpd.apache.org
Starting with IIS 4.0 (Windows NT Server) Microsoft has implemented HTTP compression support in their Web server.
Unfortunaly, compression in version 4.0 is very problematic and is not recommended to use.
With version 5.0 (Windows 2000 Server), things slightly got better, but again with a lot of problems.
The lastest version 6.0 (Windows 2003 Server) has a reliable support for simple HTTP compression, but is hard to configure.
If you have an IIS Web Server, I recommend to use an ISAPI filter module like IIS Accelerator.
www.microsoft.com/WindowsServer2003/iis/
Starting with version 4.0, Microsoft has implemented support for HTTP compression in their Internet Explorer.
There have been various bugs with older versions of Internet Explorer, described here and here.
www.microsoft.com/windows/ie/
Firefox support HTTP compression without problems.
www.mozilla.org/products/firefox/
Starting with version 4.06, Netscape Navigator sends the "Accept-Encoding: gzip" header.
This browser has some serious problems concerning HTTP compression that are fixed in version 6.02 and higher.
www.netscape.com
Starting with version 5.12, Opera understands gzip compressed HTTP responses.
There are no serious problems known.
www.opera.com
by S. Radhakrishnan
The author, Constantin Rack, has more than 6 years of experience with HTTP compression.
In 2000, he founded VIGOS, a software company
specialised on fast, secure and reliable HTTP compression tools.
If you have any questions about HTTP Compression, feel free to write him:
VIGOS AG, Attn: Constantin Rack, Steubenstr. 26a, 58097 Hagen, Germany
constantin.rack@vigos.com
This Web site and its content is copyrighted 2005 by Constantin Rack. All rights reserved. Last modified: 2005-05-05.