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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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 >> >> >
_______________________________________________ varnish-dev mailing list varnish-dev@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-dev