In message <[email protected]>, 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
[email protected] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-misc mailing list
[email protected]
http://projects.linpro.no/mailman/listinfo/varnish-misc
