varnishd appears to die if error is called from vcl_deliver

[Nathan Uno]

For the record...

I also attempted to restart from vcl_deliver(), figuring I could check
req.restart in vcl_recv() and make decisions there.

Unfortunately, while the VCL_RET_RESTART behavior in vcl_fetch() is to
restart the request at vcl_recv(), the VCL_RET_RESTART behavior for
vcl_deliver() is to INCOMPL(), which involves an abort() and I'm back where
I started.

Any other ideas out there?

Thanks,

Nato


On Fri, Nov 14, 2008 at 11:46 AM, Nathan Uno <nigel_varnish at unos.net> wrote:

> This appears to be because include/vcl_returns.h (varnish 2.0.1) asserts
> that deliver shouldnt' return error:
>
> VCL_MET_MAC(deliver,DELIVER,(VCL_RET_RESTART|VCL_RET_DELIVER))
>
> The documentation (man 7 vcl) indicates that error can be returned from
> vcl_deliver():
>
>              The vcl_deliver subroutine may terminate with one of the
> following key-
>              words:
>
>              error code [reason]
>                      Return the specified error code to the client and
> abandon the
>                      request.
>
>              deliver
>                      Deliver the object to the client.
>
> It looks from the revision history that the change took place between r2341
> and 4 and r3047.  It appears to be a deliberate change because vcl_error()
> calls vcl_deliver().  So it appears there is a documentation bug, not a code
> bug.  >)
>
> What I'm really interested in doing is forcing a document into cache
> without having that document delivered.  I'm attempting to do this by
> defining a URL pattern to hint to varnish to fetch a document with a
> specific hash (i.e. not a hash specific to the particular request).
> vcl_hash() knows what to do and is working properly.  vcl_fetch() knows
> what's going on and sets the infamous magic marker to tell vcl_deliver()
> what's up.
>
> I had thought that I could just then tell vcl_deliver() to generate an
> "error" with HTTP status code of 200 and bogus content and avoid having the
> actual cached document returned.  This, however, seems not to be the case.
>
> Am I overlooking a much simpler way to accomplish my goal?
>
> Thanks,
>
> Nato
>
>
> On Wed, Nov 12, 2008 at 10:34 PM, Nathan Uno <nigel_varnish at unos.net>wrote:
>
>> If I call error from vcl_deliver varnishd appears to die.  For example,
>> the following (nonsensical) definition:
>>
>> sub vcl_deliver {
>>     error 503 "Badness";
>> }
>>
>> ... results in the following varnishlog output (which looks like a crash
>> to me):
>>
>>    10 SessionOpen  c 172.18.26.105 47478 :8081
>>    10 ReqStart     c 172.18.26.105 47478 1731927449
>>    10 RxRequest    c GET
>>    10 RxURL        c /PRIME/mtproxy/mtdata/14/2608/5704/1024
>>    10 RxProtocol   c HTTP/1.1
>>    10 RxHeader     c Accept-Encoding: identity
>>    10 RxHeader     c Host: 172.18.26.105:8081
>>    10 RxHeader     c Connection: close
>>    10 RxHeader     c User-agent: Python-urllib/2.4
>>    10 VCL_call     c recv
>>    10 VCL_return   c lookup
>>    10 VCL_call     c hash
>>    10 VCL_return   c hash
>>    10 VCL_call     c miss
>>    10 VCL_return   c fetch
>>    12 BackendOpen  b default 127.0.0.1 60316 127.0.0.1 8880
>>    10 Backend      c 12 default default
>>    12 TxRequest    b GET
>>    12 TxURL        b /PRIME/mtproxy/mtdata/14/2608/5704/1024
>>    12 TxProtocol   b HTTP/1.1
>>    12 TxHeader     b Accept-Encoding: identity
>>    12 TxHeader     b Host: 172.18.26.105:8081
>>    12 TxHeader     b User-agent: Python-urllib/2.4
>>    12 TxHeader     b X-Varnish: 1731927449
>>    12 TxHeader     b X-Forwarded-For: 172.18.26.105
>>     0 CLI          - Rd vcl.load boot ./vcl.1P9zoqAU.so
>>     0 CLI          - Wr 0 200 Loaded "./vcl.1P9zoqAU.so" as "boot"
>>     0 CLI          - Rd vcl.use boot
>>     0 CLI          - Wr 0 200
>>     0 CLI          - Rd start
>>     0 Debug        - "Acceptor is epoll"
>>     0 CLI          - Wr 0 200
>>     0 WorkThread   - 0x4485ec10 start
>>     0 WorkThread   - 0x4525fc10 start
>>     0 WorkThread   - 0x45c60c10 start
>>     0 WorkThread   - 0x46661c10 start
>>     0 WorkThread   - 0x47062c10 start
>>     0 WorkThread   - 0x47a63c10 start
>>     0 WorkThread   - 0x48464c10 start
>>     0 WorkThread   - 0x48e65c10 start
>>     0 WorkThread   - 0x49866c10 start
>>     0 WorkThread   - 0x4a267c10 start
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20081114/7f2c464e/attachment-0001.html>