Edge processing phases model
This edge processing phases model defines a series of ordered phases that a request and response pass through at the Fastly edge. It provides a framework for understanding when different types of logic execute.
For example, this model can help explain why VCL headers added to a request during edge application request processing are visible to the Edge WAF but not the Adaptive Threat Engine.
Key principles
Edge processing phases adhere to the following key principles:
- Phases begin in a defined order. Each phase starts only after the previous phase has started.
- Phases may not end in the order they started. The flexible nature of edge processing means that later phases for one subrequest may complete before earlier phases for another subrequest. For example, a Compute program can initiate multiple backend requests, service chains, or shielded requests, each proceeding through later phases independently and completing at different times.
- Phases are skipped when not applicable. If a feature is not enabled or configured, the related phase is bypassed. For example, if your service does not use Image Optimizer, the image optimization phase is skipped.
- Some phases create additional requests. For example, in the edge application request processing phase, shielding, service chaining, and async origin fetch can generate new requests that pass through the edge processing phases model independently.
- Phases 1-5 only process external client requests. They do not process internal requests generated by shielding, service chaining, and async origin fetch.
Request processing phases
When a client sends a request to a Fastly service, it passes through the following phases in order:
| Order | Name | Description | |
|---|---|---|---|
| 1 | Client transport negotiation | Fastly negotiates transport protocol with the web client. This includes modern protocols such as HTTP/3 over QUIC (UDP), as well as TCP for traditional HTTP/2 and HTTP/1.1. This phase does not include transport negotiation for connections to origins. | |
| 2 | Client TLS handshake | Fastly handles the TLS handshake with external web clients, which can include mutual TLS (mTLS) authentication. Origin TLS handshakes are not a part of this phase and are instead performed in phase 8. | |
| 3 | Adaptive threat engine | DDoS Protection inspects requests for Distributed Denial of Service (DDoS) attacks. | |
| 4 | API discovery | API Discovery passively monitors HTTP traffic as it flows through Fastly's edge network and catalogs your API endpoints. | |
| 5 | Bot detection | Bot Management (pre-cache inspection deployment) detects and classifies bot traffic. This phase is distinct from the bot-related processing that may occur during phase 7. | |
| 6 | Edge application request processing | VCL and Compute programs execute in this phase, along with a wide range of supporting functionality:
The VCL request lifecycle maps primarily to this phase and phase 13. | |
| 7 | Edge WAF request inspection | The Next-Gen WAF (Edge WAF deployment) and Bot Management (post-cache inspection deployment) inspect requests. For Compute services, you can configure this phase to execute after phase 8. | |
| 8 | External origin fetch | Fastly sends requests to origin backends outside the current Fastly deployment configuration. This phase includes the origin TLS handshake if applicable. Requests to Fastly-managed origins outside the current deployment configuration (e.g., the On-The-Fly Packager) are modeled in this phase. However, requests to customer-managed origins within the current Fastly deployment configuration (e.g., shielding and service chaining) are handled in the edge application request processing phase. | |
| 9 | On-Prem WAF request inspection | The Next-Gen WAF (On-Prem WAF deployment) inspects requests at the customer origin. Other origin-side logic (such as web server request handling) may execute before this phase. The Next-Gen WAF agent executes at the discretion of that upstream logic. |
Response processing phases
When a response is received from the origin or generated at the edge, it passes through the following phases in order:
| Order | Name | Description | |
|---|---|---|---|
| 10 | On-Prem WAF response inspection | The Next-Gen WAF (On-Prem WAF deployment) inspects responses at the customer origin before the response is sent back to the Fastly edge. | |
| 11 | Image optimization | Fastly Image Optimizer processes media in responses. | |
| 12 | Edge WAF response inspection | The Next-Gen WAF (Edge WAF deployment) and Bot Management (post-cache inspection deployment) inspect responses. | |
| 13 | Edge application response processing | VCL (in vcl_deliver) and Compute programs process responses. This phase also includes static response compression for VCL services. For more information, check out VCL deliver subroutine, Getting started with Compute, and Static compression.The VCL request lifecycle maps primarily to this phase and phase 6. | |
| 14 | Dynamic response compression | Fastly dynamically compresses responses before delivering them to web clients. This dynamic compression relies on HTTP content negotiation headers and is applied immediately before the response leaves the Fastly platform. |
