9
Frequently Asked Questions

This chapter provides answers to frequently asked questions about Oracle HTTP Ser ver.

Documentation from the Apache Software Foundation i s referenced when applicable.

Creating Application-specific Error Pages

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

Offering HTTPS to 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 host s.

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 for e ach user listening on port 4443 of that same per-customer IP address and use SSL directives, such as SSL RequireSSL to specify the per-customer SSL characteristics. Note that each customer can have their own wallet and server certific ate.

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 liste ning on port 4443 of the shared IP address. All customers will share the SSL configuration, including the wallet and ISP's server cer tificate.

Using Oracle HTTP Serv er as Cache

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

Using Different Language and Character Se t Versions of 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.

Sending Proxy Sensitive Requests to Oracle HTTP Server Behind a Firewall

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

Oracle HTTP Server Version Number

Oracle HTTP Se rver is based on Apache version 1.3.28.

Apache v2.0 Support with Oracle Database, 10g Release 1 (10.1)

Oracle Database, 10g Release 1 (10.1) is still based on the 1.3.x stack from Apache organization.

Applying Apache Security patches to Oracle HTTP Server

You cannot apply the Apache security patches to Oracle HTTP Server for the following reasons:

< li class="LB1" type="disc">Oracle tests and appropriately modifies security patches before releasing them to Or acle HTTP Server users.
• In many cases those alerts may not be applicable, for example, openSSL alerts, since Oracle has removed those components from the stack in use.
• Oracle releases these patches soon enough that the time-delay impact of getting the patch from Oracle versus open source organization should be minimal and the benefit with respect to supportability, tremendous.

< /a>

Supporting PHP

mod_php is not supported, however, you have the following two options:

• Install mod_php by yourself and use it. If there i s a support question on any aspect of Oracle HTTP Server, you might be asked to reproduce the problem without mod_php.
• Use PHP in a CGI mode, in which case support of the rest of the Oracle HTTP Ser ver stack would not be an issue.

Creating Application Name Space that Works Across Firewalls and Clusters

The general idea is that all servers in a distributed Web site should agree on a single URL namesp ace. Every server serves some part of that namespace, and is 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/orderFor
m.html
/apps/placeOrder.jsp

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

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

Server2's configurati on is complementary. If you decide to partition the namespace by content type (HTML on server, JSP on server2), change server configu ration and move files around, but 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/applicati
on\d">
  ...
</DirectoryMatch>

Note that the amount of actual redirection can be minimized by configuring a hardware load balancer to send reques ts to server1 or server2 based on the URL.

Protecting Web Site From Hackers

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

• Use a commercial firewall between your ISP and your Web server. Recognize, however, that not all hackers are outside your organi zation.
• Use switched ethernet to limit the amount of traffic a compromised ser ver can sniff. Use additional firewalls between Web server machines and highly sensitive internal servers running database and enterp rise applications.
• Remove unnecessary network services such as RPC, Finger, te lnet 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 exampl e, 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 b reak in as soon as detected. This aids in prosecution of the hackers.