C Frequently Asked Questions

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

See Also:

"Frequently Asked Questions" in the Apache Server documentation.

Documentation from the Apache Software Foundation is referenced when applicable.

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 the hyperlinks.

C.1 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.

See Also:

ErrorDocument directive in the Apache Server documentation.

C.2 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 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 4443 of that same per-customer IP address and use SSL directives, such as Using mod_ossl Directives 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 4443 of the shared IP address. All customers will share the SSL configuration, including the wallet and ISP's server certificate.

See Also:

"Running Oracle HTTP Server as Root"

C.3 Using Different Language and Character Set 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.

C.4 Sending Proxy Sensitive Requests to HTTP Server Behind a Firewall

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

C.5 mod_oc4j Information

mod_oc4j is a module that integrates with Web servers, typically Oracle HTTP Server, and routes request to the backend OC4J processes. OPMN module keeps mod_oc4j aware of the status of different OC4J processes, so mod_oc4j routes only to the processes that are up and running. mod_oc4j also understands the concepts of Oracle Application Server Clusters and OC4J islands, and routes accordingly to provide as much transparent failover as possible.

See Also:

"mod_oc4j"

C.6 mod_oc4j Communication to OC4J using SSL

The AJP communication between mod_oc4j and OC4J processes can now be over AJP/SSL. Previously, this was in the clear. Also, the SSL negotiation does not happen each time mod_oc4j and OC4J communicate, resulting in less performance impact.

C.7 Oracle HTTP Server Version Number

Oracle HTTP Server is based on Apache version 2.0.52.

C.8 Applying Apache Security patches to Oracle HTTP Server

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

Oracle tests and appropriately modifies security patches before releasing them to Oracle 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.

C.9 Compressing Output from Oracle HTTP Server

In general, Oracle recommends the use of OracleAS Web Cache for this purpose. There are other freeware modules, such as mod_gzip that may be plugged in for this purpose, but their use is not supported. When using these, there may be an error message with respect to EAPI, but in general that can be ignored.

C.10 Supporting PHP

mod_php is fully supported in Release 2 (10.1.2.)

See Also:

"mod_php"

C.11 Protecting Web Site From Hackers

There are many attacks, and new attacks are invented everyday. The following are some general guidelines for securing your site. You can never be 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 aids in prosecution of the hackers.