The advertisement policy is defined as the following:
advertisement( )
Determines whether to treat the objects at a particular URL as banner ads to improve performance.
If the content is not specific to a particular user or client, then the hit count on the origin server is maintained while the response time is optimized using the following behavior:
- Always serve from the cache if a cached response is available. Ignore any request headers that bypass the cache; for example, Pragma: No-Cache.Always cache the response from the origin server, similar to force_cache(all).
- If the request was served from the cache, request the object from the origin server in the background to maintain the origin server's hit count on the ad and also allow ad services to deliver changing ads.
- A number of CPL properties affect caching behavior, as listed in the “See Also” section below.
Remember that any conflict between their settings is resolved by CPL evaluation logic, which uses the property value that was last set when evaluation ends.
Syntax
advertisement ( yes | no ) --- The default value is no.
Layer and Transaction Notes
Use in <Cache> layers.
Applies to HTTP transactions, except FTP over HTTP transactions.
If your ProxySG has following policy, the client sends the request to the object 2 times.
==================================
<cache>
advertisement(yes)
==================================
You can see the http transactions below.
=========================================================================
Packet capture trace sample
=========================================================================
No. Time Source Destination S.Port D.Port Protocol Info
1 0.88 [ Client IP ] [BlueCoatSG IP] 2750 8080 HTTP GET /object.jpg HTTP/1.1
2 1.20 [BlueCoatSG IP] [Web Server IP] 58712 80 HTTP GET /object.jpg HTTP/1.1
3 2.26 [Web Server IP] [BlueCoatSG IP] 80 58712 HTTP HTTP/1.1 200 OK
## HTTP response header HTTP/1.1 200 OK
Expires: Fri, 13 Aug 2010 00:55:16 GMT
4 2.26 [BlueCoatSG IP] [ Client IP ] 8080 2750 HTTP HTTP/1.1 200 OK
## HTTP response header HTTP/1.1 200 OK
Expires: Fri, 13 Aug 2010 00:55:16 GMT
5 3.79 [ Client IP ] [BlueCoatSG IP] 2750 8080 HTTP GET /object.jpg HTTP/1.1
6 3.80 [BlueCoatSG IP] [Web Server IP] 58712 80 HTTP GET /object.jpg HTTP/1.1
7 4.08 [BlueCoatSG IP] [ Client IP ] 8080 2750 HTTP HTTP/1.1 200 OK
## HTTP response header HTTP/1.1 200 OK
Expires: Sat, 13 Aug 2011 00:55:22 GMT <<----- SG added 1 year if it is cached object
8 4.35 [Web Server IP] [BlueCoatSG IP] 80 58712 HTTP HTTP/1.1 200 OK
## HTTP response header HTTP/1.1 200 OK
Expires: Fri, 13 Aug 2010 00:55:22 GMT
The first attempt to access the OCS object (Frame#1-4) is normal.
The second attempt (Frame#5-8) shows that the Client PC receives the http response from the ProxySG (Frame#7) before the response from OCS (Frame#8).
This is how the advertisement (yes) policy works. Note that the Expires date is increased by 1 year (Frame#7)
The objects cached by advertisement (yes) policy are marked as type_N internally by the ProxySG, meaning that it doesn't consider the expiration time or last-modified time as valid.
The reason we set the objects cached by the advertisement (yes) policy to expire date a year ahead is because we intend to treat these objects as fresh when a new request for them is made.
The definition of "Type N" content:
Content that has no caching information specified.
Type N content is the most difficult type of content to cache because it does not explicitly state or infer content type or freshness.
It is also difficult to determine if the content provider did not specify caching information because they do not want the content cached, or if it was an oversight.