.. _users-guide-compression:

Compression
-----------

In Varnish 3.0 we introduced native support for compression, using gzip
encoding. *Before* 3.0, Varnish would never compress objects.

In Varnish 4.0 compression defaults to "on", meaning that it tries to
be smart and do the sensible thing.

If you don't want Varnish tampering with the encoding you can disable
compression all together by setting the parameter `http_gzip_support` to
false. Please see man :ref:`varnishd(1)` for details.

Default behaviour
~~~~~~~~~~~~~~~~~

The default behaviour is active when the `http_gzip_support` parameter
is set to "on" and neither `beresp.do_gzip` nor `beresp.do_gunzip` are
used in VCL.

Unless returning from `vcl_recv` with `pipe` or `pass`, Varnish
modifies `req.http.Accept-Encoding`: if the client supports gzip
`req.http.Accept-Encoding` is set to "gzip", otherwise the header is
removed.

Unless the request is a `pass`, Varnish sets `bereq.http.Accept-Encoding`
to "gzip" before `vcl_backend_fetch` runs, so the header can be changed
in VCL.

If the server responds with gzip'ed content it will be stored in memory
in its compressed form and `Accept-Encoding` will be added to the
`Vary` header.

To clients supporting gzip, compressed content is delivered unmodified.

For clients not supporting gzip, compressed content gets decompressed
on the fly while delivering it. The `Content-Encoding` response header
gets removed and any `Etag` gets weakened (by prepending "W/").

For Vary Lookups, `Accept-Encoding` is ignored.

Compressing content if backends don't
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can tell Varnish to compress content before storing it in cache in
`vcl_backend_response` by setting `beresp.do_gzip` to "true", like this::

    sub vcl_backend_response {
        if (beresp.http.content-type ~ "text") {
            set beresp.do_gzip = true;
        }
    }

With `beresp.do_gzip` set to "true", Varnish will make the following
changes to the headers of the resulting object before inserting it in
the cache:

* set `obj.http.Content-Encoding` to "gzip"
* add "Accept-Encoding" to `obj.http.Vary`, unless already present
* weaken any `Etag` (by prepending "W/")

Generally, Varnish doesn't use much CPU so it might make more sense to
have Varnish spend CPU cycles compressing content than doing it in your
web- or application servers, which are more likely to be CPU-bound.

Please make sure that you don't try to compress content that is
uncompressable, like JPG, GIF and MP3 files. You'll only waste CPU cycles.

Uncompressing content before entering the cache
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can also uncompress content before storing it in cache by setting
`beresp.do_gunzip` to "true". One use case for this feature is to work
around badly configured backends uselessly compressing already compressed
content like JPG images (but fixing the misbehaving backend is always
the better option).

With `beresp.do_gunzip` set to "true", Varnish will make the following
changes to the headers of the resulting object before inserting it in
the cache:

* remove `obj.http.Content-Encoding`
* weaken any `Etag` (by prepending "W/")

.. XXX pending closing #940: remove any "Accept-Encoding" from `obj.http.Vary`

GZIP and ESI
~~~~~~~~~~~~

If you are using Edge Side Includes (ESI) you'll be happy to note that
ESI and GZIP work together really well. Varnish will magically decompress
the content to do the ESI-processing, then recompress it for efficient
storage and delivery.

Turning off gzip support
~~~~~~~~~~~~~~~~~~~~~~~~

When the `http_gzip_support` parameter is set to "off", Varnish does
not do any of the header alterations documented above, handles `Vary:
Accept-Encoding` like it would for any other `Vary` value and ignores
`beresp.do_gzip` and `beresp.do_gunzip`.

A random outburst
~~~~~~~~~~~~~~~~~

Poul-Henning Kamp has written :ref:`phk_gzip` which talks a bit more
about how the implementation works.
