esi;
Available inall subroutines.
Flags a request for parsing Edge Side Includes. Parsing occurs after the vcl_deliver subroutine has finished, and while this statement is available in all subroutines, it is only effective if executed in vcl_fetch.
Fastly only supports the following ESI directives:
When specifying the src URL with <esi:include src=... />, the URL can be either an absolute or relative URL. If you specify an absolute URL, you must prefix it with http:// or https://.
<esi:include src="https://example.com/index.html" />
ESI requests are made to your Fastly service as new client requests, with a copy of the HTTP header information from the original client request. If a hostname is specified in the ESI src attribute, the Host header of the new request will be set to the value of that hostname, otherwise the Host header of the ESI request will be the same as for the parent request.
In the above example, the ESI parser takes example.com in the URL as the Host request header value (i.e., req.http.host) and creates a new request to your service. Although you can specify any URL in an ESI include, and the hostname does not have to be one of your service's configured domains you can only forward that request to one of your configured backends. In general, it is often better to use relative links for ESI includes to avoid confusion.
In ESI child requests, the req.topurl variable is set to the value of req.url from the parent request.
Consider only applying ESI to response types likely to contain ESI directives. For example, text/html is often used with ESI, but image/png is unlikely to have ESI directives.
In order for the ESI parser to detect <esi:... tags in the response stream, the response must not be compressed. Compressed responses will obfuscate the ESI tags and they will be delivered unprocessed to the client. This means that ESI cannot be performed on content compressed at origin, since it's not possible to decompress content in VCL services. However, it is usually possible to prevent origin servers from applying compression by removing the Accept-Encoding header from requests before forwarding them:
sub vcl_miss { ... }
Fastly VCL
unset bereq.http.accept-encoding;
If content is received from origin uncompressed but statically compressed at the edge using beresp.gzip or beresp.brotli, ESI will also fail, since the ESI processing occurs after the vcl_deliver stage. However, dynamic compression, which occurs at the moment of delivery, allows for compression of responses after ESI processing has occurred. Learn more about compression options.
Be aware of the following limitations when using ESI:
req.topurl.esi.allow_inside_cdata variable to true if needed.We also impose limits on the number of ESI directives that can be processed on each request:
esi:include processing is 5esi:include processing fragments is 256esi is used in the following code examples. Examples apply VCL to real-world use cases and can be deployed as they are, or adapted for your own service. See the full list of code examples for more inspiration.
Click RUN on a sample below to provision a Fastly service, execute the code on Fastly, and see how the function behaves.
Convert timestamps to relative times like '2 hours ago'Generate relative time datelines at the Edge instead of in the browser or at origin. Better caching, faster rendering, fewer reflows.
Assemble content at the edge with Edge-side includes (ESI)Use Fastly's support for ESI to combine multiple origin-hosted objects into a single response at the edge.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4