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):
And you’ll get a chart like this:
To verify that Internet Explorer is configured to use the HTTP 1.1 protocol:
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
- Select the Advanced tab
- Under HTTP 1.1 settings, verify that Use HTTP 1.1 is selected (see Figure 1 below).
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
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….