In message <[email protected]>, Per
Buer writes:
>@@ -646,6 +643,22 @@ The following variables are available after the
>requested object has
> been retrieved from the backend, before it is entered into the cache. In
> other words, they are available in vcl_fetch:
>
>+beresp.do_esi
>+ ESI-process the object after fetching it. Defaults to 0. Set it to 1 to
>+ activate ESI.
>+
Set to true/false, it's a boolean, to parse the object for ESI directives.
>+beresp.do_gzip
>+ Gzip the object before storing it. Defaults to 1,
Again true/false, default is false. By default we expect the backend
to do the gzip'ery, we don't know which object types it makes sense
to gzip.
>+beresp.is_gzip
>+ True if the object is compressed.
Havn't implemented that one, would it be useful ?
>+beresp.do_gunzip
>+ Unzip the object before storing it.
correct, again: bool, true/false
>+beresp.is_gunzip
>+ True if the object is not compressed.
not implemented (yet)
> beresp.proto
> The HTTP protocol version used when the object was retrieved.
Actually, the HTTP version the backend replied with.
Also:
req.can_gzip (BOOL)
Does the client accept gzip'ed data ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[email protected] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
[email protected]
http://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
