Section 5.10 VCL - vcl_fetch
Page 77
5.10 VCL - vcl_fetch • Sanitize server-response • Override cache duration The vcl_fetch function is the backend-counterpart to vcl_recv. In vcl_recv you can use information provided by the client to decide on caching policy, while you use information provided by the server to further decide on a caching policy in vcl_fetch. If you chose to pass the request in an earlier VCL function (e.g.: vcl_recv), you will still execute the logic of vcl_fetch, but the object will not enter the cache even if you supply a cache time. You have multiple tools available in vcl_fetch. First and foremost you have the beresp.ttl variable, which defines how long an object is kept.
Warning If the request was not passed before reaching vcl_fetch, the beresp.ttl is still used even when you perform a hit_for_pass in vcl_fetch. This is an important detail that is important to remember: When you perform a pass in vcl_fetch you cache the decision you made. In other words: If beresp.ttl is 10 hours and you issue a pass, an object will be entered into the cache and remain there for 10 hours, telling Varnish not to cache. If you decide not to cache a page that returns a "500 Internal Server Error", for example, this is critically important, as a temporary glitch on a page can cause it to not be cached for a potentially long time. Always set beresp.ttl when you issue a pass in vcl_fetch.
Returning deliver in vcl_fetch tells Varnish to cache, if possible. Returning hit_for_pass tells it not to cache, but does not run the vcl_pass function of VCL for this specific client. The next client asking for the same resource will hit the hitpass-object and go through vcl_pass. Typical tasks performed in vcl_fetch include: • Overriding cache time for certain URLs • Stripping Set-Cookie headers that are not needed • Stripping bugged Vary headers • Adding helper-headers to the object for use in banning (more information in later chapters) • Applying other caching policies