One of the things that have been successfully employed by professional webmasters to improve scalability and lower the web server load is content caching. Content caching is a directive to the client browser to store a certain file that rarely changes such as image on a local computer. Next time the user requests the same page, the cached content is taken from the local computer rather than requested from the web server. Not only it allows for better user experience but also for less load on the web server.

Additional benefit of employing content caching on S3 is that every request to S3 is charged and under some circumstances you can lower your bills significantly if you use smart caching strategy.

Content Expiration can be controlled using two http-headers: Expires and Cache-Control.

Expires Header
Expires header supports exact date and time
Expires: Thu, 9 Sep 2009 14:19:41 GMT

To configure any header you can select the file(s) on S3 and click Set HTTP Headers in the toolbar.

In the popup up dialog click add and locate in this case Expires header. To make it easier we show the exact format for the header value in example. Type the value appropriate for your content.

Cache Control Header
Cache-Control supports relative time. Below are some popular values for Cache-Control Header:
max-age=[seconds] — specifies the maximum amount of time that an representation will be considered fresh. Similar to Expires, this directive is relative to the time of the request, rather than absolute. [seconds] is the number of seconds from the time of the request you wish the representation to be fresh for.
s-maxage=[seconds] — similar to max-age, except that it only applies to shared (e.g., proxy) caches.

for example relative expires for 3 months(90days). To calculate the correct value you should do some math:

90 days * 24 hr * 60 min * 60 sec = 7776000 sec

This will give us a value for max-age parameter and here is how it should look like:

Cache-Control: public, max-age=7776000,

After setting this header your content will expire in 3 month

Other common values for Cache-Control
- public — marks authenticated responses as cacheable; normally, if HTTP authentication is required, responses are automatically uncacheable (for shared caches).

- no-cache — forces caches to submit the request to the origin server for validation before releasing a cached copy, every time. This is useful to assure that authentication is respected (in combination with public), or to maintain rigid freshness, without sacrificing all of the benefits of caching.

- no-store — instructs caches not to keep a copy of the representation under any conditions.

- must-revalidate — tells caches that they must obey any freshness information you give them about a representation. HTTP
allows caches to serve stale representations under special conditions; by specifying this header, you’re telling the cache that you want it to strictly follow your rules.
c
- proxy-revalidate — similar to must-revalidate, except that it only applies to proxy caches.

Note: Cache validation rules depend on some other response/request headers like:

Response headers
ETag (in our case read-only), Last-Modified (in our case read-only, means the filestamp), etc
Request headers (mostly auto-generated by browser and/or proxy server)
If-Match, If-Modified-Since, etc.

Conclusion
Smart content caching allows you to improve scalability of your web site and lower your Amazon S3 bills. Luckily Amazon S3 supports content expiration and CloudBerry Explorer makes it very easy to configure.

Download CloudBerry Explorer freeware here.

Read the original blog entry...