3.5 Dynamic Web Pages
| only for RuBoard - do not distribute or recompile |
3.5 Dynamic Web Pages
Many people worry that caches do not properly deal with what they call "dynamic pages." Such pages are considered dynamic because the content might be different for every request. Time-sensitive information, such as stock prices and weather reports , logically fall into the category of dynamic pages. Pages that have been customized for the user , to include his name or targeted advertisements, are dynamic as well.
Historically, dynamic pages have been problematic because some web caching software had relatively aggressive caching and refresh policies. Dynamic pages were cached and returned as cache hits when perhaps they should not have been. Part of the blame lies with the early descriptions and implementations of HTTP. The HTTP/1.0 RFC [Berners-Lee, Fielding and Frystyk, 1996] was not published until May of 1996, while active development on web caching had been ongoing since early 1994. Without a stable protocol description, implementors are certainly prone to make some mistakes. Even when HTTP/1.0 became official, it still lacked a good description of what can and cannot be cached. Section 1.3 of RFC 1945 states:
Some HTTP/1.0 applications use heuristics to describe what is or is not a " cachable " response, but these rules are not standardized.
Some of the blame lies with the origin servers, however. Even though HTTP/1.1 has more caching features than HTTP/1.0, the older protocol does have enough functionality to prevent a compliant proxy from returning hits on dynamic pages. Unfortunately, confusion arises when an origin server's response leaves out some headers. For example, consider a reply such as this:
HTTP/1.0 200 OK Server: MasterBlaster/1.6.9 Date: Mon, 15 Jan 2001 23:01:43 GMT Content-Type: text/html
How should a cache interpret this? There is no Last-modified date, so the cache has no idea how old the resource is. Assuming the server's clock is correct, we know how old the response is, but not the resource. There is no Expires header either, so perhaps the cache can apply local heuristics. Should a cache be allowed to store this reply? Can it return this as a cache hit? In the absence of rigid standards, some applications might consider this cachable.
These days, you are unlikely to encounter a caching product that incorrectly handles dynamic pages. HTTP/1.1 allows servers to be very specific regarding how a response is to be treated by a cache (see Section 6.3). Over the years , people who implement HTTP caching have had a lot of time to "get it right." An application in compliance with HTTP (1.0 or 1.1) should never cache a response if the origin server does not want it to.
3.5.1 Java Applets
The Java programming language is widely used on the Web for generating dynamic content. Some people wonder if web caches are designed to properly handle Java applets. The answer is a resounding "yes" because of the way in which applets work. Rather than executing on the origin server, as CGI programs and Java servlets do, applets run on the client (usually a browser). Thus, a Java applet file is really static, much like an HTML file, when downloaded from an origin server. The user sees something dynamic only when the applet code executes on the client. Java applets are very much like other static objects, such as text files and JPEG images.
| only for RuBoard - do not distribute or recompile |
