[PATCH] try to explain beresp gzip stuff

[Poul-Henning Kamp]

In message <AANLkTin6OrMJmZwUg9jvnNd9FPOQ6+_n7wANNQd6Mj2M at mail.gmail.com>, 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
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.