Hello, I have just started using Varnish 2.0.6 in the past week as a replacement for Squid. So far, I love the fine grained control you have over what goes into cache (as opposed to Squid's "I'll cache it when I feel it's supposed to be cached, but not tell you why" approach). That said, I'm trying to better understand the "hit for pass" cache objects that Varnish will sometimes create. Here is basic flow of my vcl (much of it is based on the concepts on the intro page: http://varnish-cache.org/wiki/Introduction)
vcl_recv: Default action is "lookup". Action changes to "pass" if ... * Cache-Control or Pragma headers has "no-cache" * HTTP auth is in use (Authorization header) * Request contains cookie "bypass_cache=true" * Request type is not GET, HEAD, POST, PUT, TRACE, OPTIONS, DELETE vcl_fetch: Default action is "deliver". Action changes to "pass" if ... * Response is deemed uncacheable (!obj.cacheable) * Response contains Cache-Control headers that say "no-cache" * HTTP auth is in use (Authorization header) * Request contains cookie "bypass_cache=true" * Response contains Set-Cookie header Now on to the problem at hand. My understanding (please correct any errors) of the "hit for pass" object is that any time the action is "pass" within vcl_fetch, Varnish will create a "hit for pass" object to make future requests for the same URL hash go straight to the back end instead of lining them up serially and waiting for a response from the first request. Until that object's TTL expires, the "hit for pass" object will remain in cache and never be replaced with a fresh object from the backend. Here is what is happening my my example. Client A visits the URL http://www.example.com/. Since this is the first time they visit the site, the backend code tries to start a session (PHP code), which sends a Set-Cookie header in the response. In vcl_fetch, Varnish sees the Set-Cookie header and issues the "pass" action. Now there is a "hit for pass" cache object with a TTL based upon the Cache-Control/Expires headers or the default TTL (let's assume 120 seconds). Client B visit the same URL http://www.example.com/. Varnish finds a "hit for pass" object in the cache, so it sends the request directly to the backend. This same thing will continue for any future clients until 120 seconds have elapsed. Herein lies my dilemma. A request for the same URL (http://www.example.com/) is sometimes cacheable and sometimes not cacheable (it usually depends on whether it's the first time a user visits the site and the Set-Cookie header has to be sent). What this means is if I have a very heavy hit URL as a landing page from Google, most of the time there will be a "hit for pass" cache object in Varnish, since most people going to that page will have a Set-Cookie header. The only time it will cache the page is if I'm lucky and someone visits the page while there is no "hit for pass" cache object and their request doesn't result in a "pass" action from vcl_fetch. In my situation, I think I could avoid this problem altogether if I could make Varnish store a DIFFERENT set of headers in the cache object than the headers return to the client. For example, if I receive a response with a Set-Cookie header, I would remove the Set-Cookie header from the soon-to-be-cached object (so it wouldn't serve that header up for everyone), but LEAVE the Set-Cookie header for the individual that made the original request. This would allow the page to cache normally even if the only requests going to that page result in a Set-Cookie header. However, from what I've been able to see, there is no way to do this. Does anyone have any recommendations to get around this? In a perfect world, my caching server would work this way: * vcl_recv: If any criteria from A through D are met, don't pull this request from cache and go to the backend * vcl_fetch: If any criteria from E through G are met, send the object straight to the client without touching the cache. The "without touching the cache" portion seems to be where I am falling down. -- Justin Pasher _______________________________________________ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
