A pin list contains URL patterns for identifying objects on the Web. The Access Gateway uses the list to prepopulate the cache, before any requests have come in for the content. This accelerates user access to the content because it is retrieved from a local cache rather than from an exchange with the Web server, which would read it from disk.
You can use the pin list to specify the following:
Which objects you want to cache
Which objects you never want cached
The pin list is global to the Access Gateway and affects all protected resources. The objects remain in cache until their normal cache limits are reached or they are bumped out by more recently requested objects.
To configure a pin list:
In the Administration Console, click Devices > Access Gateways > Edit > Pin List.
Select the Enable Pin List option to enable the use of pinned objects. If this option is not selected, the pinned objects in the pin list are not used.
In the Pin List section, click New.
Fill in the following fields.
URL Mask: Specifies the URL pattern to match. For more information, see URL Mask.
Pin Type: Specifies how the URL is to be used to cache objects. Select from Normal and Bypass. For more information, see Pin Type.
To save the list item, click OK.
To save your changes to browser cache, click OK.
To apply the changes, click the Access Gateways link, then click Update > OK.
The URL mask can contain complete or partial URL patterns. A single URL mask might apply to a large set of URLs, or it might be so specific that only a single file on the Web matches it.
The Access Gateway processes the masks in the pin list in order of specificity. A mask containing a hostname is more specific than a mask that specifies only a file type. The action taken for an object is the action specified for the first mask that the object matches.
The Access Gateways recognizes four levels of specificity, using the following format:
|
Level |
Examples |
|---|---|
|
hostname |
http://www.foo.gov/documents/picture.gif http://www.foo.gov/documents/* http://www.foo.gov foo.gov/documents/* foo.gov/* All of these are classified as hostnames, and they are ordered by specificity. The first item in the list is considered the most specific and is processed first. The last item is the most general and is processed last. |
|
path |
/documents/picture.gif /documents/pictures.gif/* /documents/* Path entries are processed after hostnames. A leading forward slash must always be used when specifying a path, and the entry that follows must always reference the root directory of the Web server. In these examples, documents is the root directory. The /* at the end of the path indicates that the entry is a directory. Its absence indicates that the entry is a file. In these examples, picture.gif is a file and pictures.gif/* and documents/* are directories. If you enter a path without the trailing *, the path matches only the directory. With the trailing *, the path matches everything in the directory and its subdirectories. These path entry examples are ordered by specificity. The objects in the /documents/picture.gifdirectory are processed before the objects in the /documents directory. |
|
filename |
/picture.gif /widget.js /widget.jp*g /picture*group.gif /DailyTask /DailyTask* Filenames are processed after paths. A leading forward slash must always be used when specifying a filename. You can add asterisks in the file names. |
|
file extension |
/*.gif /*.js /*.htm File extensions are processed last. They consist of a leading forward slash, an asterisk, a period, and a file extension. |
NOTE:More than one wildcard is not allowed in a URL mask. For example, /*picture.g*f is not correct.
Also, the wildcard must be only in the last part of the path. For example:
Correct: /picture/*.gif
Incorrect: /documents/*/picture.gif
Specific rules have precedence over less specific rules. Thus, objects matched by a more specific rule are always processed according to its conditions. If a less specific rule also matches the object, the less specific rule is ignored for the object. For example, assume the following two entries are in the pin list:
|
URL Mask |
Pin Type |
Pin Links |
|---|---|---|
http://www.foo.gov/documents/* |
normal |
1 |
www.foo* |
bypass |
N/A |
The first entry, because it is most specific, caches the pages in the documents directory and follows any links on those pages and caches the linked pages. The second entry does not affect what the first entry caches, but it prevents any other domain extensions such as .com,.net, or .org whose DNS names begin with www.foo from being cached.
The pin type specifies how the Access Gateway caches objects that match the URL mask.
Normal: The Access Gateway handles objects matching the mask in the same way it handles any other requested objects. In other words, the objects are cached but not pinned.
Administrators often use this pin type in combination with a broad URL mask that has a bypass pin type. This allows them to insulate specific objects from the effects of the bypass rule.
For example, you could specify a URL mask of /*.jpg with a pin type of bypass and a second URL mask of www.foo.gov/graphics/* with a pin type of normal. This causes all files, including .jpg files, in the graphics directory on the foo.gov Web site to be cached as requested. Assuming there are no other URL masks in the pin list, all other JPG graphics are not cached because of the /*.jpg mask.
Bypass: The Access Gateway does not cache the objects. In other words, you can use this option to prevent objects from being cached.