Mailing List Archive

Fetch called after pass
Hello.

After reading the vcl man page I was under the impression that after
a "pass" return from vcl_recv the request was simply forwarded to the
backend and the response would NOT be cached. In other words:

pass - bypass cache and just forward response from backend.
pipe - bypass cache and possibly insert response into cache depending
no vcl_fetch
lookup - look at cache and if not found contact backend, etc, etc.

But from the log bellow I see fetch being called after a pass (and in
this case the response gets inserted into the cache). Are my
assumptions wrong?

btw I'm using trunk from 3/07/2007.

Regards,
Andr? Cruz


0 WorkThread 0xb4bd6134 start
11 SessionOpen c 10.134.145.2 51268
11 ReqStart c 10.134.145.2 51268 1192805805
11 RxRequest c GET
11 RxURL c /index.bml
11 RxProtocol c HTTP/1.1
11 RxHeader c Host: andre.localhost:8080
11 RxHeader c User-Agent: Mozilla/5.0 (Macintosh; U; Intel
Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
11 RxHeader c Accept: text/xml,application/xml,application/
xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
11 RxHeader c Accept-Language: en-us,en;q=0.5
11 RxHeader c Accept-Encoding: gzip,deflate
11 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
11 RxHeader c Keep-Alive: 300
11 RxHeader c Connection: keep-alive
11 RxHeader c Cookie: ljuniq=btZhgKFp2s9UaAi:1183474072;
ljuniq=btZhgKFp2s9UaAi:1183474005; ljsession=ws:infernogelado:
244:RZWHic6Puc; ljsession=ws:infernogelado:244:RZWHic6Puc
11 RxHeader c If-None-Match: "98eb61ba9c2e7b12d4fce78c559bf1fc"
11 VCL_call c recv
11 VCL_return c pass
11 VCL_call c pass
11 VCL_return c pass
11 VCL_call c recv
11 VCL_return c pass
11 VCL_call c pass
11 VCL_return c pass
14 BackendOpen b default 127.0.0.1 55997 127.0.0.1 80
14 BackendXID b 1192805805
11 Backend c 14 default
14 TxRequest b GET
14 TxURL b /index.bml
14 TxProtocol b HTTP/1.1
14 TxHeader b Host: andre.localhost:8080
14 TxHeader b User-Agent: Mozilla/5.0 (Macintosh; U; Intel
Mac OS X; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
14 TxHeader b Accept: text/xml,application/xml,application/
xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
14 TxHeader b Accept-Language: en-us,en;q=0.5
14 TxHeader b Accept-Encoding: gzip,deflate
14 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
14 TxHeader b Cookie: ljuniq=btZhgKFp2s9UaAi:1183474072;
ljuniq=btZhgKFp2s9UaAi:1183474005; ljsession=ws:infernogelado:
244:RZWHic6Puc; ljsession=ws:infernogelado:244:RZWHic6Puc
14 TxHeader b X-Varnish: 1192805805
14 TxHeader b X-Forwarded-for: 10.134.145.2
14 RxProtocol b HTTP/1.1
14 RxStatus b 200
14 RxResponse b OK
14 RxHeader b Date: Wed, 04 Jul 2007 14:18:00 GMT
14 RxHeader b Server: Apache/1.3.34 (Ubuntu) mod_perl/1.29
14 RxHeader b Cache-Control: private, proxy-revalidate
14 RxHeader b ETag: "98eb61ba9c2e7b12d4fce78c559bf1fc"
14 RxHeader b Content-length: 7749
14 RxHeader b Content-Type: text/html; charset=utf-8
14 RxHeader b Content-Language: en
11 ObjProtocol c HTTP/1.1
11 ObjStatus c 200
11 ObjResponse c OK
11 ObjHeader c Date: Wed, 04 Jul 2007 14:18:00 GMT
11 ObjHeader c Server: Apache/1.3.34 (Ubuntu) mod_perl/1.29
11 ObjHeader c Cache-Control: private, proxy-revalidate
11 ObjHeader c ETag: "98eb61ba9c2e7b12d4fce78c559bf1fc"
11 ObjHeader c Content-Type: text/html; charset=utf-8
11 ObjHeader c Content-Language: en
11 ObjHeader c Content-Length: 7749
14 BackendReuse b default
11 TTL c 1192805805 RFC 120 1183558680 1183558680 0 0 0
11 VCL_call c fetch
11 VCL_return c insert
11 Length c 7749
11 TxProtocol c HTTP/1.1
11 TxStatus c 200
11 TxResponse c OK
11 TxHeader c Date: Wed, 04 Jul 2007 14:18:00 GMT
11 TxHeader c Server: Apache/1.3.34 (Ubuntu) mod_perl/1.29
11 TxHeader c Cache-Control: private, proxy-revalidate
11 TxHeader c ETag: "98eb61ba9c2e7b12d4fce78c559bf1fc"
11 TxHeader c Content-Type: text/html; charset=utf-8
11 TxHeader c Content-Language: en
11 TxHeader c Content-Length: 7749
11 TxHeader c X-Varnish: 1192805805
11 TxHeader c Age: 0
11 TxHeader c Via: 1.1 varnish
11 ReqEnd c 1192805805 1183558680.398978585
1183558680.420266415 0.000327788 0.021247632 0.000040198
0 StatAddr 10.134.145.2 0 0 1 1 0 0 1 319 7749
Fetch called after pass [ In reply to ]
Hi Andre,

The state diagram has morphed a bit lately, DES is busy updating the
documentation and hopefully this will be covered RSN.

In the meantime, here is a snapshot of the current -trunks stateenginge:

http://phk.freebsd.dk/misc/_.pdf

This is machine generated, see comment at the top of cache_center.c

We collapsed the pass and fetch code, after all, it does the same
basic thing, the distinction is only what happens to the object
afterwards: is it cached or thrown away.

That way we eliminated a lot of almost, but not entirely identical
code and got rid a number of problems in the pass version of the
code, that were already fixed in the fetch version.

So short version: yes, pass goes on to fetch (and now from there
to deliver), but the object is not cached.

--
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.
Fetch called after pass [ In reply to ]
Hello Poul.

Thanks for the quick answer.

On 2007/07/04, at 17:30, Poul-Henning Kamp wrote:

>
> The state diagram has morphed a bit lately, DES is busy updating the
> documentation and hopefully this will be covered RSN.
>
> In the meantime, here is a snapshot of the current -trunks
> stateenginge:
>
> http://phk.freebsd.dk/misc/_.pdf
>
> So short version: yes, pass goes on to fetch (and now from there
> to deliver), but the object is not cached.
>

From what I can see, if vcl_recv() returns "pass" the request can
still be cached by logic in vcl_fetch(), right?

Because that's what I think is happening in my case. The default
vcl_fetch() handler is inserting the request in cache even though it
got a "pass" earlier... Do we have to manual check the obj.pass flag
in the handler?

Thanks,
Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.linpro.no/pipermail/varnish-misc/attachments/20070704/6a44010c/attachment.htm
Fetch called after pass [ In reply to ]
In message <CE9C9DDB-B243-4572-BD4B-0EF419D358B2 at segula.pt>, =?ISO-8859-1?Q?And
r=E9_Cruz?= writes:

> From what I can see, if vcl_recv() returns "pass" the request can
>still be cached by logic in vcl_fetch(), right?

No, this is one of the things that figure does not show: the object
created by vcl_pass() is not in the hash table at all, so no matter
what vcl_fetch() does, it will not be cached.

>Because that's what I think is happening in my case. The default
>vcl_fetch() handler is inserting the request in cache even though it
>got a "pass" earlier... Do we have to manual check the obj.pass flag
>in the handler?

That would be a bug.

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