To improve performance of your back-end network and servers by reducing their traffic and processing load, you can configure FortiWeb to cache responses from your servers.
Normally, FortiWeb forwards all allowed requests to your servers. This results in a 1:1 ratio of client-side to server-side traffic. When content caching is enabled, however, FortiWeb will forward only requests for content that:
- Does not exist in its cache, and
- Is cacheable (see What can be cached?)
When many requests are for cached content, the ratio of traffic changes to n:1.
Content caching provides the greatest benefit for things that rarely change, such as icons, background images, movies, PDFs, and static HTML.
|To configure the web caching, you must enable it by going to System > Config > Feature Visibility.|
When you create or edit an HTTP server policy in Policy > Server Policy and enable Web Cache, a web cache policy will be automatically created in Application Delivery > Caching. While if you delete the web cache enabled HTTP server policy, or disable Web Cache in the HTTP server policy, the related web cache policy will be removed automatically. The web cache policy includes no rules, and you need to configure the web cache rules for the policy.
To configure web content caching
- Go to Application Delivery > Caching.
- Click to select the web cache policy that you want to configure the rule for.
- Click Edit.
On Edit Web Cache Policy page, you can view the following information:
- The policy name that quotes the web cache policy;
- The statistics on the hit count in the last 24 hours;
- The web cache status: Caching and Clearing the cache; when it is Clearing the cache status, page content will not be cached until all cache data is successfully cleared; and the status will return to "Caching".
- Click Create New to configure web content caching rule.
When multiple web cache rules are defined in a web cache policy, and an HTTP request matches a specific web cache rule, FortiWeb will take actions according to the web cache rule settings.
- Configure these settings:
Enable to require that the
Host:field of the HTTP request match a protected host names entry in order to match the rule. Also configure Host.
Select which protected host names entry (either a web host name or IP address) that the
Host:field of the HTTP request must be in to match the policy.
This option is available only when Host Status is enabled.
Enter a path for your web pages, for example
/test, a prefix of a set of URLs.
Select whether to cache the response contents according to the HTTP method you use.
- GET, HEAD (Recommended)
- GET, HEAD, OPTIONS
- GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
Select whether to cache the response contents according to the response code.
- 200 (Recommended)
- 200, 206
- 200, 206, 301, 302
Cache File Type
Select whether to cache the response contents according to the content type.
Key Generation Factor
Select the protocol variable that you want to use to generate the cache key.
- Method, such as GET, POST, HEAD, etc.
- Protocol, the string can be either “http://” or “https://”;
- Arguments, for example in request
http://host.com/test.php?a=1&b=2, the Arguments string is
- Cookies—Once you have created a web cache rule, you can edit the rule to indicate cookies in HTTP requests and append them to the key string to generate the cache key.
Cache Inactive After
Specify a timeout threshold that the cache becomes invalid and needs to be refreshed. After the timeout, the cached web contents will be removed automatically.
Force Client Cache Refresh
Enable to clear the cache based on the specified period.
Client Cache Refresh After
Enter a period specified by max-age so that if the client requests the same contents again in the period, the client can obtain the web content from local cache directly.
- Click OK.
- In Bypass Sub URL, you can configure the URLs not to be cached.
Click Create New.
- Configure these settings.
Select the HTTP method in which the request URL is included.
Select whether the URL Expression field must contain either:
- Simple String—The field is a string that the request sub URLmust match exactly.
- Regular Expression—The field is a regular expression that defines a set of matching sub URLs.
Depending on your selection in URL Type, enter either:
Simple String—Enter a literal sub URL, such as
/expthat the HTTP request must contain in order to match the rule, or use wildcards to match multiple sub URLs, such as
/exp/*/index.htm. The sub URL must begin with a slash (
Regular Expression—A regular expression, such as
^/*.php, matching the sub URLs to which the rule should apply. The pattern does not require a slash (
/), but it must match sub URLs that begin with a slash, such as
To test a regular expression, click the >> (test) icon. This icon opens the Regular Expression Validator window from which you can fine-tune the expression. For details, see Regular expression syntax.
Enable this option and enter the argument name so that the request matches the bypass URL only when the request brings the specific arguments.
Enable this option and enter the cookie name so that the request matches the bypass URL only when the request brings the specific cookies.
- Click OK.
You can continue creating multiple bypass sub URL lists.