varnishd appears to die if error is called from vcl_deliver

[Nathan Uno]

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/9df35537/attachment-0001.html>