Geoff,
Another thing I've noticed is that beresp.ttl appears to be -1 in
vcl_fetch after a successful validation request (i.e. the one responded
with 304). With my vcl (which I took from the distribution) it causes
the object to be marked as hit_for_pass.
I've added beresp.status != 304 to prevent this but I think it would be
better if ttl was set as if the object was retrieved in full. In my case
it would be the default ttl as the backend does not provide any.
On 02/03/2011 15:15, Geoff Simmons wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 3/2/11 12:56 PM, Dmitry Panov wrote:
Thanks for the patch. I have tried it and it appears to be working. I've
just spotted one problem so far: it looks like the gziped flag is not
copied from the stale object it is possible to serve gziped object to a
client that doesn't support it. I'm new to varnish and I'm not familiar
with the code yet, but the following patch solved the problem for me:
--- cache_http.c.orig 2011-03-02 11:51:10.000000000 +0000
+++ cache_http.c 2011-03-02 11:05:20.000000000 +0000
@@ -988,6 +988,7 @@
http_SetResp(o->http, "HTTP/1.1", 200, "OK Not Modified");
http_SetH(o->http, HTTP_HDR_REQ, "GET");
http_copyh(o->http, sp->wrk->bereq, HTTP_HDR_URL);
+ sp->obj->gziped = o_stale->gziped;
break;
Good catch, thanks, I've extended the test cases to make sure this works
right from now on. Will be available in the next version.
This is a good point, we may have overlooked fields from struct object
that have to be copied over from stale_obj. We'll take a closer look;
and anyone who's testing the patch might want to keep an eye out for
something similar.
Best,
Geoff
- --
Best regards,
--
Dmitry Panov
_______________________________________________
varnish-dev mailing list
[email protected]
http://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
