General:

PipeBoost can examine an incoming page request, locate a cached copy of this page (if it exists) and validate it before the target web application processes this request. The results of the validation are passed to the target application, so that the application can decide whether to send a cached copy in response or to generate a new one. This puts the power of decision into the web developer’s hands so that your users never get stale responses. Cache pre-validation can be an efficient web application acceleration solution when used properly. It can greatly reduce the load on Database and other back office servers.

How it works:

When cache pre-validation is enabled, PipeBoost intercepts the incoming requests and runs them through its logic. To minimize the load on the web server, the validation is only done if the target script/application or its parent directories were configured for pre-validation. The request is examined with various criteria with a final goal to determine if compressed content may be sent in response to this request. If all of the criteria are met and a fresh copy of the requested page is found in cache, PipeBoost inserts an X-Pb-CacheValid header field into the request with a value of 1 and an X-Pb-CacheDate field that contains the date and time when the page was cached.

The X-Pb-CacheValid header field signals to the target script or application that PipeBoost has a valid fresh cached copy of this page and is ready to send it out, so the application has only to examine the X-Pb-CacheValid field and, optionally, the X-Pb-CacheDate field, and make a decision whether to use the cached copy or not. If it decides to use it, it should populate all other necessary response header fields and end the response. PipeBoost will do the rest. If the script decides to generate a new page, it simply sets the X-Pb-SendCache response header field to 0 and keeps going.

The conditions involved in the decision process are entirely up to the web developer. It could be a refresh flag stored in the Application object, for example, or a date value compared to the cache date, or even as simple as no condition at all.

There are, of course, some drawbacks to using this method. The code of a script or application has to be changed to use the system, although it can be as simple as a 3-line paste into an ASP script. The script or application still has to execute and signal to PipeBoost, even when no conditions are necessary. The application has to supply all the necessary response header fields (except Expires and Content-Type) every time.

Security Considerations:

Please see the Security Considerations section in Query-strings and Cookies caching. The same applies to this topic, as cache pre-validation system is meant to be used with multi-copy caching.

Limitations:

The validated cache of a page is not compatible with non-validated cache of the same page if the target ISAPI application uses URL reformatting or forwarding. The pre-validation system processes the URL before an application gets a chance to alter the URL, so cached copies of the same page will be stored in different places for different caching systems.