7. Caching

The Cloud Servers API makes extensive use of caching layers at various tiers of the system. Purging mechanisms exist to ensure that objects served out of cache are accurate and up to date. GETs returning a cached entity return a 203 (Cached) to signal users that the value is being served out of cache. Additionally, cached entities have the following header set:

Table 2.3. Last Modified Header
Header	Description
`Last-Modified`	Date and time when the entity was last updated.

Note

	Note
A known problem exists with the varnish server. It does not respect the `"Cache-Control: no-cache"` header. To workaround this issue, include an unused parameter with a unique value each time you make a request. This forces the varnish server to treat the request as a new request and to bypass the cache. For example, you might add a parameter to the request like `"?dummyreq=1323710764"`, where the value is `date "+%s"`, which is the number of seconds since the epoch. Each time you make a new request, change this value. For example `"?dummyreq=1323710769"`, which forces the varnish server to bypass the cache.

A known problem exists with the varnish server. It does not respect the "Cache-Control: no-cache" header. To workaround this issue, include an unused parameter with a unique value each time you make a request. This forces the varnish server to treat the request as a new request and to bypass the cache. For example, you might add a parameter to the request like "?dummyreq=1323710764", where the value is `date "+%s"`, which is the number of seconds since the epoch. Each time you make a new request, change this value. For example "?dummyreq=1323710769", which forces the varnish server to bypass the cache.

Legal notices