# VCL-Variables

## The complete album

Manual section:

  7

### DESCRIPTION

This is a list of all variables in the VCL language.

Variable names take the form `scope.variable[.index]`, for instance:

    req.url
    beresp.http.date
    client.ip

Which operations are possible on each variable is described below, often with the shorthand “backend” which covers the `vcl_backend_* {}` subroutines and “client” which covers the rest, except `vcl_init {}` and `vcl_fini {}`.

#### local, server, remote and client

These variables describe the network connection between the client and varnishd.

Without PROXY protocol:

         client    server
         remote    local
           v          v
    CLIENT ------------ VARNISHD

With PROXY protocol:

         client    server   remote     local
           v          v       v          v
    CLIENT ------------ PROXY ------------ VARNISHD

client.identity

> Type: STRING

> Readable from: client, backend

> Writable from: client

> Identification of the client, used to load balance in the client director. Defaults to `client.ip`

> This variable can be overwritten with more precise information, for instance extracted from a `Cookie:` header.

client.ip

> Type: IP

> Readable from: client, backend

> The client’s IP address, either the same as `remote.ip` or what the PROXY protocol told us.

server.hostname

> Type: STRING

> Readable from: all

> The host name of the server, as returned by the gethostname(3) system function.

server.identity

> Type: STRING

> Readable from: all

> The identity of the server, as set by the `-i` parameter.

> If an `-i` parameter is not passed to varnishd, the return value from gethostname(3) system function will be used.

server.ip

> Type: IP

> Readable from: client, backend

> The IP address of the socket on which the client connection was received, either the same as `local.ip` or what the PROXY protocol told us.

remote.ip

> Type: IP

> Readable from: client, backend

> The IP address of the other end of the TCP connection. This can either be the clients IP, or the outgoing IP of a proxy server.

> If the connection is a UNIX domain socket, the value will be `0.0.0.0:0`

local.endpoint `VCL >= 4.1`

> Type: STRING

> Readable from: client, backend

> The address of the ‘-a’ socket the session was accepted on.

> If the argument was `-a foo=:81` this would be “:81”

local.ip

> Type: IP

> Readable from: client, backend

> The IP address (and port number) of the local end of the TCP connection, for instance `192.168.1.1:81`

> If the connection is a UNIX domain socket, the value will be `0.0.0.0:0`

local.socket `VCL >= 4.1`

> Type: STRING

> Readable from: client, backend

> The name of the ‘-a’ socket the session was accepted on.

> If the argument was `-a foo=:81` this would be “foo”.

> Note that all ‘-a’ gets a default name on the form `a%d` if no name is provided.

#### req and req_top

These variables describe the present request, and when ESI:include requests are being processed, req_top points to the request received from the client.

req

> Type: HTTP

> Readable from: client

> The entire request HTTP data structure. Mostly useful for passing to VMODs.

req.backend_hint

> Type: BACKEND

> Readable from: client

> Writable from: client

> Set bereq.backend to this if we attempt to fetch. When set to a director, reading this variable returns an actual backend if the director has resolved immediately, or the director otherwise. When used in string context, returns the name of the director or backend, respectively.

req.can_gzip

> Type: BOOL

> Readable from: client

> True if the client provided `gzip` or `x-gzip` in the `Accept-Encoding` header.

req.esi `VCL <= 4.0`

> Type: BOOL

> Readable from: client

> Writable from: client

> Set to `false` to disable ESI processing regardless of any value in beresp.do_esi. Defaults to `true`. This variable is replaced by `resp.do_esi` in VCL 4.1.

req.esi_level

> Type: INT

> Readable from: client

> A count of how many levels of ESI requests we’re currently at.

req.filters

> Type: STRING

> Readable from: vcl_recv

> Writable from: vcl_recv

> List of Varnish Fetch Processor (VFP) filters the req.body will be pulled through. The order left to right signifies processing from client to cache, iow the leftmost filter is run first on the body as received from the client after decoding of any transfer encodings.

> VFP Filters change the body before potentially being cached (e.g. using `std.cache_req.body()`) and/or being handled by the backend side, where it may get processed again by bereq.filters.

> Trying to set req.filters after processing the request body (again, for example with `std.cache_req.body()`) triggers a VCL error.

