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:
If the server supports HTTP compression at all, invariably it will support
gzip, in which case it might compress the response as indicated in the following response header:
A historical anecdote
deflate" in this context is a misnomer. In the HTTP request header above, "
deflate" actually refers to
zlib(RFC 1950), which (like
gzip) is based on
deflatecompression (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.
As it turns out, SAML metadata is highly compressible, as illustrated below:
Shibboleth supports HTTP compression out of the box, with zero configuration. If you know of other metadata client software that supports HTTP compression, please add a comment to this page.