HTTP compression

HTTP compression is a capability built into both client browser and server to compress transmitted data and dramatically improve site performance. This method is built into HTTP 1.1, and most modern browsers that support HTTP 1.1 also support transparent decompression of server response. Browser and server have brief conversation on what data they’d like to receive or send using HTTP headers. For example following is a typical browser request to the main page indicating acceptance of compressed response (note highlighted text):

GET / HTTP/1.1
Host: www.helicontech.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

And HTTP 1.1 aware server could send then compressed response, leaded with the set of HTTP headers as below:

HTTP/1.1 200 OK
Date: Thu, 03 Jan 2007 13:10:17 GMT
Server: Apache/2.0
Vary: Accept-Encoding
Content-Encoding: gzip
Cache-Control: max-age=300
Expires: Thu, 03 Jan 2007 13:10:17 GMT
Content-Length: 1217
Content-Type: text/html; charset=ISO-8859-1

Not all of the content types suitable for compression. Maximum effect would be achieved when text data is compressed, on other hand highly compressed formats like JPG, GIF, PNG could only consume server processor time with no effect on bandwidth.

Helicon Jet comes with a set of pre-configured patterns to decide what data need to be compressed and what level of compression better fits this data format to achieve optimal compression ration with reasonable CPU utilization. Also Helicon Jet is pre-configured to avoid known bugs and drawbacks in different client browsers or third party applications which don’t support compression but indicate this support in request headers.