How the Instart Platform Handles Caching

How does Instart handle cache expiration/invalidation?

There are a couple of ways that cache invalidation/expiration is handled depending on the configuration settings for a particular account. There are three possible settings: bypass, HTTP specification-based, and Fixed Time To Live.

Bypass

Caching can be bypassed, in which case we go straight to the origin server, and we do not store the response.

HTTP specification-based

If configured in this way, we cache the response based on the response headers. We defer to our customer's origin headers as being authoritative and act appropriately based on their HTTP response headers.

  • Only HTTP Status 200 responses to GET requests are cached.
  • HTML MIME types text/html, text/xml, text/xml+xhtml, text/xhtml and application/html,application/xml, application/xml+xhtml, application/xhtml are not cached by default. We can enable caching of HTML MIME types in the configuration if desired.
  • Vary: responses that vary on headers other than accept-encoding are cached by default. We can modify this in the configuration if desired.
  • We support revalidation with the origin by default.
  • The following header directives will never be cached:

    • Cache-Control: no-cache
    • Cache-Control: no-store
    • Cache-Control: private
    • Pragma: no-cache
    • Vary: *

    If Cache-Control: no-cache=<list of headers> or Cache-Control: private=<list of headers>, we only prevent the specified headers from being cached. This does not cause the response itself to be uncacheable.

  • A response must have at least one of the following headers to be cached. If cache directive headers are missing, then the response is not cached.

    • Cache-Control: max-age
    • Cache-Control: s-maxage
    • Cache-Control: public
    • Expires

    Note

    Responses without Cache-Control headers may be cached – see below.

    The order of precedence of Cache-Control directives is s-maxage, max-age, Expires.

    The max-age, s-maxage TTL is calculated as follows:

    max-age TTL = (value of max_age) - (value of the Age header if present)

    max-age TTL = now - (value of Date header) if only the Date header is present

    The Expires TTL is calculated as follows:

    Expires TTL = (value of the Expires header) - now.

  • If the response has Cache-Control: public, but no other caching directives, then it is cached by default for a predefined time (7200 seconds) set globally for the Instart service.
  • For request headers: Cache-busting request headers (for example, a request withCache-Control: no-cache or Pragma: no-cache) will not bypass the cache by default. This can be changed in the configuration if desired.

Fixed Time to Live (TTL)

If configured in this way, we cache the response with a given fixed TTL that is specified in the configuration. This overrides all Cache-Control headers, including Cache-Control: private, Cache-Control: no_cache, Cache-Control: no_store, Cache-Control: s-maxage,Cache-Control: max-age, and Expires.

  • All HTTP Status 200 responses to GET requests are cached.
  • HTML MIME types text/html, text/xml, text/xml+xhtml, text/xhtml and application/html,application/xml, application/xml+xhtml, application/xhtml are not cached by default. We can enable caching of HTML MIME types in the configuration if desired.
  • Vary: responses that vary on headers other than accept-encoding are cached by default. We can disable this in the configuration if desired.
  • Cache object lifetime is TTL + retrieval_time, where retrieval_time is the time that the proxy first downloads the object from the origin server.

Is anything aside from the URI considered when an object is cached?

By default, an object's path, protocol, and query string (if present) is used to generate the cache lookup key used to identify the cached object.

There is the configuration option to override the inclusion of the query string in the cache. We can also ignore a specified portion of the query string.

We can also further specify an object's cache key by including additional cache key modifiers. You can, for example, specify that if a particular cookie, or header, is present in the request, the service should incorporate these in creating the cache key.

Can object revalidation be done?

We provide the capability for our service to do a lightweight check with your origin web server when a static object cached in our system expires. If the object is still the same, we then update the expiry time for the existing object in our system without needing to re-download the object. Previously our system would remove and re-request objects once they expired. In the case of images, this would require us to re-run image processing operations such as transcoding on the object. This feature reduces the loading on your back-end origin servers and reduces loading on our service.

The Cache-Control headers (and config) enable the proxy to determine how fresh a cached object is. Any request for a non-stale cached object will result in the cached object being sent back to the client.

If there is an origin error, can Instart serve stale assets from its cache?

Yes, we can configure your account to serve stale assets from our cache in cases where the origin is unreachable, down, or returning certain status codes. This feature can be enabled by contacting our customer support team at support@instartlogic.com.

How can I manually purge my cache?

There are two ways: through the customer portal web application, or through a call to Instart's REST API.

Using the portal

On the customer portal is a cache purge function, available on the Config menu. You can specify either a single path or specific asset in one domain, multiple paths or assets in multiple domains, or an entire domain. 

For details, see Purging Your Cache in the Portal

Using the REST API

Instart provides a REST API that can be used to purge the cache. On request, Instart Support can provide you with the root URL, a authentication key, and a Python script you can use to issue requests.

The API is described in more detail in the Cache Purge API Guide.

Tiered Caching (formerly Origin Shield)

In a distributed environment, every PoP that gets a cache miss for some content will fetch the content from the origin. Our Tiered Caching feature allows our proxies to route requests for static objects through a single logical Tiered Caching location close to the customer's origin web servers. This single logical location will cache static objects once for the entire service. When another PoP in the service has a cache miss, it will retrieve the object from the Tiered Caching location. This reduces the number of requests that we make to our customer's origin servers for the same objects. Without Tiered Caching, each PoP in our service could potentially ask for the same object, meaning the customer's origin would send the same object to our service many times.

Tiered Caching is not enabled by default. If you want this feature to be turned on for your site, or have any questions, please contact Support.