Conditional GETs

Ricardo Newbery ric at
Fri Jul 27 03:19:11 CEST 2007

On Jul 26, 2007, at 1:40 AM, Poul-Henning Kamp wrote:

> Ricardo Newbery writes:
>> I assume Varnish supports ETags and conditional GETs "If-Modified-
>> Since" (IMS) and "If-None-Match" (INM)?
> Right now we only support IMS, the ETags are mostly a crutch for
> clock-less clients/servers, and varnish isn't relevant in those
> cases.

Sorry, what does this mean precisely?  When an ETagged page is served  
through Varnish, does it not cache?  If it does cache, is it possible  
to code the INM test in vcl?

Vary support without ETag concerns me a bit.  See https://

>> Are IMS/INM requests relayed to the backend before the content is
>> served out of cache?
> No, we check IMS and if it passses, we serve out of cache if cache
> is still valid.

How about an "INM without IMS" request?  Still served out of cache I  
suppose.  Is it possible to modify this behavior via vcl?

>> Do the Cache-Control headers moderating conditional requests ("must-
>> revalidate",  "proxy-revalidate", and "no-cache") modify this  
>> heuristic?
> In general we don't respect cache-control from clients as we are not
> a proxy in the RFC2616 sense, but rather part of the server.

Okay.  If I understand correctly, since Varnish doesn't respect cache- 
control from clients, then backend-generated cache-control like "must- 
revalidate",  "proxy-revalidate", and "no-cache" are unnecessary  
since the "max-age" and "s-maxage" response cache-controls are  
sufficient -- at least as far as the Varnish heuristic is concerned.   

Does Varnish respect "private" and "no-store" in the response?

How about "public"?


More information about the varnish-misc mailing list