iTP Secure WebServer System Administrators Guide (Version 7.5+)

from its own cache. Using tickets can reduce the problem considerably because each request can
have a unique ticket embedded in it. So even though many users might request the same Web
page, the presence of a unique ticket will make it appear to the proxy as though each request is
unique. For example, user X's request might be
http://www.acme.com/@@4RTgh67j8S23c5d3/info.html
whereas user Y's request is
http://www.acme.com/@@H9bF3f0Df36Gpp3Cd/info.html
The proxy, therefore, will successfully find a page in its cache only if the same user requests the
same page a second time. Note, however, that this method works only if the ticket is embedded
in the URL. By default, the content server does not insert tickets in URLs if cookies are enabled and
the Web client supports cookies.
If you want a true hit count, you can specify one policy for HTML pages (for which you want to
accurately track the hit count) and another policy for other types of references (for which you might
not want this information). (For more information, see “HTML and Image References” (page 178).)
Ticketing Strategies
Tickets can be attached to resource requests either as part of the URL or in a cookie. For example,
this URL contains a ticket:
http://www.acme.com/@@3jr7D&&j89WerfB6/index.htm
When the content server receives a request for a protected resource, it first looks in the request
URL to find the ticket. If a ticket is not present or the one that is present is invalid, the content server
checks the cookie, if the cookie is available. A cookie might be unavailable either because the
Web client does not support cookies or because the user has not yet received a ticket.
Only when the content server cannot acquire a valid ticket does it generate a new anonymous
ticket and insert it into the URL.
When the content server finds a valid ticket from the URL or cookie, the server attempts to keep
the ticket until the ticket expires. So, when the user makes subsequent requests, the content server
can validate the request by using the same ticket. The content server has three techniques for
maintaining tickets:
• Inserting the ticket in a URL directly
• Causing the Web client to insert the ticket in a URL
• Storing the ticket in a cookie
You can control the way the server stores tickets.
The ticket can only be inserted into a URL if it is a relative URL, as described in “Dynamically
Rewriting References” (page 178).
iTP Secure WebServer Default Ticketing Strategy
By default the iTP Secure WebServer inserts tickets into cookies whenever cookies are supported.
If the Web client does not support cookies, the server looks for the ticket in the URL. As long as the
initial document was referred to using a ticketed URL, the iTP Secure WebServer causes the Web
client to automatically insert the ticket in all subsequent relative URLs.
To guarantee that this action occurs for all HTML references, the content server converts absolute
HTML references into relative references. (Absolute and relative references are described in
“Dynamically Rewriting References” (page 178).) This strategy maximizes the lifetime of a ticket.
A side effect of this strategy is that log files might not show the true hit number for ticketed resources
because of proxies, as explained in “How Proxy Servers Affect Ticketing” (page 176).
Configuring for Anonymous Ticketing 177