until now, nobody seems to have noticed ?) and one to control where
we put the temporary allocations for gzip/gunzip.

all of it for gzip buffers.

The tarballs live on repo.varnish-cache.org, not
www.varnish-software.com any longer, so adjust spec file to match.

my section of hell for the dimwits who decided that switching off_t from
32 to 64 bits was too scary to contemplate.

Essentially ignores everything git status would list after a normal build.

vary-matching.  Varnish will adapt whatever we find to the clients
abilities as necessary.

after vcl_recv{}.  This is necessary to get consistent Vary: header
processing.

host system.

from a non-gzip ESI object or during gunzip delivery.

Try again:

    Add the necessary code (& a testcase) to pad out an included
    gzip file, no matter which of the 8 bits of a byte the last bit
    lands in.

gzip file, no matter which of the 8 bits of a byte the last bit
lands in.

residual stopbit we expect.

to come.

indeed gzip'ed data and extracts the magic bits should it ever
be included from ESI.

In general Varnish is not in the business of inspecting content
and with the exception of ESI we still do not do so.

What we do here is make sure that we do not serve corrupt data,
in the same sense as we bail out on chunked encoding trouble or
HTTP header trouble from the backend.

For a limited number of cases we can now esi:include a gzip'ed
object into a gzip'ed ESI object.

There is less than 1 chance in hell this will work for you in
practice, I need to handle the N-1 other cases of last bit
and stop bit combinations in the gziped object, but that is
just a small (but tedious) matter of programming.

objects when we know them.

For now: use malloc for gzip instead of running out of workspace.

in an gzip'ed ESI object.

ESI object.

in a gzip'ed ESI object.