Last updated on: 2020-12-10
Authored by: Rackspace Support
When an object that is defined in the origin and located in the appropriate path is not being cached by Akamai, you should contact Rackspace Support for assistance. However the following information provides some insight into why this situation might occur.
The most common reason that cacheable objects are not cached is the presence of a Vary header in the origin server response.
The Vary header informs Akamai servers that the content of the object might differ based on some characteristic, such as the client’s specified user-agent or language, and is therefore not cacheable. This behavior is valid based on RFC HTTP/1.1.
However, if the Vary header has a single value of Vary: Accept-Encoding and the response is accompanied by Content-Encoding: gzip, then Akamai caches the content. If the Vary header contains any values other than Accept-Encoding, Akamai does not cache the object.
This restriction is necessary to prevent different versions of content from being cached and then later served to end users for whom the content is not intended. For example, this prevents pages in one language from being cached and served to users of another language, or pages designed specifically for a certain browser from being cached and then served to users on another browser.
An Accept-Encoding value to the Vary header is the exception to this restriction only when it relates to serving the object compressed. Because compression does not change the content of the object (only its size for transfer), an object that varies only by its compression can be safely cached.
In addition to the presence of a Vary header in the response, following are the most prevalent reasons why objects that are specified to be cached are not cached on an edge server:
©2020 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License