The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

HTTP Compression

To improve transfer speed and optimize bandwidth utilization, an HTTP server may compress data sent in response to an HTTP request. This is called HTTP compression.

The client and the server negotiate compression automatically. A client indicates its support for HTTP compression in the request. Consequently the server will know when it's safe to compress the response and what compression algorithm to use.

For example, a client that supports HTTP compression often sends the following request header:

HTTP request header
Accept-Encoding: deflate, gzip

If the server supports HTTP compression at all, invariably it will support gzip, in which case it might respond with the following response header:

HTTP response header
Content-Encoding: gzip

 In fact, Apache's mod_deflate supports gzip (RFC 1952) only.

A historical anecdote

The use of the word "deflate" in this context is a misnomer. Here "deflate" actually refers to zlib (RFC 1950), which (like gzip) is based on deflate compression (RFC 1951). Historically, this unfortunate choice of words has resulted in incompatibilities, which is why you won't find a server that supports "deflate." This is explained in more detail on the ZLIB FAQ page.
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels