1VCL(7) VCL(7)
2
6 VCL - Varnish Configuration Language
7
9 The VCL language is a small domain-specific language designed to be
10 used to define request handling and document caching policies for the
11 Varnish HTTP accelerator.
12 When a new configuration is loaded, the varnishd management process
14 translates the VCL code to C and compiles it to a shared object which
15 is then dynamically linked into the server process.
16
18 The VCL syntax is very simple, and deliberately similar to C and Perl.
19 Blocks are delimited by curly braces, statements end with semicolons,
20 and comments may be written as in C, C++ or Perl according to your own
21 preferences.
22 In addition to the C-like assignment (=), comparison (==) and boolean
24 (!, && and ||) operators, VCL supports regular expression and ACL
25 matching using the ~ operator.
26 Unlike C and Perl, the backslash () character has no special meaning in
28 strings in VCL, which use the (%xx) escape mechanism just like URLs, so
29 it can be freely used in regular expressions without doubling.
30 Strings are concatenated by just putting them one after each other
32 without any operator in between.
33 Assignments are introduced with the set keyword. There are no
35 user-defined variables; values can only be assigned to variables
36 attached to backend, request or document objects. Most of these are
37 typed, and the values assigned to them must have a compatible unit suf‐
38 fix.
39 You can use the set keyword to arbitrary HTTP headers. You can remove
41 headers with the remove or unset keywords, which are synonym.
42 The return(action) keyword terminates the subroutine. action can be,
44 depending on context one of
45 · deliver
47 · error
49 · fetch
51 · hash
53 · lookup
55 · pass
57 · pipe
59 · restart
61 Please see the list of subroutines to see what return actions are
63 available where.
64 VCL has if tests, but no loops.
66 You may log arbitrary strings to the shared memory log with the keyword
68 log.
69 The contents of another VCL file may be inserted at any point in the
71 code by using the include keyword followed by the name of the other
72 file as a quoted string.
73 Backend declarations
75 A backend declaration creates and initializes a named backend object::
76 backend www {
78 .host = "www.example.com";
79 .port = "http";
80 }
81 The backend object can later be used to select a backend at request
83 time::
84 if (req.http.host ~ "^(www.)?example.com$") {
86 set req.backend = www;
87 }
88 To avoid overloading backend servers, .max_connections can be set to
90 limit the maximum number of concurrent backend connections.
91 The timeout parameters can be overridden in the backend declaration.
93 The timeout parameters are .connect_timeout for the time to wait for a
94 backend connection, .first_byte_timeout for the time to wait for the
95 first byte from the backend and .between_bytes_timeout for time to wait
96 between each received byte.
97 These can be set in the declaration like this::
99 backend www {
101 .host = "www.example.com";
102 .port = "http";
103 .connect_timeout = 1s;
104 .first_byte_timeout = 5s;
105 .between_bytes_timeout = 2s;
106 }
107 To mark a backend as unhealthy after number of items have been added to
109 it's saintmode list .saintmode_threshold can be set to the maximum list
110 size. Setting a value of 0 disables saintmode checking entirely for
111 that backend. The value in the backend declaration overrides the
112 parameter.
113 Directors
115 A director is a logical group of backend servers clustered together for
116 redundancy. The basic role of the director is to let Varnish choose a
117 backend server amongst several so if one is down another can be used.
118 There are several types of directors. The different director types use
120 different algorithms to choose which backend to use.
121 Configuring a director may look like this::
123 director b2 random {
125 .retries = 5;
126 {
127 // We can refer to named backends
128 .backend = b1;
129 .weight = 7;
130 }
131 {
132 // Or define them inline
133 .backend = {
134 .host = "fs2";
135 }
136 .weight = 3;
137 }
138 }
139 The random director
141 The random director takes one per director option .retries. This spec‐
142 ifies how many tries it will use to find a working backend. The
143 default is the same as the number of backends defined for the director.
144 There is also a per-backend option: weight which defines the portion of
146 traffic to send to the particular backend.
147 The round-robin director
149 The round-robin director does not take any options.
150 The client director
152 The client director picks a backend based on the clients identity. You
153 can set the VCL variable client.identity to identify the client by
154 picking up the value of a session cookie or similar.
155 Note: in 2.1 client.identity isn't available and the director will use
157 client.ip to distribute clients across backends.
158 The client director takes one option - retries which set the number of
160 retries the director should take in order to find a healthy backend.
161 The hash director
163 The hash director will pick a backend based on the URL hash value.
164 This is useful is you are using Varnish to load balance in front of
166 other Varnish caches or other web accelerators as objects won't be
167 duplicated across caches.
168 The client director takes one option - retries which set the number of
170 retries the director should take in order to find a healthy backend.
171 The DNS director
173 The DNS director can use backends in three different ways. Either like
174 the random or round-robin director or using .list:
175 director directorname dns {
177 .list = {
178 .host_header = "www.example.com";
179 .port = "80";
180 .connect_timeout = 0.4;
181 "192.168.15.0"/24;
182 "192.168.16.128"/25;
183 }
184 .ttl = 5m;
185 .suffix = "internal.example.net";
186 }
187 This will specify 384 backends, all using port 80 and a connection
189 timeout of 0.4s. Options must come before the list of IPs in the .list
190 statement.
191 The .ttl defines the cache duration of the DNS lookups.
193 The above example will append "internal.example.net" to the incoming
195 Host header supplied by the client, before looking it up. All settings
196 are optional.
197 Backend probes
199 Backends can be probed to see whether they should be considered healthy
200 or not. The return status can also be checked by using req.back‐
201 end.healthy .window is how many of the latest polls we examine, while
202 .threshold is how many of those must have succeeded for us to consider
203 the backend healthy. .initial is how many of the probes are considered
204 good when Varnish starts - defaults to the same amount as the thresh‐
205 old.
206 A backend with a probe can be defined like this::
208 backend www {
210 .host = "www.example.com";
211 .port = "http";
212 .probe = {
213 .url = "/test.jpg";
214 .timeout = 0.3 s;
215 .window = 8;
216 .threshold = 3;
217 .initial = 3;
218 }
219 }
220 It is also possible to specify the raw HTTP request:
222 backend www {
224 .host = "www.example.com";
225 .port = "http";
226 .probe = {
227 # NB: \r\n automatically inserted after each string!
228 .request =
229 "GET / HTTP/1.1"
230 "Host: www.foo.bar"
231 "Connection: close";
232 }
233 }
234 ACLs
236 An ACL declaration creates and initializes a named access control list
237 which can later be used to match client addresses::
238 acl local {
240 "localhost"; // myself
241 "192.0.2.0"/24; // and everyone on the local network
242 ! "192.0.2.23"; // except for the dialin router
243 }
244 If an ACL entry specifies a host name which Varnish is unable to
246 resolve, it will match any address it is com‐ pared to. Consequently,
247 if it is preceded by a negation mark, it will reject any address it is
248 compared to, which may not be what you intended. If the entry is
249 enclosed in parentheses, however, it will simply be ignored.
250 To match an IP address against an ACL, simply use the match operator::
252 if (client.ip ~ local) {
254 return (pipe);
255 }
256 Functions
258 The following built-in functions are available:
259 hash_data(str)
261 Adds a string to the hash input. In default.vcl hash_data() is
262 called on the host and URL of the request.
263 regsub(str, regex, sub)
265 Returns a copy of str with the first occurrence of the regular
266 expression regex replaced with sub. Within sub, 0 (which can
267 also be spelled &) is replaced with the entire matched string,
268 and n is replaced with the contents of subgroup n in the matched
269 string.
270 regsuball(str, regex, sub)
272 As regsuball() but this replaces all occurrences.
273 purge_url(regex)
275 Purge all objects in cache whose URLs match regex.
276 Subroutines
278 A subroutine is used to group code for legibility or reusability::
279 sub pipe_if_local {
281 if (client.ip ~ local) {
282 return (pipe);
283 }
284 }
285 Subroutines in VCL do not take arguments, nor do they return values.
287 To call a subroutine, use the call keyword followed by the subroutine's
289 name:
290 call pipe_if_local;
292 There are a number of special subroutines which hook into the Varnish
294 workflow. These subroutines may inspect and manipulate HTTP headers
295 and various other aspects of each request, and to a certain extent
296 decide how the request should be handled. Each subroutine terminates
297 by calling one of a small number of keywords which indicates the
298 desired outcome.
299 vcl_recv
301 Called at the beginning of a request, after the complete request
302 has been received and parsed. Its purpose is to decide whether
303 or not to serve the request, how to do it, and, if applicable,
304 which backend to use.
305 The vcl_recv subroutine may terminate with calling return() on
307 one of the following keywords:
308 error code [reason]
310 Return the specified error code to the client and abandon
311 the request.
312 pass Switch to pass mode. Control will eventually pass to
314 vcl_pass.
315 pipe Switch to pipe mode. Control will eventually pass to
317 vcl_pipe.
318 lookup Look up the requested object in the cache. Control will
320 eventually pass to vcl_hit or vcl_miss, depending on
321 whether the object is in the cache.
322 vcl_pipe
324 Called upon entering pipe mode. In this mode, the request is
325 passed on to the backend, and any further data from either
326 client or backend is passed on unaltered until either end closes
327 the connection.
328 The vcl_pipe subroutine may terminate with calling return() with
330 one of the following keywords:
331 error code [reason]
333 Return the specified error code to the client and abandon
334 the request.
335 pipe Proceed with pipe mode.
337 vcl_pass
339 Called upon entering pass mode. In this mode, the request is
340 passed on to the backend, and the backend's response is passed
341 on to the client, but is not entered into the cache. Subsequent
342 requests sub‐ mitted over the same client connection are handled
343 normally.
344 The vcl_recv subroutine may terminate with calling return() with
346 one of the following keywords:
347 error code [reason]
349 Return the specified error code to the client and abandon
350 the request.
351 pass Proceed with pass mode.
353 restart
355 Restart the transaction. Increases the restart counter.
356 If the number of restarts is higher than max_restarts
357 varnish emits a guru meditation error.
358 vcl_hash
360 You may call hash_data() on the data you would like to add to
361 the hash.
362 The vcl_hash subroutine may terminate with calling return() with
364 one of the following keywords:
365 hash Proceed.
367 vcl_hit
369 Called after a cache lookup if the requested document was found
370 in the cache.
371 The vcl_hit subroutine may terminate with calling return() with
373 one of the following keywords:
374 deliver
376 Deliver the cached object to the client. Control will
377 eventually pass to vcl_deliver.
378 error code [reason]
380 Return the specified error code to the client and abandon
381 the request.
382 pass Switch to pass mode. Control will eventually pass to
384 vcl_pass.
385 restart
387 Restart the transaction. Increases the restart counter.
388 If the number of restarts is higher than max_restarts
389 varnish emits a guru meditation error.
390 vcl_miss
392 Called after a cache lookup if the requested document was not
393 found in the cache. Its purpose is to decide whether or not to
394 attempt to retrieve the document from the backend, and which
395 backend to use.
396 The vcl_miss subroutine may terminate with calling return() with
398 one of the following keywords:
399 error code [reason]
401 Return the specified error code to the client and abandon
402 the request.
403 pass Switch to pass mode. Control will eventually pass to
405 vcl_pass.
406 fetch Retrieve the requested object from the backend. Control
408 will eventually pass to vcl_fetch.
409 vcl_fetch
411 Called after a document has been successfully retrieved from the
412 backend.
413 The vcl_fetch subroutine may terminate with calling return()
415 with one of the following keywords:
416 deliver
418 Possibly insert the object into the cache, then deliver
419 it to the client. Control will eventually pass to
420 vcl_deliver.
421 error code [reason]
423 Return the specified error code to the client and abandon
424 the request.
425 esi ESI-process the document which has just been fetched.
427 pass Switch to pass mode. Control will eventually pass to
429 vcl_pass.
430 restart
432 Restart the transaction. Increases the restart counter.
433 If the number of restarts is higher than max_restarts
434 varnish emits a guru meditation error.
435 vcl_deliver
437 Called before a cached object is delivered to the client.
438 The vcl_deliver subroutine may terminate with one of the follow‐
440 ing keywords:
441 deliver
443 Deliver the object to the client.
444 error code [reason]
446 Return the specified error code to the client and abandon
447 the request.
448 restart
450 Restart the transaction. Increases the restart counter.
451 If the number of restarts is higher than max_restarts
452 varnish emits a guru meditation error.
453 vcl_error
455 Called when we hit an error, either explicitly or implicitly due
456 to backend or internal errors.
457 The vcl_error subroutine may terminate by calling return with
459 one of the following keywords:
460 deliver
462 Deliver the error object to the client.
463 restart
465 Restart the transaction. Increases the restart counter.
466 If the number of restarts is higher than max_restarts
467 varnish emits a guru meditation error.
468 If one of these subroutines is left undefined or terminates without
470 reaching a handling decision, control will be handed over to the
471 builtin default. See the EXAMPLES section for a listing of the default
472 code.
473 Multiple subroutines
475 If multiple subroutines with the same name are defined, they are con‐
476 catenated in the order in which the appear in the source.
477 Example::
479 # in file "main.vcl"
481 include "backends.vcl";
482 include "purge.vcl";
483 # in file "backends.vcl"
485 sub vcl_recv {
486 if (req.http.host ~ "example.com") {
487 set req.backend = foo;
488 } elsif (req.http.host ~ "example.org") {
489 set req.backend = bar;
490 }
491 }
492 # in file "purge.vcl"
494 sub vcl_recv {
495 if (client.ip ~ admin_network) {
496 if (req.http.Cache-Control ~ "no-cache") {
497 purge_url(req.url);
498 }
499 }
500 }
501 The builtin default subroutines are implicitly appended in this way.
503 Variables
505 Although subroutines take no arguments, the necessary information is
506 made available to the handler subroutines through global variables.
507 The following variables are always available:
509 now The current time, in seconds since the epoch.
511 The following variables are available in backend declarations:
513 .host
515 Host name or IP address of a backend.
517 .port
519 Service name or port number of a backend.
521 The following variables are available while processing a request:
523 client.ip
525 The client's IP address.
526 server.hostname
528 The host name of the server.
529 server.identity
531 The identity of the server, as set by the -i parameter. If the
532 -i parameter is not passed to varnishd, server.identity will be
533 set to the name of the instance, as specified by the -n parame‐
534 ter.
535 server.ip
537 The IP address of the socket on which the client connection was
538 received.
539 server.port
541 The port number of the socket on which the client connection was
542 received.
543 req.request
545 The request type (e.g. "GET", "HEAD").
546 req.url
548 The requested URL.
549 req.proto
551 The HTTP protocol version used by the client.
552 req.backend
554 The backend to use to service the request.
555 req.backend.healthy
557 Whether the backend is healthy or not. Requires an active probe
558 to be set on the backend.
559 req.http.header
561 The corresponding HTTP header.
562 req.hash_always_miss
564 Force a cache miss for this request. If set to true Varnish will
565 disregard any existing objects and always (re)fetch from the
566 backend.
567 req.hash_ignore_busy
569 Ignore any busy object during cache lookup. You would want to do
570 this if you have two server looking up content from each other
571 to avoid potential deadlocks.
572 The following variables are available while preparing a backend request
574 (either for a cache miss or for pass or pipe mode):
575 bereq.request
577 The request type (e.g. "GET", "HEAD").
578 bereq.url
580 The requested URL.
581 bereq.proto
583 The HTTP protocol version used to talk to the server.
584 bereq.http.header
586 The corresponding HTTP header.
587 bereq.connect_timeout
589 The time in seconds to wait for a backend connection.
590 bereq.first_byte_timeout
592 The time in seconds to wait for the first byte from the backend.
593 Not available in pipe mode.
594 bereq.between_bytes_timeout
596 The time in seconds to wait between each received byte from the
597 backend. Not available in pipe mode.
598 The following variables are available after the requested object has
600 been retrieved from the backend, before it is entered into the cache.
601 In other words, they are available in vcl_fetch:
602 beresp.proto
604 The HTTP protocol version used when the object was retrieved.
605 beresp.status
607 The HTTP status code returned by the server.
608 beresp.response
610 The HTTP status message returned by the server.
611 beresp.cacheable
613 True if the request resulted in a cacheable response. A response
614 is considered cacheable if HTTP status code is 200, 203, 300,
615 301, 302, 404 or 410 and pass wasn't called in vcl_recv. If how‐
616 ever, both the TTL and the grace time for the response are 0
617 beresp.cacheable will be 0.
618 beresp.cacheable is writable.
620 beresp.ttl
622 The object's remaining time to live, in seconds. beresp.ttl is
623 writable.
624 After the object is entered into the cache, the following (mostly
626 read-only) variables are available when the object has been located in
627 cache, typically in vcl_hit and vcl_deliver.
628 obj.proto
630 The HTTP protocol version used when the object was retrieved.
631 obj.status
633 The HTTP status code returned by the server.
634 obj.response
636 The HTTP status message returned by the server.
637 obj.cacheable
639 True if the object had beresp.cacheable. Unless you've forced
640 delivery in your VCL obj.cacheable will always be true.
641 obj.ttl
643 The object's remaining time to live, in seconds. obj.ttl is
644 writable.
645 obj.lastuse
647 The approximate time elapsed since the object was last requests,
648 in seconds.
649 obj.hits
651 The approximate number of times the object has been delivered. A
652 value of 0 indicates a cache miss.
653 The following variables are available while determining the hash key of
655 an object:
656 req.hash
658 The hash key used to refer to an object in the cache. Used when
659 both reading from and writing to the cache.
660 The following variables are available while preparing a response to the
662 client:
663 resp.proto
665 The HTTP protocol version to use for the response.
666 resp.status
668 The HTTP status code that will be returned.
669 resp.response
671 The HTTP status message that will be returned.
672 resp.http.header
674 The corresponding HTTP header.
675 Values may be assigned to variables using the set keyword::
677 sub vcl_recv {
679 # Normalize the Host: header
680 if (req.http.host ~ "^(www.)?example.com$") {
681 set req.http.host = "www.example.com";
682 }
683 }
684 HTTP headers can be removed entirely using the remove keyword::
686 sub vcl_fetch {
688 # Don't cache cookies
689 remove beresp.http.Set-Cookie;
690 }
691 Grace and saint mode
693 If the backend takes a long time to generate an object there is a risk
694 of a thread pile up. In order to prevent this you can enable grace.
695 This allows varnish to serve an expired version of the object while a
696 fresh object is being generated by the backend.
697 The following vcl code will make Varnish serve expired objects. All
699 object will be kept up to two minutes past their expiration time or a
700 fresh object is generated.:
701 sub vcl_recv {
703 set req.grace = 2m;
704 }
705 sub vcl_fetch {
706 set beresp.grace = 2m;
707 }
708 Saint mode is similar to grace mode and relies on the same infrastruc‐
710 ture but functions differently. You can add VCL code to vcl_fetch to
711 see whether or not you like the response coming from the backend. If
712 you find that the response is not appropriate you can set beresp.saint‐
713 mode to a time limit and call restart. Varnish will then retry other
714 backends to try to fetch the object again.
715 If there are no more backends or if you hit max_restarts and we have an
717 object that is younger than what you set beresp.saintmode to be Varnish
718 will serve the object, even if it is stale.
719
721 The following code is the equivalent of the default configuration with
722 the backend address set to "backend.example.com" and no backend port
723 specified::
724 backend default {
726 .host = "backend.example.com";
727 .port = "http";
728 }
729 /*-
731 * Copyright (c) 2006 Verdens Gang AS
732 * Copyright (c) 2006-2009 Linpro AS
733 * All rights reserved.
734 *
735 * Author: Poul-Henning Kamp <phk@phk.freebsd.dk>
736 *
737 * Redistribution and use in source and binary forms, with or without
738 * modification, are permitted provided that the following conditions
739 * are met:
740 * 1. Redistributions of source code must retain the above copyright
741 * notice, this list of conditions and the following disclaimer.
742 * 2. Redistributions in binary form must reproduce the above copyright
743 * notice, this list of conditions and the following disclaimer in the
744 * documentation and/or other materials provided with the distribution.
745 *
746 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
747 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
748 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
749 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE
750 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
751 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
752 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
753 * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
754 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
755 * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
756 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
757 *
758 * $Id$
759 *
760 * The default VCL code.
761 *
762 * NB! You do NOT need to copy & paste all of these functions into your
763 * own vcl code, if you do not provide a definition of one of these
764 * functions, the compiler will automatically fall back to the default
765 * code from this file.
766 *
767 * This code will be prefixed with a backend declaration built from the
768 * -b argument.
769 */
770 sub vcl_recv {
772 if (req.restarts == 0) {
773 if (req.http.x-forwarded-for) {
774 set req.http.X-Forwarded-For =
775 req.http.X-Forwarded-For ", " client.ip;
776 } else {
777 set req.http.X-Forwarded-For = client.ip;
778 }
779 }
780 if (req.request != "GET" &&
781 req.request != "HEAD" &&
782 req.request != "PUT" &&
783 req.request != "POST" &&
784 req.request != "TRACE" &&
785 req.request != "OPTIONS" &&
786 req.request != "DELETE") {
787 /* Non-RFC2616 or CONNECT which is weird. */
788 return (pipe);
789 }
790 if (req.request != "GET" && req.request != "HEAD") {
791 /* We only deal with GET and HEAD by default */
792 return (pass);
793 }
794 if (req.http.Authorization || req.http.Cookie) {
795 /* Not cacheable by default */
796 return (pass);
797 }
798 return (lookup);
799 }
800 sub vcl_pipe {
802 # Note that only the first request to the backend will have
803 # X-Forwarded-For set. If you use X-Forwarded-For and want to
804 # have it set for all requests, make sure to have:
805 # set bereq.http.connection = "close";
806 # here. It is not set by default as it might break some broken web
807 # applications, like IIS with NTLM authentication.
808 return (pipe);
809 }
810 sub vcl_pass {
812 return (pass);
813 }
814 sub vcl_hash {
816 set req.hash += req.url;
817 if (req.http.host) {
818 set req.hash += req.http.host;
819 } else {
820 set req.hash += server.ip;
821 }
822 return (hash);
823 }
824 sub vcl_hit {
826 if (!obj.cacheable) {
827 return (pass);
828 }
829 return (deliver);
830 }
831 sub vcl_miss {
833 return (fetch);
834 }
835 sub vcl_fetch {
837 if (!beresp.cacheable) {
838 return (pass);
839 }
840 if (beresp.http.Set-Cookie) {
841 return (pass);
842 }
843 return (deliver);
844 }
845 sub vcl_deliver {
847 return (deliver);
848 }
849 sub vcl_error {
851 set obj.http.Content-Type = "text/html; charset=utf-8";
852 synthetic {"
853 <?xml version="1.0" encoding="utf-8"?>
854 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
855 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
856 <html>
857 <head>
858 <title>"} obj.status " " obj.response {"</title>
859 </head>
860 <body>
861 <h1>Error "} obj.status " " obj.response {"</h1>
862 <p>"} obj.response {"</p>
863 <h3>Guru Meditation:</h3>
864 <p>XID: "} req.xid {"</p>
865 <hr>
866 <p>Varnish cache server</p>
867 </body>
868 </html>
869 "};
870 return (deliver);
871 }
872 The following example shows how to support multiple sites running on
875 separate backends in the same Varnish instance, by selecting backends
876 based on the request URL::
877 backend www {
879 .host = "www.example.com";
880 .port = "80";
881 }
882 backend images {
884 .host = "images.example.com";
885 .port = "80";
886 }
887 sub vcl_recv {
889 if (req.http.host ~ "^(www.)?example.com$") {
890 set req.http.host = "www.example.com";
891 set req.backend = www;
892 } elsif (req.http.host ~ "^images.example.com$") {
893 set req.backend = images;
894 } else {
895 error 404 "Unknown virtual host";
896 }
897 }
898 The following snippet demonstrates how to force a minimum TTL for
900 all documents. Note that this is not the same as setting the
901 default_ttl run-time parameter, as that only affects document for
902 which the backend did not specify a TTL:::
903 sub vcl_fetch {
905 if (beresp.ttl < 120s) {
906 log "Adjusting TTL";
907 set beresp.ttl = 120s;
908 }
909 }
910 The following snippet demonstrates how to force Varnish to cache docu‐
912 ments even when cookies are present::
913 sub vcl_recv {
915 if (req.request == "GET" && req.http.cookie) {
916 return(lookup);
917 }
918 }
919 sub vcl_fetch {
921 if (beresp.http.Set-Cookie) {
922 return(deliver);
923 }
924 }
925 The following code implements the HTTP PURGE method as used by Squid
927 for object invalidation::
928 acl purge {
930 "localhost";
931 "192.0.2.1"/24;
932 }
933 sub vcl_recv {
935 if (req.request == "PURGE") {
936 if (!client.ip ~ purge) {
937 error 405 "Not allowed.";
938 }
939 return(lookup);
940 }
941 }
942 sub vcl_hit {
944 if (req.request == "PURGE") {
945 set obj.ttl = 0s;
946 error 200 "Purged.";
947 }
948 }
949 sub vcl_miss {
951 if (req.request == "PURGE") {
952 error 404 "Not in cache.";
953 }
954 }
955
957 · varnishd(1)
958
960 The VCL language was developed by Poul-Henning Kamp in cooperation with
961 Verdens Gang AS, Linpro AS and Varnish Software. This manual page was
962 written by Dag-Erling Smørgrav and later edited by Poul-Henning Kamp
963 and Per Buer.
964
966 This document is licensed under the same licence as Varnish itself. See
967 LICENCE for details.
968 · Copyright (c) 2006 Verdens Gang AS
970 · Copyright (c) 2006-2008 Linpro AS
972 · Copyright (c) 2008-2010 Redpill Linpro AS
974 · Copyright (c) 2010 Varnish Software AS
976
978 Dag-Erling Smørgrav, Poul-Henning Kamp, Kristian Lyngstøl, Per Buer
9791.0 2010-06-02 VCL(7)