Chapter 2: Managing Content Policy Language
35
Some conditions cannot be evaluated during the first stage; for example, the user and group
information will not be known until stage two. Likewise, the response headers and MIME type are
unavailable for testing until stage three. For conditions, this is known as the earliest available time.
Policy decisions can have similar timing considerations, but this is known as the latest commit time. In
this example, the requirement to authenticate must be known at stage one, and a forwarding host or
gateway must be determined by stage three.
Cache Transactions
Cache transactions are initiated by the ProxySG in order to load or maintain content in the local object
store during adaptive refresh or pipelining, or as a result of a content distribute CLI command.
These may be HTTP, FTP, or streaming media transactions. Since no specific user is associated with
these transactions, content related policy is evaluated for cache transactions, but user related policy is
not evaluated.
A cache transaction evaluates policy in <Cache> and <Forward> layers. The <Forward> layers are only
evaluated if an origin server must be contacted to complete the transaction.
The following is a list of cache transactions:
•A content distribute transaction that is initiated by the content distribute CLI command. A
content distribute transaction may use one of the following protocols: HTTP, HTTPS, Real Media,
or Windows Media. This type of transaction may be preceded by a separate Administrator
transaction, since the administrator must be authenticated and authorized to use the command.
•Pipeline transactions (HTTP only).
•Advertisement transactions (HTTP only).
•If-modified-since transactions (HTTP only).
•Refresh transactions (HTTP only).
•ICP transactions.
Cache transactions have no client identity since they are generated internally by the ProxySG, and
they do not support authentication or authorization. Therefore, they do not support conditions such as
client.address= and group=, or the authenticate() property.
Windows Media HTTP
streaming transactions
Before the authentication challenge.
After the authentication challenge, but before the requested object is fetched.
Before making an upstream connection, if necessary. (Up to this point it is
similar to an HTTP transaction.)
What happens at this stage depends on negotiations with the origin server:
• After the origin server is contacted, if the User Agent header denotes the
Windows Media player and the server supports Microsoft streaming HTTP
extensions, it finishes like an MMS transaction: Object information is
available at this stage but streaming has not begun.
• If the User-Agent header is not a Windows Media player or the server does
not support Microsoft streaming extensions, it finishes like an HTTP
transaction: The requested object is fetched, and policy is evaluated
Table 2.1: When Policy is Evaluated (Continued)