Conditional Requests (revisited)
brian at briansmith.org
Tue May 6 05:06:19 CEST 2008
Poul-Henning Kamp wrote:
> Brian Smith writes:
>>(1) I have a back-end that is very fast for validating ETags and
>>304 Not Modified, but very slow when it has to return a new response body.
>>My understanding is that Varnish will never send conditional requests to
>>backend, and it cannot use a 304 response to update the freshness
>>information for an already-cached response.
>>Would you be willing to accept patches to implement that behavior in the
> Provided they are well thought out: yes, then all patches are welcome.
> Think hard about how to enable this sensibly in VCL.
I am not sure I will go ahead and implement this but I did think about it a
little bit. In VCL, we can run different instructions for a cache hit or a
cache miss. As far as I understand, a cache hit occurs whenever Varnish is
able to return a response from the cache without contacting the back-end,
and a miss occurs otherwise. However, I think a third case is needed:
vcl_stale, where there is a cached entry but it is out of date. To me, it
seems like Varnish could manage stale hits itself (without running any VCL
code), by automatically revalidating with the back-end, processing the
response, and then calling the hit VCL or the miss VCL, based on whether the
response was a 304.
In other words, it seems reasonable to implement this in such a way that
there would be no changes to VCL. Do you think that is reasonable?
One benefit to doing everthing automatically is that, when we have
"varnishd -t 0" and no VCL file, Varnish would become a transparent cache
(in the RFC 2616 sense). Even though the developers seem to not find the
idea of a transparent cache very compelling, I think such functionality
would make Varnish compelling for many more users.
More information about the varnish-misc