To configure a single OracleAS Web Cache server as a software load balancer:
1. Download an Automated Release Update (ARU) for bug 4569559.
You can download ARUs from OracleMetalink:
http://metalink.oracle.com
2. Follow the instructions provided in the Readme for the patch.
3. Create a backup copy of the internal.xml file. This file is located in the $ORACLE_HOME/webcache directory on UNIX and ORACLE_HOME\webcache directory on Windows.
4. Use a text editor to open the internal.xml file.
5. Locate the CALYPSOINTERNALPARAMS element.
...
...
6. Add the LOADBALANCE subelement directly after the OEMPERFTOOL subelement as follows:
...
...
7. Save internal.xml.
8. Restart OracleAS Web Cache with the following command:
opmnctl restartproc ias-component=WebCache
9. Verify OracleAS Web Cache is running in the load balancer mode from the OracleAS Web Cache Manager by verifying the following status message displays beneath the Apply Changes and Cancel Changes buttons:
Web Cache running in Load Balancer Mode with current configuration
Application Server Control Console does not provide an equivalent verification status.
10. Ensure the auto-restart mechanism is enabled, as described in "Task 3: Configure Auto-Restart Settings".
11. Configure origin servers, as described in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings".
12. Create site definitions and map them to the origin servers, as described in "Task 10: Configure Web Site Settings".
13. If your application deployment requires session stickiness, enable session binding. See "Bind a Session to an Origin Server".
Applications using OracleAS Single Sign-On and Oracle Delegated Administration Services, for example, require session binding.
If the application that requires session stickiness is an OC4J application, then configure session binding using the JSESSIONID cookie.
Consider the topology depicted in Figure 8-5.
Figure 8-5 Deploying OracleAS Web Cache as a Load Balancer
Description of "Figure 8-5 Deploying OracleAS Web Cache as a Load Balancer"
To configure this topology:
1. Register the IP address of the OracleAS Web Cache server webche-host with www.app1.company.com.
2. Configure the OracleAS Web Cache server with the following:
a. Receive HTTP and HTTPS requests on designated listening ports.
b. Send HTTP and HTTPS requests to application Web servers app1-host1 and app1-host2 on designated listening ports.
c. Map virtual host site definition for www.app1.company.com mapped to app1-host1 and app1-host2.
Task 3: Configure Auto-Restart Settings
OracleAS Web Cache provides an auto-restart mechanism that checks that the cache server process is running and automatically restarts the cache server process if it is not running.
If auto-restart is enabled, the auto-restart mechanism restarts the cache server if it stops. By default, auto-restart is enabled.
Note:
If you installed OracleAS Web Cache as part of an Oracle Application Server installation, the auto-restart mechanism is run by Oracle Process Manager and Notification (OPMN) Server. If you installed OracleAS Web Cache from a kit that included only this product, the auto-restart mechanism is run by the OracleAS Web Cache monitor.
To change the auto-restart settings in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Web Cache > Auto-Restart.
See Also:
"Modifying Auto-Restart Settings" in Enterprise Manager Online Help for instructions
To specify the settings for auto-restart in OracleAS Web Cache Manager:
1. In the navigator frame, select Properties > Auto-Restart.
The Auto-Restart page appears.
2. To change the default settings, click Edit.
The Edit Auto-Restart dialog box is displayed.
3. If auto-restart is not enabled, in the Enabled field, select Yes.
4. You can specify that the auto-restart mechanism polls (pings) the OracleAS Web Cache cache server at specified intervals. It does this by sending requests to a specified URL. If it cannot connect to the cache server or if the cache server does not respond within a specified time, the auto-restart mechanism restarts the cache server process.
Note that the auto-restart mechanism will restart the cache server if it has failed, whether or not you enable pinging. However, if you enable pinging, the auto-restart mechanism will attempt to restart the cache if it receives network errors in response to its ping attempts.
If you do not want the auto-start mechanism to actively ping the cache server, disable pinging by selecting No in the Pinging Enabled field.
To enable pinging:
a. In the Pinging Enabled field, select Yes.
b. In the Failover Threshold field, enter the number of consecutive failed requests before the auto-restart mechanism considers the cache server to have failed. Only network errors, including timeout errors, are counted as failed requests.
The default is three failures.
For each failed request, OracleAS Web Cache increments the failure counter. When a request is successfully processed by the cache server, OracleAS Web Cache resets the failure counter.
When the failover threshold is met, the auto-restart mechanism starts the cache server.
Note:
The threshold applies only to network errors and timeouts. If the cache server process is not running, the auto-restart mechanism immediately restarts the cache server.
c. In the Ping URL field, enter the URL that the auto-restart mechanism will use to poll the cache server.
You must use a URL that is cacheable and is guaranteed to be stored in the cache. The default is /_oracle_http_server_webcache_static_.html, which is stored in the cache. If your environment uses a hardware load balancer with pinging capability, then configure the load balancer with this ping URL to ping each OracleAS Web Cache server on a periodic basis.
d. In the Ping Interval field, enter the time, in seconds, between attempts by the auto-restart mechanism to poll the cache server.
The default value is 15 seconds.
e. In the Ping Timeout field, enter the time, in seconds, that the auto-restart mechanism will wait for a response from the cache server.
The default value is 30 seconds.
5. Click Submit.
Task 9: Configure Origin Server, Load Balancing, and Failover Settings
Configure OracleAS Web Cache with the application Web servers or proxy servers to which it sends cache misses. Typically, OracleAS Web Cache uses application Web servers for internal sites and proxy servers for external sites outside a firewall.
By default, the listening port and host name of the Oracle HTTP Server are configured. When OracleAS Web Cache is installed, Oracle HTTP Server has a default listening HTTP port of 7778 during the first installation sequence.
OracleAS Web Cache only forwards requests to a configured origin server if the server is mapped to a Web site. If you are configuring load balancing for a site, then create one site-to-server mapping that maps all the applicable origin servers to the site.
See Also:
● "Stateless Load Balancing" for an overview of load balancing
● "Task 10: Configure Web Site Settings" for instructions on configuring site-to-server mappings
To configure OracleAS Web Cache with origin server information from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Origin Servers.
See Also:
"Configuring Origin Servers" in Enterprise Manager Online Help for instructions
To configure OracleAS Web Cache with origin server information from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Origin Servers.
The Origin Servers page appears.
2. Click Add in the Application Web Servers or Proxy Servers section.
The Add Application Web Server or Proxy Server dialog box appears.
3. In the Hostname field, enter the host name of the origin server.
4. In the Port field, enter the listening port from which the origin server will receive OracleAS Web Cache requests.
Note:
OracleAS Web Cache must listen on the same port as the application Web server being proxied. When configuring proxy servers, ensure there is a corresponding listening port for every port that will need to be proxied.
5. In the Routing field, select ENABLED to permit OracleAS Web Cache to route requests to the origin server or DISABLED to only serve requests from cache.
Oracle recommends selecting DISABLED if temporary maintenance of an origin server is needed.
OracleAS Web Cache tries to route a request matching a particular site to all origin servers mapped to that site. If all of the origin servers have a routing of DISABLED, OracleAS Web Cache serves a network error page to clients.
See Also:
"Configure Error Pages"
6. In the Capacity field, enter the maximum number of concurrent connections that the origin server can accept.
You determine this number by load testing the origin server until it runs out of CPU, responds slowly, or until a backend database reaches full capacity.
In a cache cluster, OracleAS Web Cache ensures that the total number of connections from all cluster members to the origin server does not exceed the capacity. Each cluster member is allowed a percentage of the maximum connections, using the following formula:
connections_from_each_cluster_member = capacity / number_of_cluster_members
7. In the Failover Threshold field, enter the number of allowed continuous read/write failures with an origin server on established connections.
The default is five request/response failures.
If any connection failure occurs, OracleAS Web Cache immediately considers an origin server down.
When the threshold is met, OracleAS Web Cache considers the origin server down and performs automatic failover of the origin servers. If an origin server fails at any time after OracleAS Web Cache has started to send a request, then OracleAS Web Cache increments the failure counter. The failure counter is reset in the event of a successful server response. A request is considered failed if:
● There are any network errors other than connection failure errors.
● The HTTP response status code is less than 100, or is one of the following messages: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout.
After the threshold is met, OracleAS Web Cache considers the server down and uses other servers for future requests. OracleAS Web Cache starts polling the down server, by sending requests to the URL specified in the Ping URL field. When OracleAS Web Cache receives a successful response from the server without any network errors and the HTTP response code is not less than 100, or not equal to 500, 502, 503, 504, OracleAS Web Cache considers the server up again and uses it for future requests.
Note:
● The threshold does not apply if OracleAS Web Cache cannot connect to an origin server. In this case, OracleAS Web Cache immediately considers the server down and does not use it for future requests. If there are other origin servers, OracleAS Web Cache retries the request to another origin server. If there no servers configured, OracleAS Web Cache returns an error.
● The failover to another origin server does not apply if there is only one origin server left.
8. In the Ping URL field, enter the URL that OracleAS Web Cache will use to poll an origin server that has reached its failover threshold:
● For an application Web Server, enter either a relative or a fully-qualified URL that includes the domain name, or site name, representing the virtual host of the application Web server.
● For a proxy server, enter a fully-qualified URL that includes the domain name, or site name, representing the virtual host of the origin server behind the proxy server.
Rather than using a static URL, Oracle recommends using a URL that checks the health of the application logic on the origin server and returns the appropriate HTTP 200 or 500 status codes. The default is "/".
9. In the Ping Interval (seconds) field, enter the time, in seconds, that OracleAS Web Cache will poll an origin server that has reached its failover threshold.
The default is 10 seconds.
10. From the Protocol list, select either HTTP to send HTTP requests on the port or HTTPS to send HTTPS requests on the port.
See Also:
"Secure Sockets Layer (SSL)"
11. Click Submit.
12. If you selected HTTPS as the listening protocol, specify the location of the wallet for OracleAS Web Cache communication to the origin server (Origin Servers, Sites, and Load Balancing > Origin Server Wallet).
See Also:
"Task 4: Configure HTTPS Port and Wallet Location for the Origin Server" for information about configuring the wallet
Task 10: Configure Web Site Settings
For OracleAS Web Cache to act as a virtual server for one or more Web sites, configure OracleAS Web Cache with information about the Web site. To configure settings for a Web site, perform the following tasks:
● Creating Site Definitions
● Configure Error Pages
● Bind a Session to an Origin Server
Creating Site Definitions
The installation process creates a default site definition that uses the host name and listening port of the computer on which Oracle HTTP Server was installed. OracleAS Web Cache forwards requests without host information to this site.
You need to create site definition for any named sites. A site definition consists of a host name, port information, and optional URL path prefix about the site and its aliases. Alias information is essential, because many sites are represented by one or more aliases. OracleAS Web Cache recognizes and caches requests for a site and its aliases. For example, site www.company.com:80 may have an alias of company.com:80. By specifying this alias, OracleAS Web Cache caches the same content from either company.com:80 or www.company.com:80. If a request includes a site alias that is not configured, OracleAS Web Cache sends the request to the default site.
The following sections show examples of site definitions and explain how to configure new site definitions:
● Default Site Example
● Virtual Host Site Examples
● ESI Provider Site Example
● Creating New Site Definitions
Default Site Example
For those requests that do not include a Host request-header field, OracleAS Web Cache sends the request to the default site. The default site, established during installation, uses the host name and listening port of the computer on which Oracle HTTP Server was installed. Figure 8-1 shows an example of a default site definition from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The rules for the default site are as follows:
● The site definition in the Named Sites Definitions section maps HTTP requests to the origin server host-server:7778. If you select to edit this definition, you can view the ESI content policy from the Advanced tab. The ESI content policy is set to Unrestricted, which instructs OracleAS Web Cache to serve site content, as well as assemble ESI include fragments.
● The first mapping *.80 in the Server Mapping for Unnamed Site uses a * wildcard host name to map all other virtual site names to the origin server. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from any sites other than the sites specified in the first rule.
● The second mapping *.* in the Server Mapping for Unnamed Site uses a * wildcard host name to map all other virtual site names to the origin server and a * wildcard port number to map the site name to multiple port numbers. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from any sites other than the sites specified in the first two rules.
Figure 8-1 Default Site Definitions
Description of "Figure 8-1 Default Site Definitions"
Note:
If you modify the name of the default site, you must also modify the ServerName directive in the httpd.conf file. See "Task 7: Provide Directives to Oracle HTTP Server".
Virtual Host Site Examples
Figure 8-2 shows how you would configure a virtual host site named www.company.com:80 without ESI content from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The site definition in the Named Sites Definitions section maps HTTP requests to site www.company.com:80 and and site alias company.com:80 to origin server host-server:7778. The ESI content policy is set to Exclude Fragments, which restricts OracleAS Web Cache from fetching ESI content from host-server:7778 for this site.
Figure 8-2 Example: Site Settings for a Virtual Host Site
Description of "Figure 8-2 Example: Site Settings for a Virtual Host Site"
Figure 8-3 shows how you would configure a virtual host site named www.1st.company.com:80 and www.2nd.company.com with ESI content from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The rules are as follows:
● The site definitions in the Named Sites Definitions section map HTTP requests to sites www.1st.company.com:80 and www.2nd.company.com:80 and respective aliases 1st.company.com and 2nd.company.com to origin server host-server:7778. The ESI content policy is set to Unrestricted, which enables OracleAS Web Cache to serve site content, as well as assemble ESI include fragments.
● The mapping www.*.company.com:80 in the Server Mapping for Unnamed Site uses a * wildcard host name to map sites matching www.*.company.com to origin server host-server:7778. The ESI content policy is set to Unrestricted.
Figure 8-3 Example: Site Settings for Multiple Virtual Host Sites
Description of "Figure 8-3 Example: Site Settings for Multiple Virtual Host Sites"
ESI Provider Site Example
Figure 8-4 shows how you would configure ESI provider sites named www.providersite1.com:80 and www.providersite2.com from the Sites page of Application Server Control Console (Web Cache Home page > Administration tab > Properties > Application > Sites).
The site definitions in the Named Sites Definitions section specify how to map HTTP requests to sites www.providersite1.com:80 and www.providersite2.com:80 and respective aliases providersite1.com and providersite2.com. Requests to www.providersite1.com map to proxy-host:80. There is no origin server specified for www.providersite2.com, because the proxy server is not known. Instead, DNS will be used to resolve the site name to the appropriate server. The ESI content policy is set to Fragments Only, which restricts OracleAS Web Cache from using this mapping for any content that is not ESI.
Figure 8-4 Example: Site Settings for Multiple ESI Provider Sites
Description of "Figure 8-4 Example: Site Settings for Multiple ESI Provider Sites"
Creating New Site Definitions
If the default site definition is not adequate for your configuration, create additional site definitions.
To create new site definitions from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Site Properties for a Named Site" or "Configuring Site Properties for an Unnamed Site" in Enterprise Manager Online Help for instructions
Using OracleAS Web Cache Manager, you can either discover site and alias information from Oracle HTTP Server, or you can manually create definitions. Oracle recommends using the site discovery feature to initially create the necessary definitions. After discovery is complete, you can manually create additional site definitions. Application Server Control Console does not support site discovery.
See Also:
Help for the Site Definitions page in OracleAS Web Cache Manager Online Help for instructions on using the site discovery feature
To create new site definitions from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site Definitions.
The Site Definitions page appears.
Note:
● It may not be possible to specify a site definition for an external ESI provider site. If an ESI request is made to a provider that does not match any application Web server mapping, then OracleAS Web Cache uses Domain Name System (DNS) to resolve the site name. Note that this will not work if there is a firewall between the cache and the ESI provider. In that case, you must provide a proxy server mapping that directs the request to the appropriate proxy.
● Undefined ESI provider sites disable the following OracleAS Web Cache features:
— Performance assurance heuristics
— Origin server features, such as surge protection, load balancing, failover, and session binding
● It is not possible to configure only ESI provider sites. In a configuration with ESI provider sites, at least one virtual host site definition must exist for ESI template pages.
2. Specify the site information:
a. In the Site Definitions page, click Add Site.
The Add Site dialog box appears.
b. In the Host Name field, enter the site host name, for example, www.company.com. To enable OracleAS Web Cache to match requests to this site, do not add protocol information (http:// or https://) to the host name.
Note:
Do not use the wildcard * in the Host Name field to represent multiple sites.
c. Optionally, in the URL Path Prefix field, enter the path prefix of the URLs to distinguish this site from another site that shares the same host name. Ensure the prefix starts with "/" to distinguish from another site that shares the same host name. Do not include the file name or embedded URL parameters in the prefix.
The prefix is excluded in matching requests to the site.
For example, the following URLs share the same site name, but belong to two entirely differently applications hosted on entirely different origin servers:
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox
While the first URL shows an email user a front page after login, the second URL displays an inbox. If the site host name is defined as www.company.com, then you specify the prefixes as /portal and /um to distinguish the sites. Requests are matched for www.company.com, not www.company.com/portal and www.company.com/um.
d. In the Port Number field, enter the port number from which the Web site is listening for incoming HTTP requests.
The port number should be the port used in client requests.
In a configuration in which the OracleAS Web Cache listen port is the same as the logical site port, changing the OracleAS Web Cache listen port requires you to also change the logical site port in both the Site Definitions and Site-to-Server Mapping pages.
e. In the HTTPS Only Prefix field, enter the URL prefix for which only HTTPS requests will be served. If you must restrict all traffic to HTTPS, enter "/ " for the entire site.
f. In the URL Parameter to Ignore field, specify site-specific embedded URL or POST body parameters to ignore.
By configuring OracleAS Web Cache to ignore the value of embedded URL or POST body parameters, you enable OracleAS Web Cache to serve one cached object to multiple sessions requesting the same page. OracleAS Web Cache caches the response to the first request and serves subsequent requests for the page from its cache.
If you prefer instead to set a global parameter to apply to all sites, click Global URL Parameters to Ignore from the main Site Definitions page.
See Also:
● Excluding the Value of Embedded URL or POST Body Parameters for an overview and an example scenario
● Configuring OracleAS Web Cache to Exclude the Value of Embedded URL or POST Body Parameters for instructions on setting global parameters
g. In the Client-Side Certificate field, select Required or Not Required to specify that OracleAS Web Cache require or not require client-side certificates from client browsers.
A client-side certificate is a method for verifying the identity of the client. It binds information about the client user to the user's public key and must be digitally signed by a trusted CA.
h. In the Default Site field, select Yes to specify the site as the default site, or select No to specify this site as a nondefault site.
If you select Yes for a site, another site that previously had the Yes setting will change to No.
If the default site includes a URL path prefix, the prefix is excluded in matching requests to the site. For example, if you specify a default site of www.company.com and a URL path prefix of /portal, requests are matched for www.company.com, not www.company.com/portal.
See Also:
"Default Site Example" for information about how the default site is used
i. In the Create Alias from Site Name with/without www field, select either Yes or No.
● Select Yes to use the site name as a site alias.
For example, if the site domain name is company.com, a site alias of www.company.com will be used. If the site domain name is www.company.com, a site alias of company.com will be used.
● Select No if you do not want to use the site name as a site alias.
3. If the site uses additional aliases, map the site to those aliases.
Important:
To ensure requests are directed to the correct site, specify all possible variations of the site name. If a request includes a site alias that is not configured, OracleAS Web Cache sends the request to the default site.
a. In the Site Definitions page, select a site, and then click Add Alias.
The Add Alias for Site dialog box appears.
b. In the Host Name field, enter the site alias name, such as company.com.
Note:
Do not use the wildcard * in the Host Name field to represent multiple aliases.
c. In the Port Number field, enter the HTTP or HTTPS port number from which the alias is listening for incoming HTTP requests.
The port number should be the port used in client requests.
4. Click Submit.
To map sites to origin servers from Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Site Properties for a Named Site" in Enterprise Manager Online Help for instructions
To map sites to origin servers from OracleAS Web Cache Manager, take the following steps:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Site-to-Server Mapping.
The Site-to-Server Mapping page appears.
2. Click Create if no mappings exist. If mappings already exist, select a mapping, and then click Insert Above or Insert Below.
The Create Site-to-Server Mapping or Edit/Add Site-to-Server Mapping dialog box appears.
3. In the Edit Site Name section, select one of the following options:
● Enter Site Name to enter the site name, such as www.company.com or *.company.com, as well as the HTTP or HTTPS port number from which the site is listening for incoming requests.
● Select from Site definitions to select a site definition created in the Site Definitions page.
Note:
You can use the wildcard * in the Host Name field in the following ways:
● Map multiple site names to one or more application Web server or proxy servers. For example, *.company.com can be used to match sites site1.company.com and site2.company.com.
● Route cache misses to undefined ESI provider sites outside a firewall and accessible by a proxy server. For example, * can be used to map to proxy server proxy-host.
You can use the wildcard * in the Port Number field to map the same site name with different port numbers to the same origin servers. If the origin servers are proxy servers, ensure they were configured to listen on the same port as the application Web server being proxied, as described in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings".
This option does not enable you to create a site definition. You must create a site definition in the Site Definitions page.
4. In the Select either application Web servers or proxy servers to which this Site is mapped, select one of the following options:
● Select Application Web Servers to select application Web servers specified in the Origin Servers page
● Select Proxy Servers to select proxy servers specified in the Origin Servers page
Note:
If you configured multiple origin servers in "Task 9: Configure Origin Server, Load Balancing, and Failover Settings" for load balancing, then create one site-to-server mapping that maps all the applicable origin servers to the site. In that site-to-server mapping, select all the origin servers that apply for the site. If you split the origin servers among multiple site-to-server mappings, load balancing for the site will not occur in the intended manner.
5. In the Exclude section, select one of the following options to restrict OracleAS Web Cache access to the origin servers for the sites specified in Edit Site Name.
● Exclude Fragments restricts OracleAS Web Cache from using this mapping for ESI fragments. Select this option if the site is a virtual host site that does not provide ESI content.
● Fragments Only restricts OracleAS Web Cache from using this mapping for any content that is not an ESI fragment. Select this option if the site is an ESI provider site.
● Unrestricted does not enforce any OracleAS Web Cache restrictions. Select this option if the site is a virtual host site that supports ESI.
For example, one mapping entry that uses Exclude Fragments does not mean that OracleAS Web Cache is not allowed to assemble ESI content from other origin servers.
6. Click Submit.
7. After you create the mappings, order them. For each request, the first matching mapping is used.
In the Site-to-Server Mapping page, select a mapping, and then click Move Up or Move Down to order the mappings. Note the following:
● Because mappings that use the wildcard * encompass a broader scope, give these mappings a lower priority than other mappings.
● Because requests are resolved to the first matching mapping, give mappings that contain the optional URL path prefix a higher priority than those mappings without an URL path prefix.
For example, you should order the following mappings as follows:
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox
http://www.company.com
If you instead reorder the mappings as follows, the request for URLs http://www.company.com/portal/page?_pageid=33,4232&_dad=portal and http://www.company.com/um/traffic_cop?mailid=inbox will never be reached. Requests for these URLs will instead resolve to http://www.company.com because it is listed first:
http://www.company.com
http://www.company.com/portal/page?_pageid=33,4232&_dad=portal
http://www.company.com/um/traffic_cop?mailid=inbox
Note:
If the protocol used in the src attribute of an
tag attribute does not match the protocol specified in the Site-to-Server Mapping page, then OracleAS Web Cache uses the protocol configured for the origin server in the Site-to-Server Mapping page. OracleAS Web Cache also reports the following warning message to the event log:
ESI include fragment protocol does not match origin server protocol: Origin Server Protocol=protocol URL=URL
For example, if the template page is configured with and the Site-to-Server Mapping specifies HTTP for the origin server, then http://www.company.com/gifs/frag1.gif is used and the following message appears in the event log:
[25/Jul/2005:19:30:48 +0000] [warning 11250] [ecid: -] ESI include fragment protocol does not match origin server protocol: Origin Server Protocol=http URL=https://www.company.com/gifs/frag1.gif
Configure Error Pages
For configured sites, specify error pages to be served from OracleAS Web Cache for network communication errors, site busy errors, and ESI errors:
1. Create error pages and place them in the $ORACLE_HOME/webcache/files directory on UNIX and the ORACLE_HOME\webcache\files directory on Windows. The default settings are as follows:
● For network errors, the default setting is set to network_error.html. This error page is served when there is a network problem while connecting, sending, or receiving a response from an origin server for a cache-miss request.
● For site busy errors, the default setting is set to busy_error.html. This page is served when origin server capacity is reached.
● For ESI default fragments, the default setting is set to esi_fragment_error.txt. This page is served when OracleAS Web Cache is unable to fetch the src specified in an tag and the alt attribute, onerror attribute, or the try |attempt |except block are either not present or fail.
See Also:
"Exceptions and Errors"
For a production environment, modify the defaults or create entirely new error pages to be consistent with other error pages for the site.
2. Configure OracleAS Web Cache with the error pages.
You can modify the settings for error pages in one of two ways:
● Change the default settings, and apply it to all defined sites.
● Modify the error page settings for a specific site.
From Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Default Error Pages" in Enterprise Manager Online Help for instructions on configuring error pages
From OracleAS Web Cache Manager, perform these steps to configure error pages:
● In the navigator frame, select Origin Servers, Sites, and Load Balancing > Error Pages.
The Error Pages page appears.
● Select either Default Pages or a site name in the table, and then click Edit.
The Edit Error Pages dialog box appears.
● In the Network Error Page field, enter the file name of the error page that will be delivered for network communication problems between OracleAS Web Cache and the Web site.
If you are using the default network_error.html page, leave the field as is.
● In the Site Busy Page field, enter the file name of the error page that will be delivered when a Web site is saturated with requests.
If you are using the default busy_error.html page, leave the field as is.
● In the ESI Default Fragment field, enter the file name of the page that will be delivered when OracleAS Web Cache is unable to retrieve an HTML fragment for an tag.
If you are not using tags for partial page caching or you want to use only ESI language elements for exceptions, do not enter a value.
● Click Submit.
If you selected Default Pages in Step b, the new settings will be applied to all defined sites with the default page setting. However, the new setting will not be applied to undefined sites. If you selected a specific site in Step b, the new settings will be applied to just to the site.
See Also:
"Exceptions and Errors" to understand how exceptions and error are handled for errors
Bind a Session to an Origin Server
Notes:
● When a session cookie expires, OracleAS Web Cache does not continue to bind the user session to the origin server. Instead, OracleAS Web Cache uses load balancing to choose an origin server. To avoid pages being served past the client session expiration time, ensure that the session cookie expires before the origin server expires the client session.
● If an origin server is busy, OracleAS Web Cache disables session binding to that origin server.
You can configure OracleAS Web Cache to support session binding, whereby a user session for a particular site is bound to an origin server in order to maintain state for a period of time. To utilize this feature, the origin server itself must maintain state; that is, it must be stateful.
If a request is forwarded to an origin server for an object requiring session binding, the origin server creates the user session by including the session information to clients through OracleAS Web Cache in the form of a session cookie or an embedded URL parameter. OracleAS Web Cache does not process the value of the parameter or cookie; it simply passes the information back to the client browser. When a client includes the session information in a subsequent request, OracleAS Web Cache forwards the request to the origin server that originally created the user session. OracleAS Web Cache binds the user session to that particular origin server.
If you have configured a cache cluster, you must enable tracking of session bindings through the use of a cookie that tracks session information so that it can be read by all cluster members. OracleAS Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.
See Also::
● "Session Binding(Stateful Load Balancing)" for an overview of origin server binding
● "Task 3: Enable Tracking of Session Binding" for instructions on enabling session tracking in a cluster
By default, session binding is not enabled for any sites. If there is no session binding specified for a site, then the default session binding setting is applied, which uses the Default Session Binding rule. The Default Session Binding rule has a default value of Disable Session Binding. You can enable session binding in one of two ways:
● Change the default value of the Default Session Binding rule from Disable Session Binding to a specific session and binding mechanism. OracleAS Web Cache applies these settings to all sites that use the Default Session Binding rule. If you decide to change the value of the Default Session Binding rule, ensure all named sites currently configured with this rule require session binding. If some sites do not require session binding, leave the value of Disable Session Binding, and instead specify session binding settings for the site. Use the next option.
● Overwrite the default session binding setting to some other session for a specific site.
To enable session binding in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Session Binding Settings" in Enterprise Manager Online Help for instructions
To enable session binding from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Session Binding.
The Session Binding page appears.
2. In the Session Binding page, select Default Session Binding or a specific site name in the table, and then click Edit Selected.
The Edit Session Binding dialog box appears.
3. From the Please select a session list:
● If you selected the Default Session Binding rule in Step 2, change the session value from Use Default Session Binding to another defined session, and then skip to Step 4.
● If you selected a specific site in Step 2, change the session value from Disable Session Binding to a defined session, and then skip to Step 3. Table 8-1 provides descriptions of the default session definitions provided at installation time.
If you want OracleAS Web Cache to bind user sessions with multiple cookies when any cookie is set, select a session of Any Set Cookie. When selecting Any Set Cookie, in Please select a session binding mechanism, select Cookie-Based to instruct OracleAS Web Cache to include a Set-Cookie response-header in the response.
If the sessions listed do not contain the definition you require, click Cancel to exit the Edit Session Binding dialog box. Continue to Step 4.
4. Create a session definition:
● In the navigator frame, select Rules for Caching, Personalization, and Compression > Session Definitions.
The Session Definitions page appears.
● From the For Site list, select the Web site for which you want to create site-specific site definitions.
● Click Add or Create.
The Edit/Add Session Definition dialog box appears.
● In the Session Name field, enter an easy-to-remember unique name.
● Enter the cookie name in the Cookie Name field and the embedded URL parameter in the URL or Post body parameter field.
If you enter both a cookie name and an embedded URL parameter, keep in mind that both must be used to support the same session. If they support different sessions, create separate session definitions. You can specify up to 20 session definitions for each page.
Note:
OracleAS Web Cache requires a session cookie to perform session binding. If client browsers do not support cookies and you want to use an embedded URL parameter for the session, then perform the following for OracleAS Web Cache to perform session binding on the session:
1. In addition to the URL Parameter field, specify a cookie name for the session in the Cookie Name field.
2. Ensure that the origin server returns a Set-Cookie response-header with the value of the session every time a session is created.
Set-Cookie: cookie=value
Set value to the same value as set in the URL Parameter field.
OracleAS Web Cache uses the Set-Cookie response header, even if ignored by browsers, to locate the session cookie value for session binding.
See Also: http://www.rfc-editor.org/ for further information about the Set-Cookie response header
● Click Submit.
● Repeat Steps 1 through 3.
5. From the Please select a session binding mechanism list, select one of the following mechanisms:
● Cookie-based: Select if the client supports cookies. OracleAS Web Cache uses its own cookie to track a session. This cookie, which contains routing information, is maintained between OracleAS Web Cache and the client browser.
● OC4J-based: Select if the application is based on OC4J. OracleAS Web Cache forwards routing information with each request to OC4J through Oracle HTTP Server.
● Internal-tracking: Select if the client does not support cookies and the application is not based on Oracle HTTP Server and OC4J. This option is intended for backward compatibility with earlier releases of OracleAS Web Cache. OracleAS Web Cache maintains an in-memory routing table, of which each entry maps a session ID to an origin server. The routing table is not shared among cluster nodes. If you select this option and you have a cache cluster configuration, then you must bind at the load balancer layer.
6. Click Submit.
If you selected the Default Session Binding rule in Step 2, the new settings will be applied to all defined sites with the default session binding setting. However, the new default will not be applied to undefined sites. If you selected a specific site in Step 2, the new settings will be applied to just the site.
Bind a Session to an Origin Server
Notes:
● When a session cookie expires, OracleAS Web Cache does not continue to bind the user session to the origin server. Instead, OracleAS Web Cache uses load balancing to choose an origin server. To avoid pages being served past the client session expiration time, ensure that the session cookie expires before the origin server expires the client session.
● If an origin server is busy, OracleAS Web Cache disables session binding to that origin server.
You can configure OracleAS Web Cache to support session binding, whereby a user session for a particular site is bound to an origin server in order to maintain state for a period of time. To utilize this feature, the origin server itself must maintain state; that is, it must be stateful.
If a request is forwarded to an origin server for an object requiring session binding, the origin server creates the user session by including the session information to clients through OracleAS Web Cache in the form of a session cookie or an embedded URL parameter. OracleAS Web Cache does not process the value of the parameter or cookie; it simply passes the information back to the client browser. When a client includes the session information in a subsequent request, OracleAS Web Cache forwards the request to the origin server that originally created the user session. OracleAS Web Cache binds the user session to that particular origin server.
If you have configured a cache cluster, you must enable tracking of session bindings through the use of a cookie that tracks session information so that it can be read by all cluster members. OracleAS Web Cache includes a Set-Cookie response-header in the response so that subsequent requests from the client include the cookie. The cookie provides information so that any of the cluster members can resolve the binding regardless of which cache handled the initial request.
See Also::
● "Session Binding(Stateful Load Balancing)" for an overview of origin server binding
● "Task 3: Enable Tracking of Session Binding" for instructions on enabling session tracking in a cluster
By default, session binding is not enabled for any sites. If there is no session binding specified for a site, then the default session binding setting is applied, which uses the Default Session Binding rule. The Default Session Binding rule has a default value of Disable Session Binding. You can enable session binding in one of two ways:
● Change the default value of the Default Session Binding rule from Disable Session Binding to a specific session and binding mechanism. OracleAS Web Cache applies these settings to all sites that use the Default Session Binding rule. If you decide to change the value of the Default Session Binding rule, ensure all named sites currently configured with this rule require session binding. If some sites do not require session binding, leave the value of Disable Session Binding, and instead specify session binding settings for the site. Use the next option.
● Overwrite the default session binding setting to some other session for a specific site.
To enable session binding in Application Server Control Console, navigate to Web Cache Home page > Administration tab > Properties > Application > Sites.
See Also:
"Configuring Session Binding Settings" in Enterprise Manager Online Help for instructions
To enable session binding from OracleAS Web Cache Manager:
1. In the navigator frame, select Origin Servers, Sites, and Load Balancing > Session Binding.
The Session Binding page appears.
2. In the Session Binding page, select Default Session Binding or a specific site name in the table, and then click Edit Selected.
The Edit Session Binding dialog box appears.
3. From the Please select a session list:
● If you selected the Default Session Binding rule in Step 2, change the session value from Use Default Session Binding to another defined session, and then skip to Step 4.
● If you selected a specific site in Step 2, change the session value from Disable Session Binding to a defined session, and then skip to Step 3. Table 8-1 provides descriptions of the default session definitions provided at installation time.
If you want OracleAS Web Cache to bind user sessions with multiple cookies when any cookie is set, select a session of Any Set Cookie. When selecting Any Set Cookie, in Please select a session binding mechanism, select Cookie-Based to instruct OracleAS Web Cache to include a Set-Cookie response-header in the response.
If the sessions listed do not contain the definition you require, click Cancel to exit the Edit Session Binding dialog box. Continue to Step 4.
4. Create a session definition:
● In the navigator frame, select Rules for Caching, Personalization, and Compression > Session Definitions.
The Session Definitions page appears.
● From the For Site list, select the Web site for which you want to create site-specific site definitions.
● Click Add or Create.
The Edit/Add Session Definition dialog box appears.
● In the Session Name field, enter an easy-to-remember unique name.
● Enter the cookie name in the Cookie Name field and the embedded URL parameter in the URL or Post body parameter field.
If you enter both a cookie name and an embedded URL parameter, keep in mind that both must be used to support the same session. If they support different sessions, create separate session definitions. You can specify up to 20 session definitions for each page.
Note:
OracleAS Web Cache requires a session cookie to perform session binding. If client browsers do not support cookies and you want to use an embedded URL parameter for the session, then perform the following for OracleAS Web Cache to perform session binding on the session:
1. In addition to the URL Parameter field, specify a cookie name for the session in the Cookie Name field.
2. Ensure that the origin server returns a Set-Cookie response-header with the value of the session every time a session is created.
Set-Cookie: cookie=value
Set value to the same value as set in the URL Parameter field.
OracleAS Web Cache uses the Set-Cookie response header, even if ignored by browsers, to locate the session cookie value for session binding.
See Also: http://www.rfc-editor.org/ for further information about the Set-Cookie response header
● Click Submit.
● Repeat Steps 1 through 3.
5. From the Please select a session binding mechanism list, select one of the following mechanisms:
● Cookie-based: Select if the client supports cookies. OracleAS Web Cache uses its own cookie to track a session. This cookie, which contains routing information, is maintained between OracleAS Web Cache and the client browser.
● OC4J-based: Select if the application is based on OC4J. OracleAS Web Cache forwards routing information with each request to OC4J through Oracle HTTP Server.
● Internal-tracking: Select if the client does not support cookies and the application is not based on Oracle HTTP Server and OC4J. This option is intended for backward compatibility with earlier releases of OracleAS Web Cache. OracleAS Web Cache maintains an in-memory routing table, of which each entry maps a session ID to an origin server. The routing table is not shared among cluster nodes. If you select this option and you have a cache cluster configuration, then you must bind at the load balancer layer.
6. Click Submit.
If you selected the Default Session Binding rule in Step 2, the new settings will be applied to all defined sites with the default session binding setting. However, the new default will not be applied to undefined sites. If you selected a specific site in Step 2, the new settings will be applied to just the site.
http://www.scribd.com/doc/54944312/8/Configure-OracleAS-Web-Cache-to-Act-Solely-as-a-Software-Load-Balancer
