Browsers and servers have brief conversations regarding what they would like to receive and send. Using HTTP headers, they zip messages back and forth over the ether with their content shopping lists. A compression-aware browser tells servers that it would prefer to receive encoded content with a message in an HTTP header like this:
REQUEST GET / HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) Host: www.webcompression.org Connection: Keep-Alive
An HTTP 1.1-compliant server would then deliver the requested document by using an encoding that is acceptable to the client. Here’s a sample response from WebCompression.org:
RESPONSE HTTP/1.1 200 OK Date: Sun, 06 Apr 2008 22:38:00 GMT Server: Apache X-Powered-By: PHP Cache-Control: max-age=300 Expires: Sun, 06 Apr 2008 22:38:00 GMT Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 1168 Keep-Alive: timeout=15 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1
Now the client knows that the server supports gzip content encoding, and it also knows the size of the file is 1,168 bytes (Content-Length). The client downloads the compressed file, decompresses it, and displays the page. Without gzip compression, the home page HTML of WebCompression.org would be 3,183 bytes, about 2.7 times larger in file size (see Figure 9-8).
Figure 9-8. File size savings in HTTP compression (from Port80Software.com tool)