Fastly makes use of a variety of variables.
The variables are mostly the http requests and responses that take place between the user and Fastly, as well as between Fastly and the origin.
Variables can be used in conditions, and they also can often be set, modified or deleted.
In addition to the standard variables listed below, Fastly enhanced the list with geo variables like geoip.country_code
, cryptographic capabilities and a lot more.
Feature Set | Documentation |
GeoIP-related VCL features | http://docs.fastly.com/guides/vcl-extensions/geoiprelated-vcl-features |
Cryptographic- and hashing-related VCL functions | http://docs.fastly.com/guides/vcl-extensions/cryptographic-and-hashingrelated-vcl-functions |
Date- and time-related VCL features | http://docs.fastly.com/guides/vcl-extensions/date-and-timerelated-vcl-features |
Randomness-related VCL features | http://docs.fastly.com/guides/vcl-extensions/randomnessrelated-vcl-features |
Size-related VCL variables | http://docs.fastly.com/guides/vcl-extensions/sizerelated-vcl-variables |
Miscellaneous VCL features | http://docs.fastly.com/guides/vcl-extensions/miscellaneous-VCL-extensions |
Standard Varnish Variables - also see list below | https://www.varnish-cache.org/docs/2.1/reference/vcl.html#variables |
Standard VCL feaures
The following variables are always available:
now | The current time, in seconds since the epoch. |
The following variables are available in backend declarations:
.host | Host name or IP address of a backend. |
.port | Service name or port number of a backend. |
The following variables are available while processing a request:
client.ip | The client’s IP address. |
server.hostname | The host name of the server. |
server.identity | The identity of the server, as set by the -i parameter. If the -i parameter is not passed to varnishd, server.identity will be set to the name of the instance, as specified by the -n parameter. |
server.ip | The IP address of the socket on which the client connection was received. |
server.port | The port number of the socket on which the client connection was received |
req.request | The request type (e.g. “GET”, “HEAD”). |
req.url | The requested URL. |
req.proto | The HTTP protocol version used by the client. |
req.backend | The backend to use to service the request. |
req.backend.healthy | Whether the backend is healthy or not. Requires an active probe to be set on the backend. |
req.http.header | The corresponding HTTP header. |
req.hash_always_miss | Force a cache miss for this request. If set to true Varnish will disregard any existing objects and always (re)fetch from the backend. |
req.hash_ignore_busy | Ignore any busy object during cache lookup. You would want to do this if you have two server looking up content from each other to avoid potential deadlocks. |
The following variables are available while preparing a backend request (either for a cache miss or for pass or pipe mode):
bereq.request | The request type (e.g. “GET”, “HEAD”). |
bereq.url | The requested URL. |
bereq.proto | The HTTP protocol version used to talk to the server. |
bereq.http.header | The corresponding HTTP header. |
bereq.connect_timeout | The time in seconds to wait for a backend connection. |
bereq.first_byte_timeout | The time in seconds to wait for the first byte from the backend. Not available in pipe mode. |
bereq.between_bytes_timeout | The time in seconds to wait between each received byte from the backend. Not available in pipe mode. |
The following variables are available after the requested object has been retrieved from the backend, before it is entered into the cache. In other words, they are available in vcl_fetch:
beresp.proto | The HTTP protocol version used when the object was retrieved. |
beresp.status | The HTTP status code returned by the server. |
beresp.response | The HTTP status message returned by the server. |
beresp.cacheable | True if the request resulted in a cacheable response. A response is considered cacheable if HTTP status code is 200, 203, 300, 301, 302, 404 or 410 and pass wasn’t called in vcl_recv. If however, both the TTL and the grace time for the response are 0 beresp.cacheable will be 0. |
beresp.ttl | The object’s remaining time to live, in seconds. beresp.ttl is writable. |
After the object is entered into the cache, the following (mostly read-only) variables are available when the object has been located in cache, typically in vcl_hit and vcl_deliver.
obj.proto | The HTTP protocol version used when the object was retrieved. |
obj.status | The HTTP status code returned by the server. |
obj.response | The HTTP status message returned by the server. |
obj.cacheable | True if the object had beresp.cacheable. Unless you’ve forced delivery in your VCL obj.cacheable will always be true. |
obj.ttl | The object’s remaining time to live, in seconds. obj.ttl is writable. |
obj.lastuse | The approximate time elapsed since the object was last requests, in seconds. |
obj.hits | The approximate number of times the object has been delivered. A value of 0 indicates a cache miss. |
The following variables are available while determining the hash key of an object:
req.hash | The hash key used to refer to an object in the cache. Used when both reading from and writing to the cache. |
The following variables are available while preparing a response to the client:
resp.proto | The HTTP protocol version to use for the response. |
resp.status | The HTTP status code that will be returned. |
resp.response | The HTTP status message that will be returned. |
resp.http.header | The corresponding HTTP header. |
Comments
0 comments
Please sign in to leave a comment.