6.3 Being Cache-Unfriendly

only for RuBoard - do not distribute or recompile

6.3 Being Cache-Unfriendly

What if you need (or want) to send cache-unfriendly, uncachable responses? To accomplish this, it's only a matter of adding a few specific headers.

If you just want to count the requests , you don't need to make the response uncachable. Instead, you can make caches revalidate the response for each client request. To do this, use the no-cache , max-age=0 or must-revalidate directives. Of these, no-cache is the strongest, max-age=0 is the weakest, and must-revalidate is somewhere in the middle. To insert the no-cache directive with Apache's headers module, use this configuration line:

 Header: append Cache-control no-cache 

If you just want to prevent users from sharing a cached response, you can use the private directive. That still allows the response to be stored in single- user caches.

If your goal is truly to defeat caching, you should use the no-store directive.

Cache-control is an HTTP/1.1 feature; how can you ensure that HTTP/1.0 agents do not store the response? Unfortunately, this is a little bit confusing, and both of the following techniques should probably be used.

According to the HTTP/1.0 specification RFC1945, "If the [ Expires ] date given is equal to or earlier than the value of the Date header, the recipient must not cache the enclosed entity." This rule is unfortunate because expiration and cachability are really separate characteristics. Nonetheless, an HTTP/1.0-compliant cache should not cache a response if the date and expires values are identical or if the expires value is invalid. Many applications use the following:

 Expires: 0 

HTTP/1.0 also defines the Pragma header for both requests and responses. RFC1945 specifically discusses no-cache for requests but not for responses. Even so, it is common practice to include this directive in a response to mark it as uncachable. So, if you really want to be sure, also add this header:

 Pragma: no-cache 

The techniques mentioned above may not be good enough for the really paranoid . Another way to defeat caching is to make each user's URIs unique. Usually, this approach also requires cookies to differentiate individual users. www.globalcomputer.com uses this technique. If you make a request that doesn't have a valid cookie, you get redirected to a unique URL such as:

 HTTP/1.0 302 Moved Temporarily Server: Netscape-FastTrack/2.01 Date: Fri, 02 Feb 2001 04:32:45 GMT Set-Cookie: GlobalOrdernet=TXlN5ajd; expires=Fri, 02-Feb-2001 04:32:45         GMT; path=/; domain=167.206.148.90 Location: /TXlN5ajd/ Content-Type: text/html 

As you can see, the cookie and the URL both contain the string "TXlN5ajd." While this doesn't prevent caching, it does prevent sharing responses between users.

Finally, another way to prevent sharing is to use encrypted transfers, a la SSL/TLS. Caching proxies can only tunnel these responses. Only the client can decrypt the message. Once decrypted, the client can store and reuse the response, however. SSL/TLS requests are also interesting in that they cannot be diverted to interception caches.

only for RuBoard - do not distribute or recompile


Web Caching
Web Caching
ISBN: 156592536X
EAN: N/A
Year: 2001
Pages: 160

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net