req.grace

> Type: DURATION

> Readable from: client

> Writable from: client

> Unsettable from: client

> Upper limit on the object grace.

> During lookup the minimum of req.grace and the object’s stored grace value will be used as the object’s grace.

> When reading the unset value, it is returned as -1.

req.hash

> Type: BLOB

> Readable from: vcl_hit, vcl_miss, vcl_pass, vcl_purge, vcl_deliver, vcl_synth, vcl_pipe

> The hash key of this request. Mostly useful for passing to VMODs, but can also be useful for debugging hit/miss status.

req.hash_always_miss

> Type: BOOL

> Readable from: client

> Writable from: client

> Default: `false`.

> Force a cache miss for this request, even if perfectly good matching objects are in the cache.

> This is useful to force-update the cache without invalidating existing entries in case the fetch fails.

req.hash_ignore_busy

> Type: BOOL

> Readable from: client

> Writable from: client

> Default: `false`.

> Ignore any busy object during cache lookup.

> You only want to do this when you have two server looking up content sideways from each other to avoid deadlocks.

req.hash_ignore_vary

> Type: BOOL

> Readable from: client

> Writable from: client

> Default: `false`.

> Ignore objects vary headers during cache lookup.

> This returns the very first match regardless of the object compatibility with the client request. This is useful when variants are irrelevant to certain clients, and differences in the way the resource is presented don’t change how the client will interpret it.

> Use with caution.

req.http.*

> Type: HEADER

> Readable from: client

> Writable from: client

> Unsettable from: client

> The headers of request, things like `req.http.date`.

> The RFCs allow multiple headers with the same name, and both `set` and `unset` will remove all headers with the name given.

> The header name `*` is a VCL symbol and as such cannot, for example, start with a numeral. To work with valid header that can’t be represented as VCL symbols it is possible to quote the name, like `req.http."grammatically.valid"`. None of the HTTP headers present in IANA registries need to be quoted, so the quoted syntax is discouraged but available for interoperability.

> Some headers that cannot be tampered with for proper HTTP fetch or delivery are read-only.

req.http.content-length

> Type: HEADER

> Readable from: client

> The content-length header field is protected, see protected_headers.

req.http.transfer-encoding

> Type: HEADER

> Readable from: client

> The transfer-encoding header field is protected, see protected_headers.

req.is_hitmiss

> Type: BOOL

> Readable from: vcl_miss, vcl_deliver, vcl_pass, vcl_synth

> If this request resulted in a hitmiss

req.is_hitpass

> Type: BOOL

> Readable from: vcl_pass, vcl_deliver, vcl_synth

> If this request resulted in a hitpass

req.method

> Type: STRING

> Readable from: client

> Writable from: client

> The request method (e.g. “GET”, “HEAD”, …)

req.proto `VCL <= 4.0`

> Type: STRING

> Readable from: client

> Writable from: client

> The HTTP protocol version used by the client, usually “HTTP/1.1” or “HTTP/2.0”.

req.proto `VCL >= 4.1`

> Type: STRING

> Readable from: client

> The HTTP protocol version used by the client, usually “HTTP/1.1” or “HTTP/2.0”.

req.restarts

> Type: INT

> Readable from: client

> A count of how many times this request has been restarted.

req.storage

> Type: STEVEDORE

> Readable from: client

> Writable from: client

> The storage backend to use to save this request body.

req.time

> Type: TIME

> Readable from: client

> The time when the request was fully received, remains constant across restarts.

req.trace

> Type: BOOL

> Readable from: client

> Writable from: client

> Controls if `VCL_trace` VSL records are emitted for the current request, see VSL.

> Defaults to the setting of the `feature trace` parameter, see varnishd. Does not get reset by a rollback.

req.transport

> Type: STRING

> Readable from: client

> The transport protocol which brought this request.

req.ttl

> Type: DURATION

> Readable from: client

> Writable from: client

> Unsettable from: client

> Upper limit on the object age for cache lookups to return hit.

> When reading the unset value, it is returned as -1.

req.url

> Type: STRING

> Readable from: client

> Writable from: client

> The requested URL, for instance “/robots.txt”.

req.xid

> Type: INT

> Readable from: client

> Unique ID of this request.

