Headers

On Authorization header

The Authorization header is commonly used for HTTP authentication. By default, requests containing an Authorization header bypass the cache entirely, since such requests are typically user-specific and should not be cached or served to other users.

The On Authorization header setting allows you choose one of two options:

• Pass: Bypasses the cache for requests with an Authorization header (default behavior)
• Remove: Strips the Authorization header from the request before processing, allowing the request to be cached normally

Use the Remove option when the Authorization header is not needed for the functionality of the origin server.

Remove returned headers

The Remove returned headers setting allows you to strip specific headers from responses before they are sent to clients. This is useful for removing:

• Internal or debugging headers that should not be exposed to clients
• Backend-specific headers that are not relevant to end users
• Headers that might reveal information about your infrastructure

You can specify up to 5 header names to remove. Header names are case-insensitive. Common examples include removing headers like X-Powered-By, Server, or custom backend headers.

Note: All headers starting with X-NCDN- are automatically removed from responses and do not count against the 5-header limit.

Custom cache key headers

This field allows you to add up to 5 HTTP headers that can be included in your content's cache key. This will allow you to serve different content depending on these headers. Common use cases include:

• Device optimisation: Serve different pages to computers and mobile devices.
• Localisation: Serve your page in different languages depending on an Accept-Language header.
• A/B testing: Use a custom header like X-Variation-ID to serve different versions of a page.
• Geo targeting: Use a Country header to show region-specific pricing or legal disclaimers.

Best practices

• Watch your cardinality: To keep your cache efficient and your hit rate high, keep in mind that the number of objects cached scales multiplicatively. So if your cache is varied on a Country (~200) and DeviceType (maybe 3), you will end up with 600 versions of your page in cache. Therefore, take care to only vary by headers that change your content significantly.
• Stay secure: Never include unique, high-cardinality headers like Authorization, Cookie, or Session-ID in a cache key. Doing so will not only break caching efficiency but risks Cross-User Data Leakage, where one user's private session data is served to another.
• Normalize your headers: For optimal performance, normalize the headers you want to use to vary content. For example, instead of using thousands of User-Agent strings, use a simpler header indicating only mobile or desktop.

Set request headers

The Set request headers setting allows you to add or modify headers on requests before they are sent to your origin server.

You can configure up to 5 headers, each with a name and value. If a header with the specified name already exists in the request, it will be replaced with the new value. If you want to set the host header this can instead be done from the Origins tab.

Set response headers

The Set response headers setting allows you to add or modify headers on responses before they are sent to clients. This is useful for:

• Adding security headers (e.g., X-Frame-Options, X-Content-Type-Options)
• Setting cache control directives for client browsers
• Including custom headers for client-side applications

You can configure up to 5 headers, each with a name and value. If a header with the specified name already exists in the response, it will be replaced with the new value.