Overview and basic concepts
- CDN (Content Delivery Network) is a geographically distributed network that helps you deliver your application content fast and secure to the end-users across the globe.
- By distributing and caching content across 310+ globally dispersed Points of Presence (PoPs - also called edge locations) you can significantly decrease the latency of data delivery as well as reduce load on your application.
- CDN helps you improve security with automatic TLS and defends your application against DDoS attacks at no additional costs.
CDN explained
CDN can be seen as a layer between your application(origin) and clients connecting to the application.
- Instead of clients sending request directly to your application (origin - bucket, http-api-gateway or application-load-balancers), they send request to CDN.
- CDN delivers the request from the client to the closest CDN PoP (Point of Presence) edge location.
- CDN PoP gets a response from your application (origin).
- CDN PoP sends the response to the client. At the same time it caches the response.
- On subsequent requests from clients, CDN PoP can respond immediately using the cached response (cache hit).
- You can control which responses should be cached and for how long. Read section Caching configuration for more information.
Basic usage
In Stacktape, you can use CDN by configuring it on the specified resource (bucket, http-api-gateway or application-load-balancers). This resource then becomes the main origin for the CDN, which means that the requests sent to the CDN will be forwarded to this resource.
Copy
resources:myBucket:type: bucketproperties:cdn:enabled: true
You can also configure route rewrites to forward specified paths to other origins (other than the main origin). This enables you to have hybrid infrastructures where some requests are routed to bucket (to get the static content) and others are routed to http-api-gateway API (to get the dynamic content).
Enables the CDN
Type: boolean
Configures custom caching options
Type: CdnCachingOptions
- Configures the caching behavior of your edge distribution (what & when should stay in cache, and when to refetch it from the origin).
- When response from the origin does not contain neither
cache-control
norexpires
headers default caching behaviour is used. - Default caching behaviour depends on the type of origin the CDN is attached to:
- bucket - by default objects are cached for 6 months (or until the CDN cache is invalidated).
- http-api-gateway and application-load-balancer - by default responses are not cached.
Configures which parts of the request are forwarded to the origin (headers, query parameters, cookies etc.)
Type: CdnForwardingOptions
Enables you to redirect specific requests to a different origin
Type: Array of CdnRouteRewrite
- Each incoming request to the CDN is first evaluated against route rewrites. The requested path is compared with path pattern specified in route rewrite.
- If the requested path matches the path pattern specified by route rewrite, the request is sent to the configured route.
- Route rewrites are evaluated in order. The first match is where the request will be sent to.
- If no match is found, request is sent to the default origin (the one that the CDN is attached to).
Example use cases:
- Most of the content you are serving is a static content
served from a bucket (static website). Some content however needs to be
rendered dynamically by a lambda function. You can route paths that need
to be rendered dynamically to the lambda function through
http-api-gateway
. - You want to cache your
jpg
files longer than other files. You can create route rewrite that will catch every path ending withjpg
and set custom caching options for these paths.
Attaches a custom domains to this CDN
Type: Array of DomainConfiguration
Stacktape allows you to connect your custom domain names to some of your resources (HTTP API Gateways, Application Load Balancers and Buckets with CDNs).
Connecting a custom domain to the resource does 2 things:
- Creates DNS records:
- If you use your custom domain with a resource, Stacktape automatically creates a DNS record (during deploy) pointing the specified domain name to the resource.
- Adds TLS certificates
- If the origin resource (HTTP API Gateway, Application Load Balancer or CDN) uses HTTPS protocol, Stacktape takes care of issuing and attaching correct (free, AWS-managed) certificate to the resource. This means, you do not have to deal with TLS termination as it is handled by the connected resource.
- If you want to use your own certificates, you can configure
customCertificateArns
.
To manage a custom domain, it first needs to be added to your AWS account. This means that a hosted zone (collection of records managed together for a given domain) for your domain exists in your AWS account and your domain registrar's name servers are pointing to it. To learn more, refer to Adding a domain guide.
Configures CDN function triggers
Type: CdnFunctionsConfig
You can associate
cdn-lambda-function
with CDN to be executed:onRequest
- function is executed when CDN receives a request from a client(viewer) before checking CDN cacheonResponse
- function is executed before returning the response to the client(viewer)
Potential use-cases for using cdn functions:
- generating immediate HTTP response without the need to check CDN cache or forward to origin
- modifying request (i.e rewrite url, headers etc) before forwarding to the origin
- inspection of cookies
- inspection/validation of authorization headers and tokens
Configures locations from which the CDN serves traffic
Type: string ENUM
Possible values: PriceClass_100PriceClass_200PriceClass_All
- Higher price class results in more locations that serve your traffic.
- This can result in better performance in some regions, but is more costly.
- Example: If your users are located only in US & Europe, you can save money by configuring
PriceClass_100
- To learn more about price classes, refer to AWS docs
Prefixes requests to the origin with specified prefix
Type: string
- Incoming requests will be prefixed with
defaultRoutePrefix
before being forwarded to the origin. - Example: If the CDN receives a request with path
/my/resource/url
, the request will be sent to the origin as/default_route_prefix/my/resource/url
Custom error document URL
Type: string
- Error document is requested by the CDN if the original request to the origin responds with an error code
404
. - Example:
/error.html
Custom index (root) document served for requests with path /
Type: string
Invalidates the CDN cache after each deployment
Type: boolean
- This prevents serving outdated content to your users
- If you choose to invalidate the cache, CDN will flush all the cached content and new requests will result in a request to the origin (bucket, application-load-balancer or http-api-gateway)
CDN with bucket
With bucket you can enable CDN using two lines.
Copy
resources:myBucket:type: bucketproperties:cdn:enabled: true
By default, CDN caches content returned from the bucket for 6 months.
Most comon use case for using CDN with a bucket is using the bucket to serve your static website:
Stacktape can automatically set-up correct cache-control headers for your static content when uploading the content to the bucket.
See Cache control section to understand how to control the caching behavior.
CDN with http-api-gateway
With http-api-gateway you can enable CDN using two lines.
Copy
resources:myApiGateway:type: http-api-gatewayproperties:cdn:enabled: true
By default, CDN does not cache any content returned from the http-api-gateway, as it assumes that all content returned by http-api-gateway is dynamic. You can control caching behaviour by sending the cache control header within response from http-api-gateway. See Cache control section for more information.
CDN with application-load-balancer
With http-api-gateway you can enable CDN using two lines. If your application-load-balancer uses custom listeners you need to specify the port of a listener to which the CDN should deliver traffic.
Copy
resources:myApiGateway:type: application-load-balancerproperties:cdn:enabled: true
By default, CDN does not cache any content returned from the application-load-balancer, as it assumes that all content returned by application-load-balancer is dynamic. You can control caching behaviour by sending the cache control header within response from application-load-balancer. See Cache control section for more information.
Custom domain names
Stacktape allows you to connect your custom domain names to some of your resources (HTTP API Gateways, Application Load Balancers and Buckets with CDNs).
Connecting a custom domain to the resource does 2 things:
- Creates DNS records:
- If you use your custom domain with a resource, Stacktape automatically creates a DNS record (during deploy) pointing the specified domain name to the resource.
- Adds TLS certificates
- If the origin resource (HTTP API Gateway, Application Load Balancer or CDN) uses HTTPS protocol, Stacktape takes care of issuing and attaching correct (free, AWS-managed) certificate to the resource. This means, you do not have to deal with TLS termination as it is handled by the connected resource.
- If you want to use your own certificates, you can configure
customCertificateArns
.
To manage a custom domain, it first needs to be added to your AWS account. This means that a hosted zone (collection of records managed together for a given domain) for your domain exists in your AWS account and your domain registrar's name servers are pointing to it. To learn more, refer to Adding a domain guide.
Fully qualified (absolute) domain name.
Type: string
- Must be specified WITHOUT the protocol (omit the https:// part)
- Example:
mydomain.com
orpreview.mydomain.com
ARN of a custom certificate to be provisioned with this domain
Type: string
- Stacktape generates certificates for all your domains.
- If you want to use a custom certificate (managed within your AWS account), you can specify its ARN (Amazon Resource Name).
Enables creation of a DNS record
Type: boolean
- Stacktape creates a DNS record by default for all of your domains.
- If you want to configure DNS records on your own, set this to
true
.
Copy
resources:myHttpApi:type: 'http-api-gateway'properties:cdn:enabled: truecustomDomains:- domainName: mydomain.com
CDN lambda functions@edge
You can associate
cdn-lambda-function
with CDN to be executed:onRequest
- function is executed when CDN receives a request from a client(viewer) before checking CDN cacheonResponse
- function is executed before returning the response to the client(viewer)
Potential use-cases for using cdn functions:
- generating immediate HTTP response without the need to check CDN cache or forward to origin
- modifying request (i.e rewrite url, headers etc) before forwarding to the origin
- inspection of cookies
- inspection/validation of authorization headers and tokens
For more information refer to CDN lambda functions page.
Name of the cdn-lambda-function in the config
Type: string
onRequest
function is triggered when CDN receives a request from a client(viewer):- You can modify the request before forwarding it to the origin
- You can return immediate response to the client(viewer)
- You can make network calls to external resources to confirm user credentials, or fetch additional content
- The body of the request is exposed to the function with some restrictions (refer to AWS docs for more details)
Name of the cdn-lambda-function in the config
Type: string
onResponse
function is triggered before CDN returns response to the client(viewer):- You can modify the response (headers, cookies) before returning to the client
- The function does not execute in following cases:
- When the origin returns an HTTP status code of 400 or higher.
- When the response is generated from a function that was triggered by a viewer request event (
onRequest
function).
Copy
resources:authFunction:type: cdn-lambda-functionproperties:packaging:type: stacktape-lambda-buildpackproperties:entryfilePath: auth-function.tsmyBucket:type: bucketproperties:cdn:enabled: truecdnFunctions:onRequest: authFunction
Cache control
There are 2 ways to control caching behavior of the CDN:
By using
cache-control
header in the responses from your origins.cache-control
header is automatically detected by the CDN and the response is cached based on the directives in the header.- to see how to configure
cache-control
header, refer to respective sections for bucket or http-api-gateway/application-load-balancer - this approach gives you fine-grained control over caching behavior and is recommended.
By setting (
minTTL
,maxTTL
,defaultTTL
) in CDN caching options.- this approach lets you set basic caching rules, but is overall less flexible.
- see section CDN cache options
Stacktape automatically invalidates cache after each successfull deployment.
This means that each time you deploy, entire cache in all CDN PoPs (edge locations) is flushed and subsequent requests to CDN will need to re-fetch the content from the origin.
You can disable automatic invalidation. See section Automatic invalidation.
Cache-Control header with buckets
You can set cache-control header by setting metadata on the objects uploaded to your bucket.
Stacktape can set the correct cache-control headers automatically when uploading objects to your bucket, if you:
- choose to upload your objects using directory upload functionality,
- use one of the headers presets. The header presets are made for most common use-cases, but you are also able to customize them and set your own headers.
Copy
resources:myBucket:type: bucketproperties:directoryUpload:directoryPath: my-web/buildheadersPreset: static-websitecdn:enabled: true
Bucket with directoryUpload
and headersPreset
Cache-Control header with http-api-gateway/application-load-balancer
When using CDN with a http-api-gateway or an application-load-balancer, you can set cache-control header by sending it with response from your application.
Consider following example:
Copy
resources:myApiGateway:type: http-api-gatewayproperties:cdn:enabled: truemyFunction:type: functionproperties:packaging:type: stacktape-lambda-buildpackproperties:entryfilePath: hello.tsevents:- type: http-api-gatewayproperties:httpApiGatewayName: myApiGatewaymethod: GETpath: /hello
Stacktape configuration with CDN enabled http-api-gateway and a function
Copy
export default async (event, context) => {return {statusCode: 200,statusDescription: '200 OK',isBase64Encoded: false,headers: {'Content-Type': 'text/plain','Cache-Control': 'max-age=30'},body: 'Hello !!!'};};
Code of the function returning response that sets the cache-control header
Similar configuration could be done with aplication-load-balancer. Or you could swap the function for a container-workload since the response format is same.
To understand directives in the cache-control
header and how to use them, refer to
MDN docs.
CDN caching options
Caching options enable you to specify default caching behavior for your CDN.
You can specify different caching options for each route rewrite. This gives you ability to set different default caching options for different routes.
If you do not specify caching options, Stacktape uses default caching options (depending on the target origin):
Origin type | minTTL | maxTTL | defaultTTL |
---|---|---|---|
Bucket | 0 | 31536000 | 15768000 |
Http Api Gateway | 0 | 31536000 | 0 |
Application Load Balancer | 0 | 31536000 | 0 |
In the following example:
- We are setting default TTL for the default route to 60 seconds (1 minute).
- Every request, with URL path starting with
/static
has default TTL 604800 seconds (1 week). - If responses from origin do not contain
cache-control
header, default TTL is used.
Copy
resources:myHttpApi:type: 'http-api-gateway'properties:cdn:enabled: truecachingOptions:defaultTTL: 60routeRewrites:- path: /static/*cachingOptions:defaultTTL: 604800
Only responses to the requests with these methods will be cached
Type: Array of string ENUM
Possible values: GETHEADOPTIONS
- Possible values are:
['GET', 'HEAD']
['GET', 'HEAD', 'OPTIONS']
The minimum amount of time in seconds that the objects will stay in the CDN cache before another request is sent to the origin
Type: number
- To learn more about cache expiration, refer to AWS Docs
The maximum amount of time in seconds that the objects will stay in the CDN cache before another request is sent to the origin
Type: number
- To learn more about cache expiration, refer to AWS Docs
The default amount of time in seconds that the objects will stay in the CDN cache before another request is sent to the origin
Type: number
- To learn more about cache expiration, refer to AWS Docs
Disables compression of the objects served by the CDN
Type: boolean
- Compression is enabled by default.
- Compression can significantly reduce the size of the responses from the CDN. In some cases, less than a quarter the size of the original. This can result in a better performance and lower transfer costs.
- The CDN compresses objects using the
Gzip
andBrotli
compression methods. - If the viewer supports both formats, Brotli version is used.
- The client must indicate that it accepts compressed files using the
Accept-Encoding
HTTP header. - To learn more about compression, refer to AWS Docs
Configures HTTP headers, cookies, and URL query strings to include in the cache key
Type: CdnCacheKey
- By default the cache key depends on the type of origin the CDN routes to:
- bucket - only
url path
is part of the cache key - http-api-gateway and application-load-balancer - only
url path
andquery string
are part of the cache key
- bucket - only
- The values included in the cache key are automatically forwarded in the requests that the CDN sends to the origin.
Controlling cache key
The cache key is the unique identifier for every object in the cache. It determines whether a client request results in a cache hit. A cache hit occurs when a client request generates the same cache key as a prior request, and the object for that cache key is in the CDN PoP location's cache. If the object is in the cache and is valid, it can be served to client without sending request to the origin.
- A cache key can be configured to include headers, cookies, or query params.
- Every part of request that is included in a cache key is automatically forwarded to the origin. If you wish to forward parts of request to the origin but NOT include them in the cache key, use forwarding options
- Cache key can be controlled by using
cacheKeyParameters
within caching options.
If you do not specify cache key, Stacktape uses default cache key (depending on the target origin):
Origin type | Parts of request included in cache key |
---|---|
Bucket | URL path |
Http Api Gateway | URL path + all query params + Authorization header |
Application Load Balancer | URL path + all query params + Authorization header |
Example usage: If your origin uses the Accept-Language
HTTP header in client requests to return different content
based on the client’s language, you might want to include this header in the cache key.
Copy
resources:myApiGateway:type: http-api-gatewayproperties:cdn:enabled: truecachingOptions:cacheKeyParameters:headers:whitelist:- Accept-Language
CDN with custom cache key configured: URL(default) + Accept-Language header
Configures cookies that will be included in the cache key
Type: CacheKeyCookies
- The cookies included in the cache key are automatically forwarded in the requests that the CDN sends to the origin.
- By default no cookies are included in the cache key.
Configures headers that will be included included in the cache key
Type: CacheKeyHeaders
- The headers included in the cache key are automatically forwarded in the requests that the CDN sends to the origin.
- By default no headers (except
Accept-Encoding
for compression to work) are included in the cache key.
Configures query parameters that will be included in the cache key
Type: CacheKeyQueryString
- The query params included in the cache key are automatically forwarded in the requests that the CDN sends to the origin.
- By default no query params are included in the cache key.
CDN forwarding options
Forwarding options specify which parts of a request get forwarded to the origin. You can also filter which types (methods) of requests are forwarded.
Different forwarding options can be specified for each route rewrite.
If no forwarding options are specified, Stacktape uses default forwarding options (depending on the target origin):
Origin type | Parts of request forwarded to origin |
---|---|
Bucket | URL path |
Http Api Gateway | URL path + all query params + all headers + all cookies |
Application Load Balancer | URL path + all query params + all headers + all cookies |
Copy
resources:myHttpApi:type: 'http-api-gateway'properties:cdn:enabled: trueforwardingOptions:allowedMethods:- 'GET'- 'POST'
CDN configured to only forward requests with methods GET
and POST
Adds static headers that the CDN will add to all requests sent to the origin
Type: Array of CdnCustomRequestHeader
Configured methods that will be forwarded by the CDN to the origin
Type: Array of string ENUM
Possible values: DELETEGETHEADOPTIONSPATCHPOSTPUT
- If not set, all methods are forwarded
Configured cookies forwarded to the origin
Type: ForwardCookies
- If not set, all cookies are forwarded
- All cookies that are part of the cache key (see
cachingOptions
) are automatically forwarded to the origin.
Configured headers will be forwarded to the origin
Type: ForwardHeaders
- If not set, all headers are forwarded
- All headers that are part of the cache key (see
cachingOptions
) are automatically forwarded to the origin.
Configured query params will be forwarded to the origin
Type: ForwardQueryString
- If not set, all query string parameters are forwarded
- All query string parameters that are part of the cache key (see
cachingOptions
) are automatically forwarded to the origin.
Route rewrites
Route rewrites can be used to route incoming requests to different origins: I.e., instead of forwarding a request to the main origin (the one CDN is attached to), the request can be forwarded to some other origin (http-api-gateway, bucket, application-load-balancer or a custom origin).
- Each incoming request to the CDN is first evaluated against route rewrites. The requested path is compared with path pattern specified in route rewrite.
- If the requested path matches the path pattern specified by route rewrite, the request is sent to the configured route.
- Route rewrites are evaluated in order. The first match is where the request will be sent to.
- If no match is found, request is sent to the default origin (the one that the CDN is attached to).
Example use cases:
- Most of the content you are serving is a static content
served from a bucket (static website). Some content however needs to be
rendered dynamically by a lambda function. You can route paths that need
to be rendered dynamically to the lambda function through
http-api-gateway
. - You want to cache your
jpg
files longer than other files. You can create route rewrite that will catch every path ending withjpg
and set custom caching options for these paths.
Path to be adjusted by this route rewrite
Type: string
- You can use wildcards for your path patterns to match multiple paths.
- To learn more about path patterns, refer to AWS docs
Prefixes every request to the origin with the specified prefix
Type: string
- All requests coming to the CDN will be prefixed with
routePrefix
before being forwarded to the origin. - Example: If the CDN receives a request with path
/my/resource/url
, the request will be sent to the origin as/route_prefix/my/resource/url
Configures the origin to which the route rewrite forwards requests
Type: (CdnLoadBalancerRoute or CdnHttpApiGatewayRoute or CdnCustomDomainRoute or CdnBucketRoute)
- If not set, the default origin (the one this CDN is attached to) is used
Configures custom caching options for this route rewrite
Type: CdnCachingOptions
- Configures the caching behavior of your edge distribution (what & when should stay in cache, and when to refetch it from the origin)
- When response from the origin does not contain neither
cache-control
norexpires
headers default caching behaviour is used. - Default caching behaviour depends on the type of origin the CDN routes to:
- bucket - by default objects are cached for 6 months (or until the CDN cache is invalidated).
- http-api-gateway and application-load-balancer - by default responses are not cached.
Enables you to redirect specific requests to a different origin
Type: CdnForwardingOptions
- Forwarding options enable you to set which parts of the request are forwarded to the origin (headers, query params, cookies etc.)
Configures CDN function triggers
Type: CdnFunctionsConfig
You can associate
cdn-lambda-function
with CDN to be executed:onRequest
- function is executed when CDN receives a request from a client(viewer) before checking CDN cacheonResponse
- function is executed before returning the response to the client(viewer)
Potential use-cases for using cdn functions:
- generating immediate HTTP response without the need to check CDN cache or forward to origin
- modifying request (i.e rewrite url, headers etc) before forwarding to the origin
- inspection of cookies
- inspection/validation of authorization headers and tokens
Routing to bucket
No description
Type: string "bucket"
Name of the bucket
Type: string
Disables URL normalization (ability to use clean urls without the .html
extension)
Type: boolean
- URL normalization is enabled by default.
- URL normalization is useful when you want to serve HTML files from the bucket
- When the URL normalization is enabled, the CDN is able to fetch correct HTML files
from the bucket even when incomplete URL is used (without the
.html
extension) - This enables you to use URLs such as
<
instead of urls>/about <
or>/about.html <
>/about/index.html
In the following example:
- we are routing all requests with url path starting with
/static
to the bucket myBucket. - all other requests are routed to the http-api-gateway myHttpApi (default origin).
Copy
resources:myHttpApi:type: 'http-api-gateway'properties:cdn:enabled: truerouteRewrites:- path: /static/*routeTo:type: bucketproperties:bucketName: myBucketdisableUrlNormalization: truemyBucket:type: 'bucket'
Routing to application-load-balancer
No description
Type: string "application-load-balancer"
Name of the Load balancer
Type: string
Port of the Load balancer listener
Type: number
- You need to specify listener port if the load balancer you are routing to uses custom listeners.
Explicitly sets the origin domain name you wish to use when forwarding to load balancer
Type: string
- This is required only if the load balancer has no
customDomains
attached and listener usescustomCertificateArns
In the following example:
- we are routing all requests with url path starting with
/app2
to the application-load-balancer myLoadBalancer. - all other requests are routed to the http-api-gateway myHttpApi (default origin).
Copy
resources:myHttpApi:type: 'http-api-gateway'properties:cdn:enabled: truerouteRewrites:- path: /app2/*routeTo:type: 'application-load-balancer'properties:loadBalancerName: myLoadBalancermyLoadBalancer:type: 'application-load-balancer'
Routing to http-api-gateway
No description
Type: string "http-api-gateway"
Name of the HTTP Api Gateway
Type: string
In the following example:
- we are routing all requests with url path starting with
/app2/
to the http-api-gateway appApiGateway. - all other requests are routed to the http-api-gateway myHttpApi (default origin).
Copy
resources:myHttpApi:type: 'http-api-gateway'properties:cdn:enabled: truerouteRewrites:- path: /app2/*routeTo:type: 'http-api-gateway'properties:httpApiGatewayName: appApiGatewayappApiGateway:type: 'http-api-gateway'
Routing to custom origin
No description
Type: string "custom-origin"
Domain name of the custom origin.
Type: string
Example: mydomain.com
or domain.example.com
Protocol to use when connecting to custom origin.
Type: string ENUM
Possible values: HTTPHTTPS
Port of the custom origin.
Type: number
By default port number 443 is used for HTTPS
origins and port number 80 is used for HTTP
origins.
In the following example:
- we are routing all request with url path starting with
/external
to the custom origin (my-custom-origin.example.com
). - all other requests are routed to the application-load-balancer myLoadBalancer.
Copy
resources:myLoadBalancer:type: 'application-load-balancer'properties:cdn:enabled: truerouteRewrites:- path: /external/*routeTo:type: custom-originproperties:domainName: my-custom-origin.example.com
Automatic invalidation
By default Stacktape invalidates the CDN cache after each deploy. This means that the cache is flushed and new requests will result in requests to the origin. This in turn ensures that only new content is served to the clients.
You can disable automatic invalidation by setting invalidateAfterDeply
to false.
Copy
resources:myApiGateway:type: http-api-gatewayproperties:cdn:enabled: trueinvalidateAfterDeploy: false
Setting price class
You can set price class to reduce the costs for your CDN. Setting price class affecs the number locations (PoPs) from which the CDN serves traffic.
- Higher price class results in more locations that serve your traffic.
- This can result in better performance in some regions, but is more costly.
- Example: If your users are located only in US & Europe, you can save money by configuring
PriceClass_100
- To learn more about price classes, refer to AWS docs
Copy
resources:myApiGateway:type: http-api-gatewayproperties:cdn:enabled: truecloudfrontPriceClass: PriceClass_200
API reference
No headers are included in the cache key
Type: boolean
Only the headers listed are included in the cache key
Type: Array of string
All query params are included in the cache key
Type: boolean
No query params are included in the cache key
Type: boolean
Only the query parameters listed are included in the cache key
Type: Array of string
Name of the header
Type: string
Value of the header
Type: string
No headers are forwarded to the origin
Type: boolean
Only the headers listed are forwarded to the origin
Type: Array of string
All viewer headers are forwarded to the origin
Type: boolean
All viewer headers and additional listed CDN headers are forwarded to the origin
Type: Array of string
All query params are forwarded to the origin
Type: boolean
No query params are forwarded to the origin
Type: boolean
Only the query parameters listed are forwarded to the origin
Type: Array of string