8
Frequently Asked Questions

This chapter provides answers to frequently asked questions on how to configure the Oracle HTTP Server to perform specialized useful functions.

See Also: "Frequently Asked Questions" in the Apache Server documentation.

Note: Readers using this guide in PDF or hard copy formats will be unable to access third-party documentation, which Oracle provides in HTML format only. To access the third-party documentation referenced in this guide, use the HTML version of this guide and click on the hyperlinks.

1. How do I create an application-specific error page?

   Oracle HTTP Server has a default content handler for dealing with errors. You can use the ErrorDocument directive to override the defaults.

   See Also: "ErrorDocument directive" in the Apache Server documentation.

2. How can I offer HTTPS to my ISP (virtual host) customers?

   For HTTP, Oracle HTTP Server supports two types of virtual hosts: name-based and IP-based. HTTPS supports only IP-based virtual hosts.

   If you are using IP-based virtual hosts for HTTP, then the customer has a virtual server listening on port 80 of a per-customer IP address. To provide HTTPS for these customers, simply add an additional virtual host per user listening on port 443 of that same per-customer IP address and use SSL directives, such as SSLRequireSSL to specify the per-customer SSL characteristics. Note that each customer can have their own wallet and server certificate.

   If you are using name-based virtual hosts for HTTP, each customer has a virtual server listening on port 80 of a shared IP address. To provide HTTPS for those customers, you can add a single shared IP virtual host listening on port 443 of the shared IP address. All customers will share the SSL configuration, including the wallet and ISP's server certificate.

3. How can I use the Oracle HTTP Server as a Web cache?

   You can use the Oracle HTTP Server as a Web cache by setting the ProxyRequests "on" and CacheRoot directives.

   See Also: "ProxyRequests and CacheRoot directives" in the Apache Server documentation.

4. How can I configure the Oracle HTTP Server to use different language and character set versions of a document?

   You can use multiviews, a general name given to the Apache server's ability to provide language and character-specific document variants in response to a request.

   See Also: "Multiviews" in the Apache Server documentation.

5. How do I configure the Oracle HTTP Server if I use Oracle9iAS Web Cache in front of it?

   You can use directives such as ExpiresActive, ExpiresByType, ExpiresDefault, to set the length of time that any cache existing between the client and the Web server will cache the returned Web pages.

   See Also: "ExpiresActive, ExpiresByType, ExpiresDefault directives" in the Apache Server documentation.

6. When the Oracle HTTP Server is in front of a firewall, how should it send proxy sensitive requests to an Oracle HTTP Server behind a firewall?

   You should use the Proxy directives, and not the Cache directives, to send proxy sensitive requests across firewalls.

7. How can I use <Directory>, <Location>, Alias, and other directives to create a simple, distributed application name space that works across firewalls, clusters of application servers, and Web caches?

   The general idea is that all servers in a distributed Web site should agree on a single URL namespace. Every server will serve some part of that namespace, and will be able to redirect or proxy requests for URLs that it does not serve to a server that is "closer" to that URL. For example, your namespaces could be the following:

   /app1/login.html
   /app1/catalog.html
   app1/dologin.jsp
   /app2/orderForm.html
   /apps/placeOrder.jsp
   

   We could initially map this namespace to two Web servers by putting app1 on server1 and app2 on server2. Server1's configuration might look like the following:

   Redirect permanent /app2 http://server2/app2
   Alias /app1 /myApps/application1
   <Directory /myApps/application1>
   ...
   </Directory>
   

   Server2's configuration is complementary. Now, if we decide to partition the namespace by content type (HTML on server, JSP on server2), we change server configuration and move files around, but we do not have to make changes to the application itself. The resulting configuration of server1 might look like the following:

   RedirectMatch permanent (.*) \.jsp$ http://server2/$1.jsp
   AliasMatch ^/app(.*) \.html$ /myPages/application$1.html
   <DirectoryMatch "^/myPages/application\d">
   ...
   </DirectoryMatch>
   

   Note that the amount of actual redirection can be minimized by configuring a hardware load balancer like F5 system's BigIP to send requests to server1 or server2 based on the URL.

8. How do I protect my Web site from hackers?

   There are many attacks, and new attacks are invented everyday. Following are some general guidelines for securing your site. You can never be really completely secure, but you can avoid being an easy target.

   • Use a commercial firewall, such as Checkpoint FW-1 or Cisco PIX between your ISP and your Web server. Recognize, however, that not all hackers are outside your organization.

   • Use switched ethernet to limit the amount of traffic a compromised server can sniff. Use additional firewalls between Web server machines and highly sensitive internal servers running database and enterprise applications.

   • Remove unnecessary network services such as RPC, Finger, telnet from your server machine.

   • Carefully validate all input from Web forms. Be especially wary of long input strings and input that contains non-printable characters, HTML tags, or javascript tags.

   • Encrypt or randomize the contents of cookies that contain sensitive information. For example, it should be difficult to guess a valid sessionId to prevent a hacker from hijacking a valid session.

   • Check often for security patches for all your system and application software, and install them as soon as possible. Be sure these patches come from bona fide sources; download from trusted sites and verify the cryptographic checksum.

   • Use an intrusion detection package to monitor for defaced Web pages, viruses, and presence of "rootkits" that indicate hackers have broken in. If possible, mount system executables and Web content on read only file systems.

   • Have a "forensic analysis" package on hand to capture evidence of a break in as soon as detected. This will aid in prosecution of the hackers.