How to Configure HTTP(S) Object Cache (Proxy)


  • Configuration option for new Proxies or Applications in Proxy / App Management section of Portal.
  • Appears under Advanced tab. 
  • Silverline HTTP Cache will honor cache-related HTTP headers in accordance with RFC2616, along with some implementation-specific logic.

For more info on Proxy / App Configuration, see:




Silverline Cache Object Logic

The Silverline caching layer includes additional logic to prevent caching of dynamic objects and requests that may interfere with security processing, particularly WAF. 

Specifically, Silverline will never serve objects from cache (i.e. objects that are already in cache memory) for HTTP requests that meet any of the following criteria:

  • Use a request method other than GET
  • Include an Authorization or Proxy-Authorization header 

Silverline caching layer will attempt to cache objects from HTTP 200 OK responses that meet any of the following criteria:

  • Include a Content-Type header starting with image/
  • Include an Expires header
  • Include a Cache-Control header

However the following exclusions exist, meaning that the caching layer will not cache objects from responses that meet any of the following criteria:

  • Include a Set-Cookie header
  • Include a Vary header with value 'accept-encoding'

 Finally, any requests that generate WAF violations and/or other WAF processing will not be cached.  For more details, please see: K14880: The BIG-IP ASM system may prevent object caching


HTTP Caching Headers

1. cache-control

If there were a default super-header for caching behavior, this would be it. Typically you will see a string of settings for this header along the lines of:

cache-control: private, max-age=0, no-cache

These settings are called cache response directives, and are as follows:

private | public

Essentially they let intermediary caches know that a given response is specific to the end user and should not be cached. Do not make the mistake of assuming that this in any way provides you with some kind of security or privacy: Keep using SSL for that.


When used alone, this header lets you specify that caches should revalidate this resource every time, typically using the "etag" header outlined below. The fun bit comes when you specify a field name after the no-cache directive, which lets caches know that you can cache the response, provided that the named fields are stripped out; cookies would be a good example of why you might want to do this. I should note that older User Agents won't respect this trick, so you shouldn't depend on it too much.


This header lets you specify that caches should not store this response. I know that may be surprising given the name, but there it is. Actually, if the cache in question is following the rules, it will also ensure that no part of the request is stored either. "no-store" was designed with sensitive information requirements in mind, and so is kind of like the G-Man of cache headers.


Traditionally, you would let caches know when an asset is expired by using the aptly-named "expires" header, discussed below. However, if you want to be more explicit, you may set a max-age, in seconds, which will override the expires header. Further reasons to use this directive are discussed below under the Caveats section.


Using our keen deductive skills, we can see some similarities between this header and the last one. "s-" is for shared, as in "shared cache", as in CDN. These directives are explicitly for CDNs and other intermediary caches. When present, this directive overrides both the max-age and expires header, and most well behaved CDNs will obey it.


This one is fun, although not applicable to most of us. For the sake of completeness, and in case your dev-team has some kind of trivia night where free beer is involved, we'll discuss it. Essentially, if your responses include this directive, you are telling the cache that it needs to revalidate a cached asset on any subsequent request, and that it may not, under any circumstance, serve stale content (which is sometimes a desired behaviour). Of course, I say "under any circumstances", but what I really mean is that there's a big fat asterisk next to that claim. If your users are under "severe connectivity constraints", (perhaps they are browsing from low-earth-orbit), then their user agents may serve stale content, provided they pinky-swear to tell their users that they've done so. Apparently this directive exists because some protocols require it, typically involving transactions.


“Transform into what?”, you’re surely asking. Some proxies will convert image formats and other documents to improve performance. Presumably this was thought to be a feature that you should have to opt out of. If you don’t like the idea of your CDN making automated guesses about how your content should be encoded or formatted, I suggest including this header.


Essentially the same as the "must-revalidate" directive, except it's just for the shared caches. Why didn't they call it "s-mustrevalidate"? I'm sure there exists a mailing list somewhere where you could find that debate, but for now, just know that like "s-maxage", this directive is designed for intermediary proxies and not user agents. The idea here is that you validate each end-user only once between the proxy and their agent, but each new user should revalidate back to the server. I suspect if your service requires this feature, you probably already know about it.

As always, you should check out the spec for these settings if you need any clarification.


2. expires

On most modern systems, the "cache-control" headers "max-age" and "s-maxage" will take precedence, but it's always good practice to set a matching value here for compatibility. Just make sure you format the date correctly, or it will be evaluated as an expired date:

Thu, 01 Dec 1983 20:00:00 GMT

Try to avoid setting the value to more than one year out as that breaks the specification, (see below for a discussion on cache time settings).


3. etag

Short for "entity-tag", the etag is a unique identifier for the resource being requested, typically comprised of the hash of that resource, or a hash of the timestamp the resource was updated. 

There's a neat trick you can do with etags, which is to make them weak validators. This basically tells the user that although they are not the same, the two resources are functionally equivalent. Support for this feature is considered optional though, so you will want to do some testing with your providers, (discussed below).


4. vary

The “vary” header is extremely powerful, but can trip up what would otherwise be a simple caching scheme. IE has had issues handling the "vary" header in the past, and at one point, even Chrome was handling this in a funny way. Essentially, "vary" lets the caches know which of the headers to use to figure out if they have a valid cache for a request; if a cache were a giant key-value store, adding "vary" fields appends those values to the key, thus changing which requests are considered valid matches for what exists in the cache.

You would commonly set this to something like "Accept-Encoding" to make sure your gzip'ed assets get served where appropriate, saving you all that bandwidth you might otherwise waste. Additionally, setting:

vary: User-Agent

will put you in the SEO good-books if you happen to be serving different versions of your HTML/CSS depending on the User-Agent of the request. Google will note the header and have the Googlebot crawl your mobile content as well.


5. pragma

Another beast from the days of yore, the "pragma" header does many things, and most of them are honored by newer implementations. The directive we're most concerned with is:

pragma: no-cache

which gets interpreted by newer implementations as:

cache-control: no-cache

I would not generally recommend worrying about it, but for the sake of completeness, there it is. No new HTTP directives will be defined for "pragma" going forward.







Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request