Common use cases for restarting a request include:
- in case of an error response, to retry an origin server or switch to an alternative backend
- to allow a request to be 'annotated' with data from an API call (a pattern we call 'preflighting')
Upon restart, all backend response (
beresp), cache object (
obj) and client response (
resp) variables are discarded. The state of the client request (
req) is preserved, along with any modifications to it. If a
restart is performed in the
vcl_error subroutines, modifications made to
req may not survive a restart due to the effects of clustering.
After a restart, clustering is automatically disabled. To re-enable it, set the value of the HTTP header
Requests are limited to three restarts, to avoid infinite loops. The fourth restart will trigger a
503 Service Unavailable error.
As a result it's essential to execute the
restart statement conditionally.
Try it out
restart is used in the following solution recipes. Recipes apply VCL to real-world use cases and can be deployed as-is, or adapted for your own service. See the full list of recipesfor more inspiration.
Click RUN on a sample below to provision a Fastly service, execute the code on Fastly, and see how the function behaves.
Threat intelligence preflight
Detect requests that contain submitted passwords and use a service to determine whether the password has leaked before allowing the request to proceed to origin (data from haveibeenpwned).
Serve stale to search crawlers
Prioritize human traffic over search crawlers by serving stale content to crawlers.
Smoke test a new origin
Send a copy of your traffic to a test origin before returning a response from production.