Understand "hit for pass" cache objects

[Poul-Henning Kamp]

In message <4B79C2F1.9050901 at newmediagateway.com>, Justin Pasher writes:

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

Correct.

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

I guess you could do that, something like:

	sub vcl_fetch {
		set req.http.myfoo = beresp.http.set-cookie;
		unset beresp.http.set-cookie;
	}

	sub vcl_deliver {
		if (req.http.myfoo) {
			set resp.http.set-cookie = req.http.myfoo;
		}
	}

But doing this means that the next user that comes without the
cookie, will get the cached copy, and no set-cookie header ?

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