Release 2 (9.0.2)
Part Number A97301-01
 Home |
| Oracle9iAS Web Cache Release Notes Release 2 (9.0.2) Part Number A97301-01 |
|
April 2002
Part No. A97301-01
This document summarizes the differences between Oracle9iAS Web Cache and its documented functionality.
This section describes general issues and their workarounds for Oracle9iAS Web Cache. It contains the following sections:
Oracle9iAS Web Cache uses 2 KB for the access log buffer size and the following for cached documents:
If the HTTP response body is less than 4 KB, then Oracle9iAS Web Cache uses a 4 KB buffer size.
These default sizes should be sufficient for most deployments. If you need to change any of these default sizes, contact Oracle Support Services or consultants.
Oracle9iAS Web Cache Manager, the graphical user interface tool for configuring Oracle9iAS Web Cache, does not enforce the same level of consistency checking upon receiving configuration input that Oracle9iAS Web Cache does upon starting up. Therefore, there may be instances where configuration changes are accepted by the Oracle9iAS Web Cache Manager, but Oracle9iAS Web Cache does not start up with the resulting configuration.
This is especially a problem when the admin server process is shut down (with the webcachectl stop or webcachectl stopadm command) after applying bad configuration changes. In that case, the admin server process will not be able to start up, and the Oracle9iAS Web Cache Manager will become inaccessible. To work around this problem, run the webcachectl reset command to restore to the previous version of the configuration. webcachectl is located in $ORACLE_HOME/bin on UNIX and ORACLE_HOME\bin on Windows.
Oracle Application Server, when used specifically with the Oracle Web Listener, strictly enforces virtual-host checking using the Host request header, that is sent by almost all browsers. The Host header contains the string "hostname:port" where hostname and port are as entered in the location bar of the browser, even if the hostname in the location bar is an IP address. If the Oracle Web Listener receives a Host header that does not match an entry in the Host Name and Port columns of the Network section of the configuration (corresponding to the [Multiport] section in the sv*.cfg configuration file for the listener), it returns an HTTP error code 400 indicating that the request did not specify a valid virtual host.
This limitation applies to the following deployments:
Network section. The port number in the Host header does not matter.
To make an Oracle Web Listener recognize and accept a Host header, a corresponding entry must be added to the Network section for that listener. When you add an entry with host name h1 and port p1, h1 is only used to match incoming Host headers and does not otherwise effect the operation of the listener. h1 does not need to be a DNS host name of the computer. However, p1 is used as a port that the Oracle Web Listener tries to listen on. Hence there should be no other process on the computer listening on port p1.
Oracle9iAS Web Cache does not change the Host header that it receives as part of a request when relaying that request to the application Web server.
If you set up Oracle9iAS Web Cache to listen on port 1100 on a computer with DNS host name m1 and the Application Web Server is on computer m2 on port 80, and you use a browser to access http://m1:1100/, the Host header received by Oracle9iAS Web Cache is "Host: m1:1100". This is exactly the Host header that will be received by the application Web server.
If you are using Oracle Application Server with the Oracle Web Listener as your application Web server, this means that the Host header sent to Oracle9iAS Web Cache must be recognized by the Oracle Web Listener, that is, there must be a corresponding entry in the Network section.
If you are using Oracle9iAS Web Cache's host name and port directly in your browser, and if Oracle9iAS Web Cache and the Oracle Web Listener are on the same computer, the Oracle Web Listener will need to accept Oracle9iAS Web Cache's host name and port number in the Host header, and for that to occur Oracle9iAS Web Cache's port number needs to be in the Network section of the Listener's configuration. This would mean that both Oracle9iAS Web Cache and the Oracle Web Listener will try to listen on that port, which is not possible. See Section 1.3.2, "Entries for Network".
When you are using your browser to connect directly to Oracle9iAS Web Cache, ensure that Oracle9iAS Web Cache and the Oracle Web Listener are not on the same computer.
To deploy Oracle9iAS Web Cache and the Oracle Web Listener on the same computer, there has to be a port-translating switch between the browser and Oracle9iAS Web Cache that translates the port number to which the browser connects to Oracle9iAS Web Cache's listening port.
For example, assume that Oracle9iAS Web Cache is listening on port 7777 on computer m1.aaa.com, and Oracle Web Listener is the application Web server listening on port 80 on the same computer m1.aaa.com. In this example, the user enters http://www.aaa.com/ in the browser. The browser will attempt to connect to port 80 on www.aaa.com. www.aaa.com should be resolved through DNS to the switch, which should redirect requests for www.aaa.com on port 80 to computer m1 on port 1100. Note that the Host header will be: "Host: www.aaa.com:80". Oracle9iAS Web Cache will forward requests as needed to computer m1 port 80, that is, the Oracle Web Listener. For the Oracle Web Listener to accept this Host header, you will need to have added an entry to Network containing host name www.aaa.com and port 80. See Section 1.3.2, "Entries for Network" for how this can done on computer m1.
If you want Oracle9iAS Web Cache to handle a large number of concurrent HTTP requests, you may need to tune TCP/IP settings for your operating system, such as the maximum TCP/IP connection queue length.
|
See Also:
Operating-system-specific documentation. For example, |
In particular, if you run stress tests against Oracle9iAS Web Cache and continuously open more TCP/IP connections from one client computer to Oracle9iAS Web Cache, you may experience periodic oscillation of throughput. This is usually caused by TCP/IP connection TIME_WAIT in your operating system. In real world deployments, this is not an issue since it is unlikely that a single client will generate a huge number of connections.
In case of denial of service attack, availability problems usually arise in the network layer in your operating system. For example, if one client generates large number of connections, TCP/IP connection problems generally arise in your operating system.
The following examples demonstrate utilities that set some of the TCP/IP parameters for Solaris, HP-UX, AIX, Linux, and Compaq Tru64.
#!/usr/bin/bash -x /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 10240 /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 10240 /usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 32768 /usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 32768 /usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 1000
#!/usr/bin/ksh /usr/bin/ndd -set /dev/tcp tcp_conn_req_max_q 10240 /usr/bin/ndd -set /dev/tcp tcp_time_wait_interval 1000
Use the no utility to set the tcp tunable values on AIX.
For example, to see current values, enter:
prompt> no -a
To increase the size of send and receive buffers, enter:
prompt> no -o tcp_sendspace=65536 prompt> no -o tcp_recvspace=65536
On Linux, the tunable TCP/IP parameters can be set through the /proc file system.
The /proc/sys/net/ipv4 directory contains the files which can be edited to change the TCP/IP default values.
For example, enter the following commands:
prompt> echo 900 > /proc/sys/net/ipv4/tcp_keepalive_time prompt> echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout
Also, you can set the size of TCP/IP sender and receiver windows using the following command, where w_value and r_value are the new sizes of the windows:
prompt> echo w_value /proc/sys/net/core/wmem_max prompt> echo r_value /proc/sys/net/core/rmem_max
Use the sysconfig utility to set the TCP/IP tunable values for Tru64.
For example, to set the value of tcbhashsize to 16384, enter:
prompt> sysconfig -r inet tcbhashsize=16384
To enable keepalive, enter:
prompt> sysconfig -r inet tcp_keepalive_default=1
To set the maximum number of pending TCP/IP connections, enter:
prompt> sysconfig -r socket somaxconn=65535
This section describes configuration issues and their workarounds for Oracle9iAS Web Cache. It contains the following sections:
To start initial Oracle9iAS Web Cache configuration:
From the command line, enter webcachectl start.
http://web_cache_hostname:4000/
administrator.
Oracle9iAS Web Cache Administration and Deployment Guide (available at
See Also:
http://otn.oracle.com/products/ias/web_cache/) for complete configuration coverage
Oracle9iAS Web Cache uses two configuration files: webcache.xml and internal.xml. The Oracle9iAS Web Cache Manager writes its configuration information to the webcache.xml file. Oracle9iAS Web Cache uses internal.xml file. These files are located in the $ORACLE_HOME/webcache directory on UNIX and ORACLE_HOME\webcache directory on Windows. Do not edit these configuration files manually, except in the cases described in these Release Notes, or when directed to do so by Oracle Support Services. Improper editing of these configuration files may cause problems in Oracle9iAS Web Cache.
In past releases, the following attributes required manual modification of the internal.xml file:
KEEPALIVE_TIMEOUT attribute specifies the time, in seconds, for Oracle9iAS Web Cache to keep a connection open to the browser after it has returned a response.
OSRECV_TIMEOUT attribute specifies the time, in seconds, for the origin server to generate a response to Oracle9iAS Web Cache.
In this release of Oracle9iAS Web Cache, these attributes have been merged into the Oracle9iAS Web Cache Manager (webcache.xml). During migration, these modifications are not preserved. If you modified these attributes, you have two choices. You can:
internal.xml, and copy the changes to the appropriate place in webcache.xml.
If you are upgrading an existing Oracle9iAS Web Cache installation, the passwords for administration and invalidation are reset. The user name and password for administration is administrator/administrator and the user name and password for invalidation is invalidator/invalidator. You can change both passwords in the Security page (General Configuration > Security) of Oracle9iAS Web Cache Manager.
By default, Oracle9iAS Web Cache is configured to use the following default TCP ports:
If these ports are in use, the installation procedure attempts to assign other port numbers from a range of possible port numbers.
The default configuration does not enable HTTPS for the operations (administration, invalidation, or statistics monitoring) requests. Instead, these ports are configured for HTTP basic authentication. The passwords for the administrator user and the invalidator user can be decoded when they are sniffed out of the HTTP traffic. To avoid breach of security information for unprotected and insecure networks, modify the protocol to HTTPS in the Operations page (Cache-Specific Configuration > Operations Ports) to ensure that the passwords for these requests are secure.
The Oracle HTTP Server is configured to use the following default ports:
At the end of installation, Oracle9iAS Web Cache will attempt to start. Depending on your environment (port conflicts, file/directory permissions, and so on), the admin server process and cache server process may fail to start.
If the admin server could not start because the default administration port is already in use by other running applications, you need to change the administration port in the webcache.xml file.
To change the administration port:
webcache.xml file:
<LISTEN IPADDR="ANY" PORT="4000" PORTTYPE="ADMINISTRATION"/>
webcachectl start command to start the admin server and cache server processes.
If the admin server process starts, but the cache server process does not start, point your browser http://web_cache_hostname:administration_port/ to reconfigure the cache server process, and then start the cache server process from the Operations page (Administration > Operations).
If any of the port settings conflict with existing settings in the installed computer, reconfigure through http://web_cache_hostname:administration_port/. For example, if Oracle9iAS Web Cache is installed on a computer named server1, then you can reconfigure through http://server1:4000/.
After reconfiguring the administration port, you must restart the admin server process. After reconfiguring any other ports, you must restart the admin server process.
To restart the admin server process, execute either the webcachectl restart command or the webcachectl restartadm command.
If the definition of Oracle home in the webcache.xml configuration file is different than the definition of Oracle home in your environment, Oracle9iAS Web Cache may fail to start.
For example on UNIX, if $ORACLE_HOME was defined as /home/oracle_home_ias during the installation, that definition is written to the ORACLEHOME attribute in the webcache.xml file. Then, if your environment defines $ORACLE_HOME as /private/oracle_home_ias and you invoke the webcachectl executable to start Oracle9iAS Web Cache, Oracle9iAS Web Cache will fail to start.
In this case, you may see a message similar to the following:
Error: No matchingCACHEelement found inwebcache.xmlfor current host name (webcache-host) andORACLE_HOME(/private/oracle_home_ias). Admin Server failed to start.
You can remedy this situation by either redefining $ORACLE_HOME in your environment or editing the webcache.xml file so that the definitions are identical. (In the webcache.xml file, you modify the ORACLEHOME attribute of the CACHE NAME element. In a cluster environment, there is more than one CACHE NAME element, one for each cluster member. Be sure to modify the correct element.)
[Reference Bug: 2286732]
A cache hierarchy whereby one Oracle9iAS Web Cache server acts as an origin server to another Oracle9iAS Web Cache server is not enabled by default.
To configure this advanced feature:
internal.xml file.
<INVALIDATION/> element and add attribute ENABLEOUTBOUNDICC="YES" as follows:
<INVALIDATION ENABLEOUTBOUNDICC="YES" />
In a distributed deployment with a local cache and remote caches, the local cache stores content from application Web server, and the remote caches store content from the local cache. In other words, the local cache acts as an origin server to the remote caches.
To configure a distributed deployment with local and remote caches, perform the tasks in "Setting Up Oracle9iAS Web Cache" of Chapter 6, "Initial Setup and Configuration," in the Oracle9iAS Web Cache Administration and Deployment Guide for each cache. When performing the tasks, take special care to perform the following:
When content from the local cache becomes invalid, an invalidation message is sent to its cache. In addition, the local cache propagates the invalidation message to the remote caches.
Table 1 shows the example settings for local cache webcache1-host and remote cache webcache2-host.
In a deployment with subscriber and provider caches:
For these deployments, the provider caches act as origin servers to the subscriber cache.
To configure an ESI deployment with subscriber and provider caches, perform the tasks in "Setting Up Oracle9iAS Web Cache" of Chapter 6, "Initial Setup and Configuration," in the Oracle9iAS Web Cache Administration and Deployment Guide for each cache. When performing the tasks, take special care to perform the following:
When content from the provider cache becomes invalid, an invalidation message is sent to its cache. In addition, the provider cache propagates the invalidation message to the subscriber cache.
Table 2 shows the example settings for subscriber cache webcache-host and provider cache webcache-providerhost.
Invalidation has a default time-out of 300 seconds for the propagation of messages in the following deployments:
To change the default settings, modify the webcache.xml file:
webcache.xml file.
<CALYPSONETINFO...> line:
<CALYPSONETINFO INV_PEER_TIMEOUT="300" INV_GLOBAL_TIMEOUT="300"/>
INV_PEER_TIMEOUT to modify the time-out for invalidation messages sent in a cache hierarchy.
INV_PEER_TIMEOUT to modify the time-out for invalidation messages sent in a cache cluster.
At installation time, Oracle HTTP Server sets the httpd.conf file with the following directives that impact Oracle9iAS Web Cache:
Port=web_cache_port specifies the Oracle9iAS Web Cache listening ports, enabling dynamically created URLs to be redirected to Oracle9iAS Web Cache
Listen=Oracle_HTTP_Server_port specifies the HTTP and HTTPS ports obtained by Oracle HTTP Server
ServerName specifies the host name of Oracle HTTP Server
UseCanonicalName On instructs Oracle HTTP Server to use the host names and port values set in the ServerName and Port directives when redirecting a URL
For example:
## ## httpd.conf -- Apache HTTP server configuration file ## ... Port 7777 Listen 7778 ... ServerName http_server.company.com ... UseCanonicalName On ....
If you decide to disable Oracle9iAS Web Cache, then the Oracle HTTP Server administrator must modify the value of the Port directive to the same value set for the Listen directive.
For example:
## ## httpd.conf -- Apache HTTP server configuration file ## ... Port 7778 Listen 7778 ... ServerName http_server.company.com ... UseCanonicalName On ....
If Oracle9iAS Web Cache is deployed on a separate machine from the Oracle HTTP Server, then the Oracle HTTP Server administrator must modify the ServerName directive in httpd.conf for each site hosted by Oracle9iAS Web Cache. This will enable Oracle HTTP Server to redirect URLs to Oracle9iAS Web Cache. The following example shows httpd.conf modified to direct requests for www.1st.company.com and www.2nd.company.com to Oracle9iAS Web Cache, which listening on port 7777.
Port 7777 Listen 7778 ... ServerName www.1st.company.com ServerName www.2nd.company.com ... Usecanonicalname On ....
The httpd.conf file resides in $ORACLE_HOME/Apache/Apache/conf/httpd.conf on UNIX or ORACLE_HOME\Apache\Apache\conf\httpd.conf on Windows.
The Oracle proprietary language elements described in Appendix D, "Edge Sides Includes Languages," of the Oracle9iAS Web Cache Administration and Deployment Guide are not supported by the Edge Sides Includes for Java (JESI) in this release. Oracle Corporation plans to support these language elements in a future implementation.
Oracle9iAS Web Cache supports HTTP and HTTPS in the src attribute of the <esi:include> tag. Oracle9iAS Web Cache permits the template and fragments to use different protocols. Take note of the following:
src attribute specifies a fragment's relative path, such as src="/PersonalizedGreeting", then the template's protocol is used.
src attribute does not match the protocol specified in the Site to Server Mapping page (General Configuration > Site to Server Mapping), then Oracle9iAS Web Cache uses the protocol configured for the origin server in the Site to Server Mapping page. Oracle9iAS Web Cache also reports the following warning message to the event log:
DateWarning: ESI Include protocol does not match Origin Server protocol: Origin Server Protocol=protocolURL=URL
For example, if the template page is configured with <esi:include> src="https://www.company.com/gifs/frag1.gif"/> 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:
11/Jan/2002:19:25:59 +0000 Warning: ESI Include protocol does not match Origin Server protocol: Origin Server Protocol=http URL=https://www.company.com/gifs/frag1.gif
When a non-fetchable <esi:inline> fragment is not found in the cache, Oracle9iAS Web Cache re-fetches the fragment's parent template. This behavior implies that the parent cannot be another non-fetchable <esi:inline> fragment. If the parent is an <esi:inline> non-fetchable fragment, then the response returned to the browser is undefined.
Note the following limitations when appending the string +wcdebug to the URL of the document to see the diagnostic information string embedded in the response body:
+wcdebug for a content owned by another cache member, the page with debug information may be stored in the cache as an on-demand cached page. During a subsequent request for the same page without +wcdebug, you will retrieve the on-demand cached page with the debug information.
[Reference Bug: 2142446]
telnet, you will see the debug information prepended to the compressed page.
[Reference Bug: 2133691]
Most Web sites are served by multiple origin servers running on multiple computers that share the load of HTTP and HTTPS requests. All requests that Oracle9iAS Web Cache cannot serve are passed to the origin servers. Oracle9iAS Web Cache balances the load among origin servers by determining the percentage of the available capacity, the weighted available capacity of each origin server. Oracle9iAS Web Cache sends a request to the origin server with the highest weighted available capacity. The weighted available capacity is determined by the following formula:
(Capacity - Load) / Capacity
where:
Capacity is the maximum number of concurrent connections that the origin server can accept
Load is the number of connections currently in use
If the weighted available capacity is equal for multiple origin servers, then Oracle9iAS Web Cache sends requests to the origin servers in round-robin fashion. With round-robin, the first origin server in the list of configured servers receives the request, then the second origin server receives the second request.
If the weighted available capacity is not equal, Oracle9iAS Web Cache sends the request to the origin server with the highest weighted available capacity.
Consider the following cases:
company1-host and company2-host, with capacities of 50 each.
The requests to company1-host and company2-host will be distributed between the two origin servers so that they maintain an equal load. The first request is sent to company1-host. The second request is sent to company2-host if company1-host is still processing the first request. The third and subsequent requests are sent to the origin server that has the highest weighted available capacity.
server1-host, server2-host, and server3-host with capacities of 150, 50, and 50, respectively.
The first request is sent to server1-host.
The second request is sent to server2-host, because server1-host now has a weighted available capacity of 99.3 percent and server2-host has a weighted available capacity of 100 percent.
The third request is sent to server3-host because server2-host now has a weighted available capacity of 98 percent and server3-host has a weighted available capacity of 100 percent.
The fourth request is sent to server1-host because server2-host and server3-host now have weighted available capacities of 98 percent.
The fifth request is sent to server1-host because its weighted available capacity is 98.6 percent, still greater than that of server2-host and server3-host.
To configure load balancing, set the capacity of each origin server.
If an origin server is busy, then Oracle9iAS Web Cache disables session binding to that origin server.
[Reference Bug: 2180999]
Oracle9iAS Web Cache permits only five concurrent users on Windows NT Workstation. If you require more than five concurrent users, then consider using a Windows NT Server, such as Windows NT or Windows 2000.
Table 3 describes browser limitations and their impact on Oracle9iAS Web Cache.
Table 4 describes event logs related to cache clusters. This information supplements information in Appendix E, "Event Log Messages," of the Oracle9iAS Web Cache Administration and Deployment Guide.
By default, peer requests between two members of a cache cluster are not logged in the access log. Only client requests to the cluster are logged. Peer request logging can be enabled for individual cache cluster members by adding the ACCESSLOGIGNOREPEERREQUEST attribute to the MISCELLANEOUS element in the internal.xml configuration file.
The valid values for this attribute are:
The default value is YES.
The following example shows the MISCELLANEOUS element with peer-to-peer logging disabled:
<MISCELLANEOUS
ERRORLOGFILE="my_oracle_home/webcache/logs/event_log"
ACCESSLOGIGNOREPEERREQUEST="NO"/>
This section describes security limitations for Oracle9iAS Web Cache. It contains the following sections:
Oracle9iAS Web Cache does not cache pages that support basic HTTP authentication. These pages result in cache misses.
Oracle9iAS Web Cache does not cache login requests or authenticated pages that use mod_sso static directives. To ensure that responses for those pages using dynamic directives with mod_sso are not cached, add the Surrogate-Control: no-store response-header field to identify the page as non-cacheable.
When configured with HTTPS listening ports, Oracle9iAS Web Cache is unable to forward browser certificates to origin servers. If browsers are using certificate-based single sign-on authentication, do not use Oracle9iAS Web Cache. This restriction will be lifted in a future release of Oracle9iAS Web Cache.
If the root.sh script was run, then the webcachectl executable has a set-user ID of root. As a result, the user that installs Oracle9iAS Web Cache can gain root privileges. To restrict root privileges, remove set-user ID root from the webcachectl executable. Note that set-user ID root is required in the following cases:
webcachectl user does not match the configured user in the Process Identity page (Cache-Specific Configuration > Process Identity) of Oracle9iAS Web Cache Manager
Oracle Corporation plans to resolve this issue in the next release.
[Reference Bug: 2302587]
If a wallet contains a user certificate as a trustpoint for an origin server, then a core dump will occur when the user connects to the origin server. Oracle Corporation recommends not adding user certificates to trustpoints in the Oracle wallet but instead install the certificate authority (CA) signers' certificate as a trustpoint.
Oracle Corporation plans to resolve this issue in the next release.
[Reference Bugs: 2295542 and 2295884]
This section describes known errors and omission in the documentation for Oracle9iAS Web Cache. It contains the following sections:
The documentation for the Process Identity page (Cache-Specific Configuration > Process Identity) of Oracle9iAS Web Cache Manager describes how to change the user ID and group ID of the Oracle9iAS Web Cache executables. In addition to using the Process Identity page, you must also manually change the ownership of the following files and directories to the new user ID and group ID with the chown command:
$ORACLE_HOME/webcache
$ORACLE_HOME/webcache/internal.xml
$ORACLE_HOME/webcache/internal_admin.xml
$ORACLE_HOME/webcache/webcache.xml
$ORACLE_HOME/webcache/logs/event_log
$ORACLE_HOME/webcache/logs/access_log
The documentation for the cs(request_header) and sc(response_header) fields for access log does not provide sufficient examples of the request and response headers that can be used for these user-specified fields.
Table 5 lists examples of HTTP/1.1 headers that can be used for the cs(request_header) and sc(response_header) fields. This table lists only some of the possible headers. It is not an exhaustive list.
Table 6 lists examples of cookie-related headers that can be used for the cs(request_header) and sc(response_header) fields.
| cs(request_header) Field | sc(response_header) Field |
|---|---|
|
|
|
Table 7 lists examples of Oracle9iAS Web Cache headers that can be used for the cs(request_header) and sc(response_header) fields.
| cs(request_header) Field | sc(response_header) Field |
|---|---|
|
|
|
The following event log error message has been added to Oracle9iAS Web Cache:
Process out of memory on malloc/realloc request. Exiting process.
This error indicates that insufficient virtual memory remains in the cache server process to satisfy the request. The error can be caused by either of the following situations:
cache server process over the system limit.
When this error occurs, the cache server process is stopped. If auto-restart is enabled, then the auto-restart process automatically restarts the cache server process. If auto-restart is not enabled, then restart the cache server process from the Operations page (Administration > Operations).
Oracle is a registered trademark, and Oracle9i is a trademark or registered trademark of Oracle Corporation. Other names may be trademarks of their respective owners.
Copyright © 2002 Oracle Corporation.
All Rights Reserved.
|
|
 Copyright © 2002 Oracle Corporation. All Rights Reserved. |
|