req_top.http.*

> Type: HEADER

> Readable from: client

> HTTP headers of the top-level request in a tree of ESI requests. Identical to req.http. in non-ESI requests.

> See req.http for general notes.

req_top.method

> Type: STRING

> Readable from: client

> The request method of the top-level request in a tree of ESI requests. (e.g. “GET”, “HEAD”). Identical to req.method in non-ESI requests.

req_top.proto

> Type: STRING

> Readable from: client

> HTTP protocol version of the top-level request in a tree of ESI requests. Identical to req.proto in non-ESI requests.

req_top.time

> Type: TIME

> Readable from: client

> The time when the top-level request was fully received, remains constant across restarts.

req_top.url

> Type: STRING

> Readable from: client

> The requested URL of the top-level request in a tree of ESI requests. Identical to req.url in non-ESI requests.

#### bereq

This is the request we send to the backend, it is built from the clients `req.*` fields by filtering out “per-hop” fields which should not be passed along (`Connection:`, `Range:` and similar).

Slightly more fields are allowed through for `pass` fetches than for `miss` fetches, for instance ``Range`.

bereq

> Type: HTTP

> Readable from: backend

> The entire backend request HTTP data structure. Mostly useful as argument to VMODs.

bereq.backend

> Type: BACKEND

> Readable from: vcl_pipe, backend

> Writable from: vcl_pipe, backend

> This is the backend or director we attempt to fetch from. When set to a director, reading this variable returns an actual backend if the director has resolved immediately, or the director otherwise. When used in string context, returns the name of the director or backend, respectively.

bereq.between_bytes_timeout

> Type: DURATION

> Readable from: backend

> Writable from: backend

> Unsettable from: vcl_pipe, backend

> Default: `.between_bytes_timeout` attribute from the Backend definition, which defaults to the `between_bytes_timeout` parameter, see varnishd.

> The time in seconds to wait between each received byte from the backend. Not available in pipe mode.

bereq.body

> Type: BODY

> Unsettable from: vcl_backend_fetch

> The request body.

> Unset will also remove bereq.http.content-length.

bereq.connect_timeout

> Type: DURATION

> Readable from: vcl_pipe, backend

> Writable from: vcl_pipe, backend

> Unsettable from: vcl_pipe, backend

> Default: `.connect_timeout` attribute from the Backend definition, which defaults to the `connect_timeout` parameter, see varnishd.

> The time in seconds to wait for a backend connection to be established.

bereq.filters

> Type: STRING

> Readable from: vcl_backend_fetch

> Writable from: vcl_backend_fetch

> List of VDP filters the bereq.body will be pushed through when sending the body to the backend.

bereq.first_byte_timeout

> Type: DURATION

> Readable from: backend

> Writable from: backend

> Unsettable from: vcl_pipe, backend

> Default: `.first_byte_timeout` attribute from the Backend definition, which defaults to the `first_byte_timeout` parameter, see varnishd.

> The time in seconds to wait getting the first byte back from the backend. Not available in pipe mode.

bereq.hash

> Type: BLOB

> Readable from: vcl_pipe, backend

> The hash key of this request, a copy of `req.hash`.

bereq.http.*

> Type: HEADER

> Readable from: vcl_pipe, backend

> Writable from: vcl_pipe, backend

> Unsettable from: vcl_pipe, backend

> The headers to be sent to the backend.

> See req.http for general notes.

bereq.http.content-length

> Type: HEADER

> Readable from: backend

> The content-length header field is protected, see protected_headers.

bereq.http.transfer-encoding

> Type: HEADER

> Readable from: backend

> The transfer-encoding header field is protected, see protected_headers.

bereq.is_bgfetch

> Type: BOOL

> Readable from: backend

> True for fetches where the client got a hit on an object in grace, and this fetch was kicked of in the background to get a fresh copy.

bereq.is_hitmiss

> Type: BOOL

> Readable from: backend

> If this backend request was caused by a hitmiss.

bereq.is_hitpass

> Type: BOOL

> Readable from: backend

> If this backend request was caused by a hitpass.

bereq.method

> Type: STRING

> Readable from: vcl_pipe, backend

> Writable from: vcl_pipe, backend

> The request type (e.g. “GET”, “HEAD”).

> Regular (non-pipe, non-pass) fetches are always “GET”

bereq.proto `VCL <= 4.0`

> Type: STRING

> Readable from: vcl_pipe, backend

> Writable from: vcl_pipe, backend

> The HTTP protocol version, “HTTP/1.1” unless a pass or pipe request has “HTTP/1.0” in `req.proto`

bereq.proto `VCL >= 4.1`

> Type: STRING

> Readable from: vcl_pipe, backend

> The HTTP protocol version, “HTTP/1.1” unless a pass or pipe request has “HTTP/1.0” in `req.proto`

bereq.retries

> Type: INT

> Readable from: backend

> A count of how many times this request has been retried.

bereq.task_deadline

> Type: DURATION

> Readable from: vcl_pipe

> Writable from: vcl_pipe

> Unsettable from: vcl_pipe

> Deadline for pipe sessions, defaults `0s`, which falls back to the `pipe_task_deadline` parameter, see varnishd

bereq.time

> Type: TIME

> Readable from: vcl_pipe, backend

> The time when we started preparing the first backend request, remains constant across retries.

bereq.trace

> Type: BOOL

> Readable from: backend

> Writable from: backend

> Controls if `VCL_trace` VSL records are emitted for the current request, see VSL.

> Inherits the value of `req.trace` when the backend request is created. Does not get reset by a rollback.

bereq.uncacheable

> Type: BOOL

> Readable from: backend

> Indicates whether this request is uncacheable due to a pass in the client side or a hit on an hit-for-pass object.

bereq.url

> Type: STRING

> Readable from: vcl_pipe, backend

> Writable from: vcl_pipe, backend

> The requested URL, copied from `req.url`

bereq.xid

> Type: INT

> Readable from: vcl_pipe, backend

> Unique ID of this request.

#### beresp

The response received from the backend, one cache misses, the store object is built from `beresp`.

beresp

> Type: HTTP

> Readable from: vcl_backend_response, vcl_backend_error

> The entire backend response HTTP data structure, useful as argument to VMOD functions.

beresp.age

> Type: DURATION

> Readable from: vcl_backend_response, vcl_backend_error

> Default: Age header, or zero.

> The age of the object.

beresp.backend

> Type: BACKEND

> Readable from: vcl_backend_response, vcl_backend_error

> This is the backend we fetched from. If bereq.backend was set to a director, this will be the backend selected by the director. When used in string context, returns its name.

beresp.backend.ip `VCL <= 4.0`

> Type: IP

> Readable from: vcl_backend_response

> IP of the backend this response was fetched from.

beresp.backend.name

> Type: STRING

> Readable from: vcl_backend_response, vcl_backend_error

> Name of the backend this response was fetched from. Same as beresp.backend.

beresp.body

> Type: BODY

> Writable from: vcl_backend_error

> For producing a synthetic body.

beresp.do_esi

> Type: BOOL

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> Default: `false`.

> Set it to true to parse the object for ESI directives. This is necessary for later ESI processing on the client side. If beresp.do_esi is false when an object enters the cache, client side ESI processing will not be possible (obj.can_esi will be false).

> It is a VCL error to use beresp.do_esi after setting beresp.filters.

beresp.do_gunzip

> Type: BOOL

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> Default: `false`.

> Set to `true` to gunzip the object while storing it in the cache.

> If `http_gzip_support` is disabled, setting this variable has no effect.

> It is a VCL error to use beresp.do_gunzip after setting beresp.filters.

beresp.do_gzip

> Type: BOOL

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> Default: `false`.

> Set to `true` to gzip the object while storing it.

> If `http_gzip_support` is disabled, setting this variable has no effect.

> It is a VCL error to use beresp.do_gzip after setting beresp.filters.

beresp.do_stream

> Type: BOOL

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> Default: `true`.

> Deliver the object to the client while fetching the whole object into varnish.

> For uncacheable objects, storage for parts of the body which have been sent to the client may get freed early, depending on the storage engine used.

> This variable has no effect if beresp.do_esi is true or when the response body is empty.

beresp.filters

> Type: STRING

> Readable from: vcl_backend_response

> Writable from: vcl_backend_response

> List of Varnish Fetch Processor (VFP) filters the beresp.body will be pulled through. The order left to right signifies processing from backend to cache, iow the leftmost filter is run first on the body as received from the backend after decoding of any transfer encodings.

> VFP Filters change the body before going into the cache and/or being handed to the client side, where it may get processed again by resp.filters.

> The following VFP filters exist in varnish-cache:

> - `gzip`: compress a body using gzip

> - `testgunzip`: Test if a body is valid gzip and refuse it otherwise

> - `gunzip`: Uncompress gzip content

> - `esi`: ESI-process plain text content

> - `esi_gzip`: Save gzipped snippets for efficient ESI-processing

>   This filter enables stitching together ESI from individually gzipped fragments, saving processing power for re-compression on the client side at the expense of some compression efficiency.

> Additional VFP filters are available from VMODs.

> By default, beresp.filters is constructed as follows:

> - `gunzip` gets added for gzipped content if `beresp.do_gunzip` or `beresp.do_esi` are true.

> - `esi_gzip` gets added if `beresp.do_esi` is true together with `beresp.do_gzip` or content is already compressed.

> - `esi` gets added if `beresp.do_esi` is true

> - `gzip` gets added for uncompressed content if `beresp.do_gzip` is true

> - `testgunzip` gets added for compressed content if `beresp.do_gunzip` is false.

> After beresp.filters is set, using any of the beforementioned `beresp.do_*` switches is a VCL error.

beresp.grace

> Type: DURATION

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> Default: Cache-Control `stale-while-revalidate` directive, or `default_grace` parameter.

> Set to a period to enable grace.

beresp.http.*

> Type: HEADER

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> Unsettable from: vcl_backend_response, vcl_backend_error

> The HTTP headers returned from the server.

> See req.http for general notes.

beresp.http.content-length

> Type: HEADER

> Readable from: vcl_backend_response, vcl_backend_error

> The content-length header field is protected, see protected_headers.

beresp.http.transfer-encoding

> Type: HEADER

> Readable from: vcl_backend_response, vcl_backend_error

> The transfer-encoding header field is protected, see protected_headers.

beresp.keep

> Type: DURATION

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> Default: `default_keep` parameter.

> Set to a period to enable conditional backend requests.

> The keep time is cache lifetime in addition to the ttl.

> Objects with ttl expired but with keep time left may be used to issue conditional (If-Modified-Since / If-None-Match) requests to the backend to refresh them.

beresp.proto `VCL <= 4.0`

> Type: STRING

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> The HTTP protocol version the backend replied with.

beresp.proto `VCL >= 4.1`

> Type: STRING

> Readable from: vcl_backend_response, vcl_backend_error

> The HTTP protocol version the backend replied with.

beresp.reason

> Type: STRING

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> The HTTP status message returned by the server.

beresp.status

> Type: INT

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> The HTTP status code returned by the server.

> More information in the HTTP response status section.

beresp.storage

> Type: STEVEDORE

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> The storage backend to use to save this object. If none is set, Varnish will pick a storage backend in a round-robin fashion, or the Transient backend if the object is short-lived.

beresp.storage_hint `VCL <= 4.0`

> Type: STRING

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> Deprecated since varnish 5.1 and discontinued since VCL 4.1 (varnish 6.0). Use beresp.storage instead.

> Hint to Varnish that you want to save this object to a particular storage backend.

beresp.time

> Type: TIME

> Readable from: vcl_backend_response, vcl_backend_error

> When the backend headers were fully received just before `vcl_backend_response {}` was entered, or when `vcl_backend_error {}` was entered.

beresp.transit_buffer

> Type: BYTES

> Readable from: vcl_backend_response

> Writable from: vcl_backend_response

> Default: `transit_buffer` parameter, see varnishd.

> The maximum number of bytes the client can be ahead of the backend during a streaming pass if `beresp` is uncacheable. See also `transit_buffer` parameter documentation in varnishd.

beresp.ttl

> Type: DURATION

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> Default: Cache-Control `s-maxage` or `max-age` directives, or a value computed from the Expires header’s deadline, or the `default_ttl` parameter.

> The object’s remaining time to live, in seconds.

beresp.uncacheable

> Type: BOOL

> Readable from: vcl_backend_response, vcl_backend_error

> Writable from: vcl_backend_response, vcl_backend_error

> Inherited from bereq.uncacheable, see there.

> Setting this variable makes the object uncacheable.

> This may produce a hit-for-miss object in the cache.

> Clearing the variable has no effect and will log the warning “Ignoring attempt to reset beresp.uncacheable”.

beresp.was_304

> Type: BOOL

> Readable from: vcl_backend_response, vcl_backend_error

> When `true` this indicates that we got a 304 response to our conditional fetch from the backend and turned that into `beresp.status = 200`

#### obj

This is the object we found in cache. It cannot be modified.

obj.age

> Type: DURATION

> Readable from: vcl_hit, vcl_deliver

> The age of the object.

obj.can_esi

> Type: BOOL

> Readable from: vcl_hit, vcl_deliver

> If the object can be ESI processed, that is if setting `resp.do_esi` or adding `esi` to `resp.filters` in `vcl_deliver {}` would cause the response body to be ESI processed.

obj.grace

> Type: DURATION

> Readable from: vcl_hit, vcl_deliver

> The object’s grace period in seconds.

obj.hits

> Type: INT

> Readable from: vcl_hit, vcl_deliver

> The count of cache-hits on this object.

> In vcl_deliver a value of 0 indicates a cache miss.

obj.http.*

> Type: HEADER

> Readable from: vcl_hit

> The HTTP headers stored in the object.

> See req.http for general notes.

obj.keep

> Type: DURATION

> Readable from: vcl_hit, vcl_deliver

> The object’s keep period in seconds.

obj.proto

> Type: STRING

> Readable from: vcl_hit

> The HTTP protocol version stored in the object.

obj.reason

> Type: STRING

> Readable from: vcl_hit

> The HTTP reason phrase stored in the object.

obj.status

> Type: INT

> Readable from: vcl_hit

> The HTTP status code stored in the object.

> More information in the HTTP response status section.

obj.storage

> Type: STEVEDORE

> Readable from: vcl_hit, vcl_deliver

> The storage backend where this object is stored.

obj.time

> Type: TIME

> Readable from: vcl_hit, vcl_deliver

> The time the object was created from the perspective of the server which generated it. This will roughly be equivalent to `now` - `obj.age`.

obj.ttl

> Type: DURATION

> Readable from: vcl_hit, vcl_deliver

> The object’s remaining time to live, in seconds.

obj.uncacheable

> Type: BOOL

> Readable from: vcl_deliver

> Whether the object is uncacheable (pass, hit-for-pass or hit-for-miss).

#### resp

This is the response we send to the client, it is built from either `beresp` (pass/miss), `obj` (hits) or created from whole cloth (synth).

With the exception of `resp.body` all `resp.*` variables available in both `vcl_deliver{}` and `vcl_synth{}` as a matter of symmetry.

resp

> Type: HTTP

> Readable from: vcl_deliver, vcl_synth

> The entire response HTTP data structure, useful as argument to VMODs.

resp.body

> Type: BODY

> Writable from: vcl_synth

> To produce a synthetic response body, for instance for errors.

resp.do_esi `VCL >= 4.1`

> Type: BOOL

> Readable from: vcl_deliver, vcl_synth

> Writable from: vcl_deliver, vcl_synth

> Default: obj.can_esi

> This can be used to selectively disable ESI processing, even though ESI parsing happened during fetch (see beresp.do_esi). This is useful when Varnish caches peer with each other.

> It is a VCL error to use resp.do_esi after setting resp.filters.

resp.filters

> Type: STRING

> Readable from: vcl_deliver, vcl_synth

> Writable from: vcl_deliver, vcl_synth

> List of VDP filters the resp.body will be pushed through.

> Before resp.filters is set, the value read will be the default filter list as determined by varnish based on resp.do_esi and request headers.

> After resp.filters is set, changing any of the conditions which otherwise determine the filter selection will have no effect. Using resp.do_esi is an error once resp.filters is set.

resp.http.*

> Type: HEADER

> Readable from: vcl_deliver, vcl_synth

> Writable from: vcl_deliver, vcl_synth

> Unsettable from: vcl_deliver, vcl_synth

> The HTTP headers that will be returned.

> See req.http for general notes.

resp.http.content-length

> Type: HEADER

> Readable from: vcl_deliver, vcl_synth

> The content-length header field is protected, see protected_headers.

resp.http.transfer-encoding

> Type: HEADER

> Readable from: vcl_deliver, vcl_synth

> The transfer-encoding header field is protected, see protected_headers.

resp.is_streaming

> Type: BOOL

> Readable from: vcl_deliver, vcl_synth

> Returns true when the response will be streamed while being fetched from the backend.

resp.proto `VCL <= 4.0`

> Type: STRING

> Readable from: vcl_deliver, vcl_synth

> Writable from: vcl_deliver, vcl_synth

> The HTTP protocol version to use for the response.

resp.proto `VCL >= 4.1`

> Type: STRING

> Readable from: vcl_deliver, vcl_synth

> The HTTP protocol version to use for the response.

resp.reason

> Type: STRING

> Readable from: vcl_deliver, vcl_synth

> Writable from: vcl_deliver, vcl_synth

> The HTTP status message that will be returned.

resp.status

> Type: INT

> Readable from: vcl_deliver, vcl_synth

> Writable from: vcl_deliver, vcl_synth

> The HTTP status code that will be returned.

> More information in the HTTP response status section.

> resp.status 200 will get changed into 304 by core code after a return(deliver) from vcl_deliver for conditional requests to cached content if validation succeeds.

> For the validation, first `req.http.If-None-Match` is compared against `resp.http.Etag`. If they compare equal according to the rules for weak validation (see RFC7232), a 304 is sent.

> Secondly, `req.http.If-Modified-Since` is compared against `resp.http.Last-Modified` or, if it is unset or weak, against the point in time when the object was last modified based on the `Date` and `Age` headers received with the backend response which created the object. If the object has not been modified based on that comparison, a 304 is sent.

resp.time

> Type: TIME

> Readable from: vcl_deliver, vcl_synth

> The time when we started preparing the response, just before entering `vcl_synth {}` or `vcl_deliver {}`.

#### Special variables

now

> Type: TIME

> Readable from: all

> The current time, in seconds since the UNIX epoch.

> When converted to STRING in expressions it returns a formatted timestamp like `Tue, 20 Feb 2018 09:30:31 GMT`

> `now` remains stable for the duration of any built-in VCL subroutine to make time-based calculations predictable and avoid edge cases.

> In other words, even if considerable amounts of time are spent in VCL, `now` will always represent the point in time when the respective built-in VCL subroutine was entered. `now` is thus not suitable for any kind of time measurements. See VOID timestamp(STRING s), TIME now() and DURATION timed_call(SUB) in VMOD std - Varnish Standard Module.

#### sess

A session corresponds to the “conversation” that Varnish has with a single client connection, over which one or more request/response transactions may take place. It may comprise the traffic over an HTTP/1 keep-alive connection, or the multiplexed traffic over an HTTP/2 connection.

sess.idle_send_timeout

> Type: DURATION

> Readable from: client

> Writable from: client

> Unsettable from: client

> Send timeout for individual pieces of data on client connections, defaults to the `idle_send_timeout` parameter, see varnishd

sess.send_timeout

> Type: DURATION

> Readable from: client

> Writable from: client

> Unsettable from: client

> Total timeout for ordinary HTTP1 responses, defaults to the `send_timeout` parameter, see varnishd

sess.timeout_idle

> Type: DURATION

> Readable from: client

> Writable from: client

> Unsettable from: client

> Idle timeout for this session, defaults to the `timeout_idle` parameter, see varnishd

sess.timeout_linger

> Type: DURATION

> Readable from: client

> Writable from: client

> Unsettable from: client

> Linger timeout for this session, defaults to the `timeout_linger` parameter, see varnishd

sess.xid `VCL >= 4.1`

> Type: INT

> Readable from: client, backend

> Unique ID of this session.

#### storage

storage.<name>.free_space

> Type: BYTES

> Readable from: client, backend

> Default: 0

> Free space available in the named stevedore. Only available for the malloc stevedore.

storage.<name>.happy

> Type: BOOL

> Readable from: client, backend

> Default: true

> Health status for the named stevedore. Not available in any of the current stevedores.

storage.<name>.used_space

> Type: BYTES

> Readable from: client, backend

> Default: 0

> Used space in the named stevedore. Only available for the malloc stevedore.

#### Protected header fields

The `content-length` and `transfer-encoding` headers are read-only. They must be preserved to ensure HTTP/1 framing remains consistent and maintain a proper request and response synchronization with both clients and backends.

VMODs can still update these headers, when there is a reason to change the framing, such as a transformation of a request or response body.

#### HTTP response status

A HTTP status code has 3 digits XYZ where X must be between 1 and 5 included. Since it is not uncommon to see HTTP clients or servers relying on non-standard or even invalid status codes, Varnish can work with any status between 100 and 999.

Within VCL code it is even possible to use status codes in the form VWXYZ as long as the overall value is lower than 65536, but only the XYZ part will be sent to the client, by which time the X must also have become non-zero.

The VWXYZ form of status codes can be communicate extra information in `resp.status` and `beresp.status` to `return(synth(...))` and `return(error(...))`, to indicate which synthetic content to produce:

    sub vcl_recv {
        if ([...]) {
            return synth(12404);
        }
    }

    sub vcl_synth {
        if (resp.status == 12404) {
            [...]       // this specific 404
        } else if (resp.status % 1000 == 404) {
            [...]       // all other 404's
        }
    }

The `obj.status` variable will inherit the VWXYZ form, but in a ban expression only the XYZ part will be available. The VWXYZ form is strictly limited to VCL execution.

Assigning an HTTP standardized code to `resp.status` or `beresp.status` will also set `resp.reason` or `beresp.reason` to the corresponding status message.

##### 304 handling

For a 304 response, Varnish core code amends `beresp` before calling vcl_backend_response:

- If the gzip status changed, `Content-Encoding` is unset and any `Etag` is weakened

- Any headers not present in the 304 response are copied from the existing cache object. `Content-Length` is copied if present in the existing cache object and discarded otherwise.

- The status gets set to 200.

beresp.was_304 marks that this conditional response processing has happened.

Note: Backend conditional requests are independent of client conditional requests, so clients may receive 304 responses no matter if a backend request was conditional.

##### beresp.ttl / beresp.grace / beresp.keep

Before calling vcl_backend_response, core code sets `beresp.ttl` based on the response status and the response headers `Age`, `Cache-Control` or `Expires` and `Date` as follows:

- If present and valid, the value of the `Age` header is effectively deduced from all ttl calculations.

- For status codes 200, 203, 204, 300, 301, 304, 404, 410 and 414:

  - If `Cache-Control` contains an `s-maxage` or `max-age` field (in that order of preference), the ttl is set to the respective non-negative value or 0 if negative.

  - Otherwise, if no `Expires` header exists, the default ttl is used.

  - Otherwise, if `Expires` contains a time stamp before `Date`, the ttl is set to 0.

  - Otherwise, if no `Date` header is present or the `Date` header timestamp differs from the local clock by no more than the clock_skew parameter, the ttl is set to

    - 0 if `Expires` denotes a past timestamp or

    - the difference between the local clock and the `Expires` header otherwise.

  - Otherwise, the ttl is set to the difference between `Expires` and `Date`

- For status codes 302 and 307, the calculation is identical except that the default ttl is not used and -1 is returned if neither `Cache-Control` nor `Expires` exists.

- For all other status codes, ttl -1 is returned.

`beresp.grace` defaults to the default_grace parameter.

For a non-negative ttl, if `Cache-Control` contains a `stale-while-revalidate` field value, `beresp.grace` is set to that value if non-negative or 0 otherwise.

`beresp.keep` defaults to the default_keep parameter.

### SEE ALSO

- varnishd

- VCL

### HISTORY

VCL was developed by Poul-Henning Kamp in cooperation with Verdens Gang AS, Redpill Linpro and Varnish Software. This manual page is written by Per Buer, Poul-Henning Kamp, Martin Blix Grydeland, Kristian Lyngstøl, Lasse Karstensen and others.

### COPYRIGHT

This document is licensed under the same license as Varnish itself. See LICENSE for details.

- Copyright (c) 2006 Verdens Gang AS

- Copyright (c) 2006-2021 Varnish Software AS