[Varnish] #795: Conditional GETs based on modification time are not honored if Last-Modified was not explicitly set
Varnish
varnish-bugs at varnish-cache.org
Mon Oct 18 17:13:12 CEST 2010
#795: Conditional GETs based on modification time are not honored if Last-
Modified was not explicitly set
----------------------+-----------------------------------------------------
Reporter: runa | Type: defect
Status: closed | Priority: normal
Milestone: | Component: build
Version: 2.0 | Severity: normal
Resolution: wontfix | Keywords:
----------------------+-----------------------------------------------------
Changes (by phk):
* status: new => closed
* resolution: => wontfix
Comment:
I can see why you would want to do that, but I am not comfortable
synthesizing a L-M header in Varnish by default.
RFC2616 is quite clear that the only valid reasons for a backend to not
offer a L-M header is A) Can't, or B) Won't.
You are probably talking about the A) case, where the backend does not
produce a L-M header for whatever deficient excuses it might have.
I'm worried about the B) case, where the backend deliberately does not
want a L-M header in order to maintain tight control of the semantic
integrity of the object.
In that case a synthetic L-M header may lead to wrong caching
assumptions/decisions down-stream, (See p88 of RFC2616 for some legal but
weird assumptions based on L-M headers) which conflict with the way the
backend manages the object (purges ?).
But that should not leave you stranded: If you synthesize a L-M header in
VCL, I belive things will work as you expect:
{{{
sub vcl_fetch {
if (!beresp.http.last-modified) {
set beresp.http.last-modified = beresp.http.date;
}
}
}}}
Please report back on this, so we can document this corner-case.
--
Ticket URL: <http://varnish-cache.org/trac/ticket/795#comment:1>
Varnish <http://varnish-cache.org/>
The Varnish HTTP Accelerator
More information about the varnish-bugs
mailing list