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
Limitations to avoid loops
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, which show real world use cases. Click RUN 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.
User contributed notes
We welcome comments that add use cases, ideas, tips, and caveats. All comments will be moderated before publication. To post support questions, visit our support center and we'll find you the help you need.