r1277 - in trunk/varnish-cache: bin/varnishd include lib/libvcl

[Poul-Henning Kamp]

In message <ujrirclrcw6.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>phk at projects.linpro.no writes:
>> Pipe and Pass calls vcl_pipe{} and vcl_pass{} respectively, before
>> contacting the backend.  I havn't quite decided if they should
>> operate on the request header from the client or the one to the
>> backend, or both.
>
>I'm working on the documentation, and have a couple of questions
>regarding these.
>
>1) VCL_pipe_method() is never called

Not yet, havn't gotten to that yet.  Same for the vcl_hash {} as
far as I recall.

>2) The return value from VCL_pass_method() is ignored unless it is
>   VCL_RET_ERROR:

Only error and pass are valid (see include/vcl_returns.h)

The pass and pipe methods are for twapping headers and stuff
before hitting the backend.  They can only error or continue.

>3) The default implementations of vcl_pipe() and vcl_pass() end with
>   "pipe" and "pass", respectively, which one would expect to result
>   in infinite recursion (though we know from 2) that it doesn't)

No risk.  The return action, for instance "pass", is interpreted in
context (of the state engine), and as you saw, in this case it
really means "go on".

>4) What is the "hash" keyword supposed to mean?
>
>> +    "sub default_vcl_hash {\n"
>> +    "    hash;\n"
>> +    "}\n"

Same basic semantics.  I don't expect to see the "hash" anywhere
but in the default code.

The idea for the vcl_hash{} method is to make it possible
to control which fields to hash.

The default vcl_hash will end up looking somewhat like:

	sub vcl_hash {
		hashkey += req.url;
		hashkey += req.http.Host;
		hash;
	}

(not sure about syntax yet)

-- 
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.