Skip Headers

Oracle® HTTP Server Administrator's Guide
10g Release 1 (10.1)

Part Number B12255-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page

Go to previous page
Go to next page
View PDF

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.


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.

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.

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 for each user listening on port 4443 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 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" for instructions on running Oracle HTTP Server with ports lesser than 1024.

Using Oracle HTTP Server as Cache

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

See Also:

"ProxyRequests and CacheRoot directives" in the Apache Server documentation.

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.

See Also:

"Multiviews" in the Apache Server documentation.

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 sensitive requests across firewalls.

Oracle HTTP Server Version Number

Oracle HTTP Server 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:

Supporting PHP

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

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 namespace. 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:


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>

Server2's configuration is complementary. If you decide to partition the namespace by content type (HTML on server, JSP on server2), change server configuration 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/application\d">

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

Protecting 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 completely secure, but you can avoid being an easy target.