[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


 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