dcsimg

HTTP Compression Speeds up the Web Page 2

By ServerWatch Staff (Send Email)
Posted Oct 13, 2000


Yes. Most newer browsers since 1998/1999 have been equipped to support the HTTP 1.1 standard known as "content-encoding." Essentially the browser indicates to the server that it can accept "content encoding" and if the server is capable it will then compress the data and transmit it. The browser decompresses it and then renders the page.

Only HTTP 1.1 compliant clients request compressed files. Clients that are not HTTP 1.1 compliant request and receive the files un-compressed, thereby not benefiting from the improved download times that HTTP 1.1 compliant clients offer. Internet Explorer versions 4 and above, Netscape 4.5 and above, Windows Explorer, and My Computer are all HTTP 1.1 compliant clients by default.

To test your browser, click on this link (works if you are outside a proxy server):

http://12.17.228.52:7000/

And you'll get a chart like this:

Describeme

To verify that Internet Explorer is configured to use the HTTP 1.1 protocol:

  1. Open the Internet Options property sheet
    • If using IE 4, this is located under the View menu
    • If using IE 5, this is located under the Tools menu
  2. Select the Advanced tab
  3. Under HTTP 1.1 settings, verify that Use HTTP 1.1 is selected (see Figure 1 below).
Describeme

IE4/5 Setting HTTP 1.1

What is IETF Content-Encoding (or HTTP Compression)?

In a nutshell... it is simply a publicly defined way to compress HTTP content being transferred from Web Servers down to Browsers using nothing more than public domain compression algorithms that are freely available.

"Content-Encoding" and "Transfer-Encoding" are both clearly defined in the public IETF Internet RFC's that govern the development and improvement of the HTTP protocol which is the "language" of the World Wide Web. "Content-Encoding" applies to methods of encoding and/or compression that have been already applied to documents before they are requested. This is also known as "pre-compressing pages." The concept never really caught on because of the complex file maintenance burden it represents and there are few Internet sites that use pre-compressed pages of any description. "Transfer-Encoding" applies to methods of encoding and/or compression used DURING the actual transmission of the data itself.

In modern practice, however, the two are now one and the same. Since most HTTP content from major online sites is now dynamically generated, the line has blurred between what is happening before a document is requested and while it is being transmitted. Essentially, a dynamically generated HTML page doesn't even exist until someone asks for it. The original concept of all pages being "static" and already present on the disk has quickly become an 'older' concept and the originally well defined separation between "Content-Encoding" and "Transfer-Encoding" has simply turned into a rather pale shade of gray. Unfortunately, the ability for any modern Web or Proxy Server to supply "Transfer-Encoding" in the form of compression is even less available than the spotty support for "Content-Encoding."

Suffice it to say that regardless of the two different publicly defined "Encoding" specifications, if the goal is to compress the requested content (static or dynamic) it really doesn't matter which of the two publicly defined "Encoding" methods is used... the result is still the same. The user receives far fewer bytes than normal and everything happens much faster on the client side. The publicly defined exchange goes like this....



Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.