- UserVariant—The response is dependent on the user's identity.
- DesignUserVariant—The response is from a database that has protected elements.
- DbData—The response uses data in the database other than the referenced document.
- UsedDocId—The response uses the document ID.
- UsedNewDoc—The response uses a newly-created in-memory note.
  It should be understood that this list is a non-exhaustive list given for illustrative purposes. Additional examples are shown in the above-referenced '767 patent.

In any event, afterattribute analyzer58 has developed a composite of attributes for the parts of the response, the composite will be passed tocacheability analyzer interface60 ofcacheability analyzer42. As described in '767,caching strategy generator62 will examine the composite of attributes to determine whether the response is cacheable, and to generate a set (e.g., one or more) of cacheability flags based thereon. The cacheability flags reflect a caching strategy for the response. Illustrative flags are as follows:

- DontCache—The response is not cached.
- Document—Invalidate the cached response when the document changes.
- DbDesign—Invalidate the cached response when the database design changes.
- DbData—Invalidate the cached response when any of the data in the database changes.

Using an algorithm such as disclosed in '767, the cacheability flags are set. If the determination is that the response is cacheable, the set cacheability flags are passed to tagsystem44. Under the present invention,tag generator46 will then generate an entity tag for the response that is generally based on the sources of the content, as well as any dependencies of the response on those sources. Specifically, the entity tag will identify the sources of the dynamic content in the response, and will include a tag version number, the cacheability flags, time values, and optionally, a document identifier and a user name (if the dependencies so require). Accordingly, the entity tag could resemble the following:

- XX-YYYY-DesignTimeDate-DateTimeDate-UNID-UserName
  where:
- XX represents major and minor version numbers of the tag format (e.g. 10)
- YYYY represents ASCII hex string representation of the 16 bit cacheability flags field.
- DesignTimeDate represents the last modified time value of the database design as a 16 digit ASCII hex string.
- DateTimeDate represents a 16 digit ASCII hex string of either the last modified time value of data in the database, or of a specific document in the database on which the response depends.
- UNID represents the document identifier in the event DateTimDate refers to a specific document in the database.
- UserName refers to the name of the specific user issuing the request in the event the response is user variant.

It should be understood that in most cases, content within the response will generally be dependent on either data within the database, or a specific document within the database. Although a response can depend on both, since the document resides within the database, the database last modified date will always be the same or later than the last-modified date of the most recently modified document therein. Accordingly, it is not typically necessary to record both, and DateTimeDate can represent one or the other. In the case of the former, if any data within the database changes, a cached response is no longer valid. In the case of the latter, if data within the document identified by the UNID changes, the cached response is no longer valid. In any event, once the entity tag is generated it is Base64 encoded, wrapped in quotation marks and preceded by “W/” to indicate that the entity tag is a weak cache validator (as described in the HTTP 1.1 specification). Identifying the entity tag as a weak cache validator essentially ensures that it will only be used with HTTP GET and HEAD requests, and that at most one entity tag will be associated with any given request.

The entity tag will accompany the response in an “E-Tag” header as communicated toclient22 viacommunication system50. Upon receipt, the response andentity tag56 are cached inbrowser25. Ifuser24 later requests the same web page, a conditional get request is issued. Specifically, the entity tag is sent toserver26 in an “If-Non-Match” header. Upon receipt,communication system50 will forward the entity tag to taganalyzer48, which will decode the entity tag and determine whether the cached response is valid. Specifically,tag analyzer48 will compare the time values in the entity tag to corresponding time values for the sources identified by the entity tag. If the time values match, the cached response is still valid. Thereafter, a status code (e.g., HTTP 304—Not Modified) will be sent toclient22 so that the cached response can be displayed foruser24 Conversely, if one or more of the time values do not match, or if the entity tag indicates that the cached response is user variant and the user name encoded within the entity tag does not match the logged-in user name, the response is no longer valid (i.e., is stale). Accordingly,response builder40 will build a new response and a new composite set of attributes that cacheabilityanalyzer42 will use to determine whether the new response is cacheable and to generate a new set of cacheability flags. The new set of cacheability flags is then used bytag system44 to generate a new entity tag that is sent toclient22 with the new response in an “E-Tag” header. Similar to the previous response, the new response and entity tag are cached inbrowser25 for possible later use. As can be seen, the present invention allows remotely cached dynamic content web pages to be validated simply by analyzing the entity tag. That is, no evaluation or rebuilding of the web page is required.

Referring now toFIG. 4, a method flow diagram100 of the present invention is shown. As depicted, first step S1 is to receive a request. In step S2, it is determined if the response contains an If-None-Match header. If not, a response is built in step S3. However, if the request did contain an If-None-Match header, the entity tag therein would be decoded in step S4. Thereafter, the tag attributes and dependencies would be compared against the corresponding resources in step S5. That is, the time values in the entity tag would be compared to corresponding time values of the relevant dynamic content sources. Based on the comparison, it would be determined whether the response is still valid or is stale in step S6. If the response was still valid, a Not Modified status code would be returned to the client in step S7. However, if the response was deemed to be invalid in step S6, a response would be built in step S3. After the response is built, a composite of attributes would be generated in step S8. That composite would then be analyzed in step S9 for cacheability. Based on the analysis, an entity tag would be generated in step S10, and the new response and entity tag would be sent to the client in step S11.

It should be understood that the present invention can be realized in hardware, software, or a combination of hardware and software. Any kind of computer system(s)—or other apparatus adapted for carrying out the methods described herein—is suited. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when loaded and executed, carries out the respective methods described herein. Alternatively, a specific use computer, containing specialized hardware for carrying out one or more of the functional tasks of the invention, could be utilized. The present invention can also be embedded in a computer program product, which comprises all the respective features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods. Computer program, software program, program, or software, in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: (a) conversion to another language, code or notation; and/or (b) reproduction in a different material form.

The foregoing description of the preferred embodiments of this invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and obviously, many modifications and variations are possible. Such modifications and variations that may be apparent to a person skilled in the art are intended to be included within the scope of this invention as defined by the accompanying claims.