Apache Http Server Version 2.0

Reference manager 12 full. free download. Using Apache with Microsoft Windows

The modproxy module in the Apache HTTP Server 2.0.x through 2.0.64 and 2.2.x before 2.2.18, when the Revision 1179239 patch is in place, does not properly interact with use of (1) RewriteRule and (2) ProxyPassMatch pattern matches for configuration of a reverse proxy, which allows remote attackers to send requests to intranet servers by using the HTTP/0.9 protocol with a malformed URI containing an. Apache HTTP Server Version 2.0. Apache HTTP Server Documentation. Apache HTTP Server Version 2.0 Documentation. New features with Apache 2.0; Upgrading to 2.0 from 1.3; Apache License; Reference Manual. Licensed under the Apache License, Version 2.0. The Apache HTTP Project developers strongly encourages all users to migrate to Apache stable release 2.4 or at minimum version the legacy release 2.2 as quickly as possible, as no further maintenance will be performed on this historical version 2.0. Apache HTTP Server Version 2.4 Documentation. New features with Apache 2.3/2.4; New features with Apache 2.1/2.2.

This document explains how to install, configure and run Apache 2.0 under Microsoft Windows. If you find any bugs, or wish to contribute in other ways, please use our bug reporting page.

This document assumes that you are installing a binary distribution of Apache. If you want to compile Apache yourself (possibly to help with development or tracking down bugs), see Compiling Apache for Microsoft Windows.

Because of the current versioning policies on Microsoft Windows operating system families, this document assumes the following:

* Windows NT: This means all versions of Windows that are based on the Windows NT kernel. Includes Windows NT, Windows 2000, Windows XP and Windows .Net Server 2003.
* Windows 9x: This means older, consumer-oriented versions of Windows. Includes Windows 95 (also OSR2), Windows 98 and Windows ME.

Operating System Requirements

The primary Windows platform for running Apache 2.0 is Windows NT. The binary installer only works with the x86 family of processors, such as Intel and AMD processors. Running Apache on Windows 9x is not thoroughly tested, and it is never recommended on production systems.

On all operating systems, TCP/IP networking must be installed and working. If running on Windows 95, the Winsock 2 upgrade must be installed. Winsock 2 for Windows 95 can be downloaded from here.

On Windows NT 4.0, installing Service Pack 6 is strongly recommended, as Service Pack 4 created known issues with TCP/IP and Winsock integrity that were resolved in later Service Packs.

Downloading Apache for Windows

nformation on the latest versions of Apache can be found on the web site of the Apache web server at http://httpd.apache.org/download.cgi. There you will find the current release, as well as more recent alpha or beta test versions, and a list of HTTP and FTP mirrors from which you can download the Apache web server. Please use a mirror near to you for a fast and reliable download.

For Windows installations you should download the version of Apache for Windows with the .msi extension. This is a single Microsoft Installer file, which contains a ready-to-run version of Apache. There is a separate .zip file, which contains only the source code. You can compile Apache yourself with the Microsoft Visual C++ (Visual Studio) tools.
Installing Apache for Windows

You need Microsoft Installer 1.2 or above for the installation to work. On Windows 9x you can update your Microsoft Installer to version 2.0 here and on Windows NT 4.0 and 2000 the version 2.0 update can be found here. Windows XP does not need this update.

Note that you cannot install two versions of Apache 2.0 on the same computer with the binary installer. You can, however, install a version of the 1.3 series and a version of the 2.0 series on the same computer without problems. If you need to have two different 2.0 versions on the same computer, you have to compile and install Apache from the source.

Run the Apache .msi file you downloaded above. The installation will ask you for these things:

Network Domain. Enter the DNS domain in which your server is or will be registered in. For example, if your server’s full DNS name is server.mydomain.net, you would type mydomain.net here.
2.

Server Name. Your server’s full DNS name. From the example above, you would type server.mydomain.net here.
3.

Administrator’s Email Address. Enter the server administrator’s or webmaster’s email address here. This address will be displayed along with error messages to the client by default.
4.

For whom to install Apache Select for All Users, on Port 80, as a Service – Recommended if you’d like your new Apache to listen at port 80 for incoming traffic. It will run as a service (that is, Apache will run even if no one is logged in on the server at the moment) Select only for the Current User, on Port 8080, when started Manually if you’d like to install Apache for your personal experimenting or if you already have another WWW server running on port 80.
5.

The installation type. Select Typical for everything except the source code and libraries for module development. With Custom you can specify what to install. A full install will require about 13 megabytes of free disk space. This does not include the size of your web site(s).
6.

Where to install. The default path is C:Program FilesApache Group under which a directory called Apache2 will be created by default.

During the installation, Apache will configure the files in the conf subdirectory to reflect the chosen installation directory. However, if any of the configuration files in this directory already exist, they will not be overwritten. Instead, the new copy of the corresponding file will be left with the extension .default. So, for example, if confhttpd.conf already exists, it will be renamed as confhttpd.conf.default. After the installation you should manually check to see what new settings are in the .default file, and if necessary, update your existing configuration file.

Also, if you already have a file called htdocsindex.html, it will not be overwritten (and no index.html.default will be installed either). This means it should be safe to install Apache over an existing installation, although you would have to stop the existing running server before doing the installation, and then start the new one after the installation is finished.

After installing Apache, you must edit the configuration files in the conf subdirectory as required. These files will be configured during the installation so that Apache is ready to be run from the directory it was installed into, with the documents server from the subdirectory htdocs. There are lots of other options which you should set before you really start using Apache. However, to get started quickly, the files should work as installed.

Customizing Apache for Windows

Apache is configured by the files in the conf subdirectory. These are the same files used to configure the Unix version, but there are a few different directives for Apache on Windows. See the directive index for all the available directives.

The main differences in Apache for Windows are:

Because Apache for Windows is multithreaded, it does not use a separate process for each request, as Apache does on Unix. Instead there are usually only two Apache processes running: a parent process, and a child which handles the requests. Within the child process each request is handled by a separate thread.

The process management directives are also different:

MaxRequestsPerChild: Like the Unix directive, this controls how many requests a single child process will serve before exiting. However, unlike on Unix, a single process serves all the requests at once, not just one. If this is set, it is recommended that a very high number is used. The recommended default, MaxRequestsPerChild 0, causes the child process to never exit.
Warning: The server configuration file is reread when a new child process is started. If you have modified httpd.conf, the new child may not start or you may receive unexpected results.

ThreadsPerChild: This directive is new. It tells the server how many threads it should use. This is the maximum number of connections the server can handle at once, so be sure to set this number high enough for your site if you get a lot of hits. The recommended default is ThreadsPerChild 50.
*

The directives that accept filenames as arguments must use Windows filenames instead of Unix ones. However, because Apache uses Unix-style names internally, you must use forward slashes, not backslashes. Drive letters can be used; if omitted, the drive with the Apache executable will be assumed.
*

While filenames are generally case-insensitive on Windows, URLs are still treated internally as case-sensitive before they are mapped to the filesystem. For example, the <Location>, Alias, and ProxyPass directives all use case-sensitive arguments. For this reason, it is particularly important to use the <Directory> directive when attempting to limit access to content in the filesystem, since this directive applies to any content in a directory, regardless of how it is accessed. If you wish to assure that only lowercase is used in URLs, you can use something like:

RewriteEngine On
RewriteMap lowercase int:tolower
RewriteCond %{REQUEST_URI} [A-Z]
RewriteRule (.*) ${lowercase:$1} [R,L]
*

Apache for Windows contains the ability to load modules at runtime, without recompiling the server. If Apache is compiled normally, it will install a number of optional modules in the Apache2modules directory. To activate these or other modules, the new LoadModule directive must be used. For example, to activate the status module, use the following (in addition to the status-activating directives in access.conf):

LoadModule status_module modules/mod_status.so

Information on creating loadable modules is also available.
*

Apache can also load ISAPI (Internet Server Application Programming Interface) extensions (i.e. internet server applications), such as those used by Microsoft IIS and other Windows servers. More information is available. Note that Apache cannot load ISAPI Filters.
*

When running CGI scripts, the method Apache uses to find the interpreter for the script is configurable using the ScriptInterpreterSource directive.
*

Since it is often difficult to manage files with names like .htaccess in Windows, you may find it useful to change the name of this per-directory configuration file using the AccessFilename directive.
*

Any errors during Apache startup are logged into the Windows event log when running on Windows NT. This mechanism acts as a backup for those situations where Apache cannot even access the normally used error.log file. You can view the Windows event log by using the Event Viewer application on Windows NT 4.0, and the Event Viewer MMC snap-in on newer versions of Windows.
Note that there is no startup error logging on Windows 9x because no Windows event log exists on those operating systems.

Running Apache as a Service

Apache can be run as a service on Windows NT. There is some highly experimental support for similar behavior on Windows 9x.

You can install Apache as a service automatically during the installation. If you chose to install for all users, the installation will create an Apache service for you. If you specify to install for yourself only, you can manually register Apache as a service after the installation. You have to be a member of the Administrators group for the service installation to succeed.

Apache comes with a utility called the Apache Service Monitor. With it you can see and manage the state of all installed Apache services on any machine on your network. To be able to manage an Apache service with the monitor, you have to first install the service (either automatically via the installation or manually).

You can install Apache as a Windows NT service as follows from the command prompt at the Apache bin subdirectory:

httpd -k install

If you need to specify the name of the service you want to install, use the following command. You have to do this if you have several different service installations of Apache on your computer.

httpd -k install -n “MyServiceName”

If you need to have specifically named configuration files for different services, you must use this:

httpd -k install -n “MyServiceName” -f “c:filesmy.conf”

If you use the first command without any special parameters except -k install, the service will be called Apache2 and the configuration will be assumed to be confhttpd.conf.

Removing an Apache service is easy. Just use:

httpd -k uninstall

The specific Apache service to be uninstalled can be specified by using:

httpd -k uninstall -n “MyServiceName”

Normal starting, restarting and shutting down of an Apache service is usually done via the Apache Service Monitor, by using commands like NET START Apache2 and NET STOP Apache2 or via normal Windows service management. Before starting Apache as a service by any means, you should test the service’s configuration file by using:

httpd -n “MyServiceName” -t

You can control an Apache service by its command line switches, too. To start an installed Apache service you’ll use this:

httpd -k start

To stop an Apache service via the command line switches, use this:

httpd -k stop

httpd -k shutdown

You can also restart a running service and force it to reread its configuration file by using:

httpd -k restart

By default, all Apache services are registered to run as the system user (the LocalSystem account). The LocalSystem account has no privileges to your network via any Windows-secured mechanism, including the file system, named pipes, DCOM, or secure RPC. It has, however, wide privileges locally.
Never grant any network privileges to the LocalSystem account! If you need Apache to be able to access network resources, create a separate account for Apache as noted below.

You may want to create a separate account for running Apache service(s). Especially, if you have to access network resources via Apache, this is strongly recommended.

1. Create a normal domain user account, and be sure to memorize its password.
2. Grant the newly-created user a privilege of Log on as a service and Act as part of the operating system. On Windows NT 4.0 these privileges are granted via User Manager for Domains, but on Windows 2000 and XP you probably want to use Group Policy for propagating these settings. You can also manually set these via the Local Security Policy MMC snap-in.
3. Confirm that the created account is a member of the Users group.
4. Grant the account read and execute (RX) rights to all document and script folders (htdocs and cgi-bin for example).
5. Grant the account change (RWXD) rights to the Apache logs directory.
6. Grant the account read and execute (RX) rights to the Apache.exe binary executable.

It is usually a good practice to grant the user the Apache service runs as read and execute (RX) access to the whole Apache2 directory, except the logs subdirectory, where the user has to have at least change (RWXD) rights.

If you allow the account to log in as a user and as a service, then you can log on with that account and test that the account has the privileges to execute the scripts, read the web pages, and that you can start Apache in a console window. If this works, and you have followed the steps above, Apache should execute as a service with no problems.
Error code 2186 is a good indication that you need to review the “Log On As” configuration for the service, since Apache cannot access a required network resource. Also, pay close attention to the privileges of the user Apache is configured to run as.

When starting Apache as a service you may encounter an error message from the Windows Service Control Manager. For example, if you try to start Apache by using the Services applet in the Windows Control Panel, you may get the following message:

Could not start the Apache2 service on COMPUTER
Error 1067; The process terminated unexpectedly.

You will get this generic error if there is any problem with starting the Apache service. In order to see what is really causing the problem you should follow the instructions for Running Apache for Windows from the Command Prompt.

There is some support for Apache on Windows 9x to behave in a similar manner as a service on Windows NT. It is highly experimental. It is not of production-class reliability, and its future is not guaranteed. It can be mostly regarded as a risky thing to play with – proceed with caution!

There are some differences between the two kinds of services you should be aware of:

Apache will attempt to start and if successful it will run in the background. If you run the command

httpd -n “MyServiceName” -k start

via a shortcut on your desktop, for example, then if the service starts successfully, a console window will flash up but it immediately disappears. If Apache detects any errors on startup such as incorrect entries in the httpd.conf configuration file, the console window will remain visible. This will display an error message which will be useful in tracking down the cause of the problem.
*

Windows 9x does not support NET START or NET STOP commands. You must control the Apache service on the command prompt via the -k switches.
*

Apache and Windows 9x offer no support for running Apache as a specific user with network privileges. In fact, Windows 9x offers no security on the local machine, either. This is the simple reason because of which the Apache Software Foundation never endorses use of a Windows 9x -based system as a public Apache server. The primitive support for Windows 9x exists only to assist the user in developing web content and learning the Apache server, and perhaps as an intranet server on a secured, private network.

Once you have confirmed that Apache runs correctly as a console application you can install, control and uninstall the pseudo-service with the same commands as on Windows NT. You can also use the Apache Service Monitor to manage Windows 9x pseudo-services.

Running Apache as a Console Application

Running Apache as a service is usually the recommended way to use it, but it is sometimes easier to work from the command line (on Windows 9x running Apache from the command line is the recommended way due to the lack of reliable service support.)

To run Apache from the command line as a console application, use the following command:

httpd

Apache will execute, and will remain running until it is stopped by pressing Control-C.

You can also run Apache via the shortcut Start Apache in Console placed to Start Menu –> Programs –> Apache HTTP Server 2.0.xx –> Control Apache Server during the installation. This will open a console window and start Apache inside it. If you don’t have Apache installed as a service, the window will remain visible until you stop Apache by pressing Control-C in the console window where Apache is running in. The server will exit in a few seconds. However, if you do have Apache installed as a service, the shortcut starts the service. If the Apache service is running already, the shortcut doesn’t do anything.

You can tell a running Apache to stop by opening another console window and entering:

httpd -k shutdown

This should be preferred over pressing Control-C because this lets Apache end any current operations and clean up gracefully.

You can also tell Apache to restart. This forces it to reread the configuration file. Any operations in progress are allowed to complete without interruption. To restart Apache, use:

httpd -k restart
Note for people familiar with the Unix version of Apache: these commands provide a Windows equivalent to kill -TERM pid and kill -USR1 pid. The command line option used, -k, was chosen as a reminder of the kill command used on Unix.

If the Apache console window closes immediately or unexpectedly after startup, open the Command Prompt from the Start Menu –> Programs. Change to the folder to which you installed Apache, type the command apache, and read the error message. Then change to the logs folder, and review the error.log file for configuration mistakes. If you accepted the defaults when you installed Apache, the commands would be:

c:
cd “Program FilesApache GroupApache2bin”
httpd

Then wait for Apache to stop, or press Control-C. Then enter the following:

cd .logs
more < error.log

When working with Apache it is important to know how it will find the configuration file. You can specify a configuration file on the command line in two ways:

-f specifies an absolute or relative path to a particular configuration file:

httpd -f “c:my server filesanotherconfig.conf”

httpd -f filesanotherconfig.conf
*

-n specifies the installed Apache service whose configuration file is to be used:

httpd -n “MyServiceName”

In both of these cases, the proper ServerRoot should be set in the configuration file. Lg front load washer manual.

If you don’t specify a configuration file with -f or -n, Apache will use the file name compiled into the server, such as confhttpd.conf. This built-in path is relative to the installation directory. You can verify the compiled file name from a value labelled as SERVER_CONFIG_FILE when invoking Apache with the -V switch, like this:

httpd -V

Apache will then try to determine its ServerRoot by trying the following, in this order:

1. A ServerRoot directive via the -C command line switch.
2. The -d switch on the command line.
3. Current working directory.
4. A registry entry which was created if you did a binary installation.
5. The server root compiled into the server. This is /apache by default, you can verify it by using apache -V and looking for a value labelled as HTTPD_ROOT.

During the installation, a version-specific registry key is created in the Windows registry. The location of this key depends on the type of the installation. If you chose to install Apache for all users, the key is located under the HKEY_LOCAL_MACHINE hive, like this (the version numbers will of course vary between different versions of Apache:

HKEY_LOCAL_MACHINESOFTWAREApache GroupApache2.0.43

Correspondingly, if you chose to install Apache for the current user only, the key is located under the HKEY_CURRENT_USER hive, the contents of which are dependent of the user currently logged on:

HKEY_CURRENT_USERSOFTWAREApache GroupApache2.0.43

This key is compiled into the server and can enable you to test new versions without affecting the current version. Of course, you must take care not to install the new version in the same directory as another version.

If you did not do a binary install, Apache will in some scenarios complain about the missing registry key. This warning can be ignored if the server was otherwise able to find its configuration file.

The value of this key is the ServerRoot directory which contains the conf subdirectory. When Apache starts it reads the httpd.conf file from that directory. If this file contains a ServerRoot directive which contains a different directory from the one obtained from the registry key above, Apache will forget the registry key and use the directory from the configuration file. If you copy the Apache directory or configuration files to a new location it is vital that you update the ServerRoot directive in the httpd.conf file to reflect the new location.

Testing the Installation

After starting Apache (either in a console window or as a service) it will be listening on port 80 (unless you changed the Listen directive in the configuration files or installed Apache only for the current user). To connect to the server and access the default page, launch a browser and enter this URL:

Apache should respond with a welcome page and a link to the Apache manual. If nothing happens or you get an error, look in the error.log file in the logs subdirectory. If your host is not connected to the net, or if you have serious problems with your DNS (Domain Name Service) configuration, you may have to use this URL:

If you happen to be running Apache on an alternate port, you need to explicitly put that in the URL:

Once your basic installation is working, you should configure it properly by editing the files in the conf subdirectory. Again, if you change the configuration of the Windows NT service for Apache, first attempt to start it from the command line to make sure that the service starts with no errors.

Because Apache cannot share the same port with another TCP/IP application, you may need to stop, uninstall or reconfigure certain other services before running Apache. These conflicting services include other WWW servers and some firewall implementations.

The script content on this page is for navigation purposes only and does not alter the content in any way.

The following sections describe how to install and configure the Apache HTTP Server Plug-In:

Overview of the Apache HTTP Server Plug-In

The Apache HTTP Server Plug-In allows requests to be proxied from an Apache HTTP Server to WebLogic Server. The plug-in enhances an Apache installation by allowing WebLogic Server to handle requests that require the dynamic functionality of WebLogic Server.

The plug-in is intended for use in an environment where an Apache Server serves static pages, and another part of the document tree (dynamic pages best generated by HTTP Servlets or JavaServer Pages) is delegated to WebLogic Server, which may be operating in a different process, possibly on a different host. To the end user—the browser—the HTTP requests delegated to WebLogic Server still appear to be coming from the same source.

HTTP-tunneling, a technique which allows HTTP requests and responses access through a company's firewall, can also operate through the plug-in, providing non-browser clients access to WebLogic Server services.

The Apache HTTP Server Plug-In operates as an Apache module within an Apache HTTP Server. An Apache module is loaded by Apache Server at startup, and then certain HTTP requests are delegated to it. Apache modules are similar to HTTP servlets, except that an Apache module is written in code native to the platform.

For information on configurations on which the Apache HTTP Server Plug-In is supported, see http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html.

Note:

Apache 2.0 Plug-In was deprecated in the WebLogic Server 10.0 release.

Keep-Alive Connections in Apache Version 2.0

Version 2.0 of the Apache HTTP Server Plug-In improves performance by using a reusable pool of connections from the plug-in to WebLogic Server. The plug-in implements HTTP 1.1 keep-alive connections between the plug-in and WebLogic Server by reusing the same connection in the pool for subsequent requests from the same client. If the connection is inactive for more than 20 seconds, (or a user-defined amount of time) the connection is closed and removed from the pool. You can disable this feature if desired. For more information, see KeepAliveEnabled in Table 7-1.

Proxying Requests

The plug-in proxies requests to WebLogic Server based on a configuration that you specify. You can proxy requests based on the URL of the request (or a portion of the URL). This is called proxying by path. You can also proxy requests based on the MIME type of the requested file. Or you can use a combination of the two methods. If a request matches both criteria, the request is proxied by path. You can also specify additional parameters for each type of request that define additional behavior of the plug-in. For more information, see Configuring the Apache HTTP Server Plug-In.

Apache 2.2

Although this document refers to Apache 2.0, you can apply the same instructions to use Apache 2.2 with the libraries shown in Table 3-2.

Certifications

The Apache HTTP Server Plug-In is supported on AIX, Linux, Solaris, Windows, and HPUX11 platforms. For information on support for specific versions of Apache, see http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html.

Installing the Apache HTTP Server Plug-In

The Apache HTTP Server Plug-In is included with WebLogic Server under the WL_HOME/server/plugin directory.

You can install the Apache HTTP Server Plug-In as an Apache module in your Apache HTTP Server installation and link it as a Dynamic Shared Object (DSO).

A DSO is compiled as a library that is dynamically loaded by the server at run time, and can be installed without recompiling Apache.

Installing the Apache HTTP Server Plug-In as a Dynamic Shared Object

The Apache plug-in is distributed as a shared object (.so) for Solaris, Linux, AIX, Windows, and HPUX11 platforms.

Note:

The WebLogic Server version 10.3 installation did not include the Apache HTTP server plug-ins. The Apache HTTP Server plug-ins are available in a separate zip file, available from the Oracle download and support sites. These plug-ins contain a fix for the security advisory described at:

http://www.oracle.com/technology/deploy/security/alerts/alert_cve2008-3257.html

After downloading the zip file, extract the zip to a directory of your choice on disk.

Table 3-1 shows the directories that contain shared object files for various platforms.

Table 3-2 identifies the WebLogic Server Apache Plug-In modules for different versions of Apache HTTP Server and different encryption strengths.

Table 3-1 Locations of Plug-In Shared Object Files

Operating System	Shared Object Location Under WL_HOME/server/plugin
AIX	aix/ppc
Solaris	solaris/sparc solaris/sparc/largefile^{Foot 1} solaris/x86 solaris/x86/largefile^{Foot 2}
Linux	linux/i686 linux/i686/largefile^{Foot 3} linux/ia64 linux/x86_64
Windows (Apache 2.0 and 2.2, 32-bit)	win32
HPUX11	hpux11/IPF64 hpux11/PA_RISC Note: If you are running Apache 2.0.x server on HP-UX11, set the environment variables specified immediately below before you build the Apache server. Because of a problem with the order in which linked libraries are loaded on HP-UX, a core dump can result if the load order is not preset as an environment variable before building. Set the following environment variables before proceeding with the Apache configure, make, and make install steps, (described in Apache HTTP Server documentation at `http://httpd.apache.org/docs-2.1/install.html#configure`):

^{Footnote 1}See 'Support for Large Files in Apache 2.0'

^{Footnote 2}See 'Support for Large Files in Apache 2.0'

^{Footnote 3}See 'Support for Large Files in Apache 2.0'

Choose the appropriate version of the plug-in shared object from the following table:

Table 3-2 Apache Plug-In Shared Object File Versions

Apache Version	Regular Strength Encryption	128-bit Encryption
Standard Apache Version 2.0.x	mod_wl_20.so	mod_wl128_20.so
Standard Apache Version 2.2.x	mod_wl_22.so	mod_wl128_22.so

To install the Apache HTTP Server Plug-In as a dynamic shared object:

Locate the shared object directory for your platform using Table 3-1.
Note:
Before making your selection, please review Support for Large Files in Apache 2.0.
Identify the plug-in shared object file for your version of Apache in Table 3-2.
Verify that the WebLogic Server Apache HTTP Server Plug-In mod_so.c module is enabled.
The Apache HTTP Server Plug-In will be installed in your Apache HTTP Server installation as a Dynamic Shared Object (DSO). DSO support in Apache is based on module mod_so.c, which must be enabled before mod_wl_20.so is loaded. If you installed Apache HTTP Server using the script supplied by Apache, mod_so.c is already enabled. Verify that mod_so.c is enabled by executing the following command:
(Where APACHE_HOME is the directory containing your Apache HTTP Server installation.)
This command lists all enabled modules. If mod_so.c is not listed, you must rebuild your Apache HTTP Server, making sure that the following options are configured:
See Apache 2.0 Shared Object (DSO) Support at http://httpd.apache.org/docs/2.0/dso.html.
Install the Apache HTTP Server Plug-In module for Apache 2.0.x by copying the mod_wl_20.so file to the APACHE_HOMEmodules directory and adding the following line to your APACHE_HOME/conf/httpd.conf file manually:
Define any additional parameters for the Apache HTTP Server Plug-In.
The Apache HTTP Server Plug-In recognizes the parameters listed in General Parameters for Web Server Plug-Ins. To modify the behavior of your Apache HTTP Server Plug-In, define these parameters:
- In a Location block, for parameters that apply to proxying by path, or
- In an IfModule block, for parameters that apply to proxying by MIME type.
Verify the syntax of the APACHE_HOMEconfhttpd.conf file with the following command:
The output of this command reports any errors in your httpd.conf file or returns:
Restart Weblogic Server.
Start (or restart if you have changed the configuration) Apache HTTP Server.
Test the plug-in by opening a browser and setting the URL to the Apache Server plus “/weblogic/”, which should bring up the default WebLogic Server HTML page, welcome file, or default servlet, as defined for the default Web Application on WebLogic Server. For example:

Support for Large Files in Apache 2.0

The version of Apache 2.0 that ships with some operating systems, including some versions of Solaris and Linux, is compiled with the following flags:

These compilation flags enable support for files larger than 2 GB. If you want to use a WebLogic Server Web server plug-in on such an Apache 2.0 Web server, you must use plug-ins compiled with the same compilation flags, which are available in the largefile subdirectory for your operating system. For example:

Note:

Apache 2.2 does not require special compilation flags to support files larger than 2 GB. Therefore, you do not need to use a specially compiled Web server plug-in if you are running Apache 2.2.

Configuring the Apache HTTP Server Plug-In

After installing the plug-in in the Apache HTTP Server, configure the WebLogic Server Apache Plug-In and configure the server to use the plug-in. This section explains how to edit the Apache httpd.conf file to instruct the Apache server to load the WebLogic Server library for the plug-in as an Apache module, and to specify the application requests that should be handled by the module.

Editing the httpd.conf File

Edit the httpd.conf file in your Apache HTTP server installation to configure the Apache HTTP Server Plug-In.

This section explains how to locate and edit the httpd.conf file, to configure the server to use the WebLogic Server Apache Plug-In, to proxy requests by path or by MIME type, to enable HTTP tunneling, and to use other WebLogic Server plug-in parameters.

Open the httpd.conf file.
The file is located at APACHE_HOMEconfhttpd.conf (where APACHE_HOME is the root directory of your Apache HTTP server installation). See a sample httpd.conf file at Setting Up Perimeter Authentication.
Ensure that the WebLogic Server modules are included for Apache 2.0.x, manually add the following line to the httpd.conf file:
Add an IfModule block that defines one of the following:
- For a non-clustered WebLogic Server: the WebLogicHost and WebLogicPort parameters.
- For a cluster of WebLogic Servers: the WebLogicCluster parameter.
For example:
To proxy requests by MIME type, add a MatchExpression line to the IfModule block. Note that if both MIME type and proxying by path are enabled, proxying by path takes precedence over proxying by MIME type.
For example, the following IfModule block for a non-clustered WebLogic Server specifies that all files with MIME type .jsp are proxied:
You can also use multiple MatchExpressions, for example:
If you are proxying requests by MIME type to a cluster of WebLogic Servers, use the WebLogicCluster parameter instead of the WebLogicHost and WebLogicPort parameters. For example:
To proxy requests by path, use the Location block and the SetHandler statement. SetHandler specifies the handler for the Apache HTTP Server Plug-In module. For example the following Location block proxies all requests containing /weblogic in the URL:
The PathTrim parameter specifies a string trimmed from the beginning of the URL before the request is passed to the WebLogic Server instance (see General Parameters for Web Server Plug-Ins).
Optionally, enable HTTP tunneling for t3 or IIOP.
1. To enable HTTP tunneling if you are using the t3 protocol and weblogic.jar, add the following Location block to the httpd.conf file:
2. To enable HTTP tunneling if you are using the IIOP, the only protocol used by the WebLogic Server thin client, wlclient.jar, add the following Location block to the httpd.conf file:
Define any additional parameters for the Apache HTTP Server Plug-In.
The Apache HTTP Server Plug-In recognizes the parameters listed in General Parameters for Web Server Plug-Ins. To modify the behavior of your Apache HTTP Server Plug-In, define these parameters either:
- In a Location block, for parameters that apply to proxying by path, or
- In an IfModule block, for parameters that apply to proxying by MIME type.

Placing WebLogic Properties Inside Location or VirtualHost Blocks

If you choose to not use the IfModule, you can instead directly place the WebLogic properties inside Location or VirtualHost blocks. Consider the following examples of the Location and VirtualHost blocks:

Including a weblogic.conf File in the httpd.conf File

Make Apache Server Https

If you want to keep several separate configuration files, you can define parameters in a separate configuration file called weblogic.conf file, by using the Apache Include directive in an IfModule block in the httpd.conf file:

The syntax of weblogic.conf files is the same as that for the httpd.conf file.

This section describes how to create weblogic.conf files, and includes sample weblogic.conf files.

Creating weblogic.conf Files

Be aware of the following when constructing a weblogic.conf file.

Enter each parameter on a new line. Do not put '=' between a parameter and its value. For example:
If a request matches both a MIME type specified in a MatchExpression in an IfModule block and a path specified in a Location block, the behavior specified by the Location block takes precedence.
If you use an Apache HTTP Server <VirtualHost> block, you must include all configuration parameters (MatchExpression, for example) for the virtual host within the <VirtualHost> block (see Apache Virtual Host documentation at http://httpd.apache.org/docs/vhosts/).
If you want to have only one log file for all the virtual hosts configured in your environment, you can achieve it using global properties. Instead of specifying the same Debug, WLLogFile and WLTempDir properties in each virtual host you can specify them just once in the <IfModule> tag.
Sample httpd.conf file:
All the requests which match /jurl/* will have Debug Level set to ALL and log messages will be logged to c:/tmp/global_proxy.log file. All the requests which match /web/* will have Debug Level set to OFF and no log messages will be logged. All the requests which match /foo/* will have Debug Level set to ERR and log messages will be logged to c:/tmp/foo_proxy.log file.
Oracle recommends that you use the MatchExpression statement instead of the <Files> block.

Sample weblogic.conf Configuration Files

The following examples of weblogic.conf files may be used as templates that you can modify to suit your environment and server. Lines beginning with # are comments.

In Example 3-2, the MatchExpression parameter syntax for expressing the filename pattern, the WebLogic Server host to which HTTP requests should be forwarded, and various other parameters is as follows:

The first MatchExpression parameter below specifies the filename pattern *.jsp, and then names the single WebLogicHost. The paramName=value combinations following the pipe symbol specify the port at which WebLogic Server is listening for connection requests, and also activate the Debug option. The second MatchExpression specifies the filename pattern *.http and identifies the WebLogicCluster hosts and their ports. The paramName=value combination following the pipe symbol specifies the error page for the cluster.

Example 3-2 Example Using Multiple WebLogic Clusters

Example 3-3 shows an example without WebLogic clusters.

Example 3-4 shows an example of configuring multiple name-based virtual hosts.

Example 3-4 Example Configuring Multiple Name-Based Virtual Hosts

Carnivores dinosaur hunter mac. You must define a unique value for ServerName or some Plug-In parameters will not work as expected.

Template for the Apache HTTP Server httpd.conf File

This section contains a sample httpd.conf file for Apache 2.0. You can use this sample as a template and modify it to suit your environment and server. Lines beginning with # are comments.

Note that Apache HTTP Server is not case sensitive.

Setting Up Perimeter Authentication

Use perimeter authentication to secure WebLogic Server applications that are accessed via the Apache Plug-In.

A WebLogic Identity Assertion Provider authenticates tokens from outside systems that access your WebLogic Server application, including users who access your WebLogic Server application through the Apache HTTP Server Plug-In. Create an Identity Assertion Provider that will safely secure your Plug-In as follows:

Create a custom Identity Assertion Provider on your WebLogic Server application. See 'How to Develop a Custom Identity Assertion Provider' in Developing Security Providers for Oracle WebLogic Server.
Configure the custom Identity Assertion Provider to support the Cert token type and make Cert the active token type. See 'How to Create New Token Types' in Developing Security Providers for Oracle WebLogic Server.
Set clientCertProxy to True in the web.xml deployment descriptor file for the Web application (or, if using a cluster, optionally set the Client Cert Proxy Enabled attribute to true for the whole cluster on the Administration Console Cluster-->Configuration-->General tab). The clientCertProxy attribute can be used with a third party proxy server, such as a load balancer or an SSL accelerator, to enable 2-way SSL authentication. For more information about the clientCertProxy attribute, see 'context-param' in Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server.
Once you have set clientCertProxy, be sure to use a connection filter to ensure that WebLogic Server accepts connections only from the machine on which the Apache Plug-In is running. See 'Using Network Connection Filters' in Programming Security for Oracle WebLogic Server.
Web server plug-ins require a trusted Certificate Authority file in order to use SSL between the plug-in and WebLogic Server. Use Sun Microsystems' keytool utility to export a trusted Certificate Authority file from the DemoTrust.jks keystore file that resides in WL_HOME/server/lib.
1. To extract the wlsdemoca file, for example, use the command:
  Change the alias name to obtain a different trusted CA file from the keystore.
  To look at all of the keystore's trusted CA files, use:
  Press enter if prompted for password.
2. To convert the Certificate Authority file to pem format: java utils.der2pem trustedcafile.der

See 'Identity Assertion Providers' in Developing Security Providers for Oracle WebLogic Server.

Using SSL with the Apache Plug-In

You can use the Secure Sockets Layer (SSL) protocol to protect the connection between the Apache HTTP Server Plug-In and WebLogic Server. The SSL protocol provides confidentiality and integrity to the data passed between the Apache HTTP Server Plug-In and WebLogic Server.

The Apache HTTP Server Plug-In does not use the transport protocol (http or https) specified in the HTTP request (usually by the browser) to determine whether or not the SSL protocol is used to protect the connection between the Apache HTTP Server Plug-In and WebLogic Server.

Although two-way SSL can be used between the HTTP client and Apache HTTP server, note that one-way SSL is used between Apache HTTP Server and WebLogic Server.

Configuring SSL Between the Apache HTTP Server Plug-In and WebLogic Server

To use the SSL protocol between Apache HTTP Server Plug-In and WebLogic Server:

Configure WebLogic Server for SSL. For more information, see Configuring SSL.
Configure the WebLogic Server SSL listen port. For more information, see Configuring SSL.
In the Apache Server, set the WebLogicPort parameter in the httpd.conf file to the WebLogic Server SSL listen port configured in Step 2.
In the Apache Server, set the SecureProxy parameter in the httpd.conf file to ON.
Set any additional parameters in the httpd.conf file that define information about the SSL connection. For a complete list of the SSL parameters that you can configure for the plug-in, see SSL Parameters for Web Server Plug-Ins.

Issues with SSL-Apache Configuration

These known issues arise when you configure the Apache plug-in to use SSL:

To prepare the plug-in configuration, using Internet Explorer click the lock and go to the certificates path:
- Select the root CA (at the top).
- Display it.
- Detail and then copy this certificate (using the export wizard) to a file using the Coded 'Base 64 X509' option.
- Save the file, for example, to 'MyWeblogicCAToTrust.cer' (which is also a PEM file).
The PathTrim parameter (see SSL Parameters for Web Server Plug-Ins ) must be configured inside the <Location> tag.
The following configuration is incorrect:
The following configuration is the correct setup:
The current implementation of the WebLogic Server Apache Plug-In does not support the use of multiple certificate files with Apache SSL.

Connection Errors and Clustering Failover

When the Apache HTTP Server Plug-In attempts to connect to WebLogic Server, the plug-in uses several configuration parameters to determine how long to wait for connections to the WebLogic Server host and, after a connection is established, how long the plug-in waits for a response. If the plug-in cannot connect or does not receive a response, the plug-in attempts to connect and send the request to other WebLogic Server instances in the cluster. If the connection fails or there is no response from any WebLogic Server in the cluster, an error message is sent.

Figure 3-1 demonstrates how the plug-in handles failover.

Possible Causes of Connection Failures

Failure of the WebLogic Server host to respond to a connection request could indicate the following problems:

Physical problems with the host machine
Network problems
Other server failures

Failure of all WebLogic Server instances to respond could indicate the following problems:

WebLogic Server is not running or is unavailable
A hung server
A database problem
An application-specific failure

Tuning to Reduce Connection_Refused Errors

Under load, an Apache plug-in may receive CONNECTION_REFUSED errors from a back-end WebLogic Server instance. Follow these tuning tips to reduce CONNECTION_REFUSED errors:

Increase the AcceptBackLog setting in the configuration of your WebLogic Server domain.
On Apache 2.0.x, set the KeepAlive directive in the httpd.conf file to On. For example:
See Apache HTTP Server 2.0 documentation at http://httpd.apache.org/docs-project/.
Decrease the time wait interval. This setting varies according to the operating system you are using. For example:
- On Windows NT, set the TcpTimedWaitDelay on the proxy and WebLogic Server servers to a lower value. Set the TIME_WAIT interval in Windows NT by editing the registry key under HKEY_LOCAL_MACHINE:
  If this key does not exist you can create it as a DWORD value. The numeric value is the number of seconds to wait and may be set to any value between 30 and 240. If not set, Windows NT defaults to 240 seconds for TIME_WAIT.
- On Windows 2000, lower the value of the TcpTimedWaitDelay by editing the registry key under HKEY_LOCAL_MACHINE:
- On Solaris, reduce the setting tcp_time_wait_interval to one second (for both the WebLogic Server machine and the Apache machine, if possible):
Increase the open file descriptor limit on your machine. This limit varies by operating system. Using the limit (.csh) or ulimit (.sh) directives, you can make a script to increase the limit. For example:
On Solaris, increase the values of the following tunables on the WebLogic Server machine:

Failover with a Single, Non-Clustered WebLogic Server

If you are running only a single WebLogic Server instance the plug-in only attempts to connect to the server defined with the WebLogicHost parameter. If the attempt fails, an HTTP 503 error message is returned. The plug-in continues trying to connect to that same WebLogic Server instance for the maximum number of retries as specified by the ratio of ConnectTimeoutSecs and ConnectRetrySecs.

The Dynamic Server List

The WebLogicCluster parameter is required to proxy to a list of back-end servers that are clustered, or to perform load balancing among non-clustered managed server instances.

In the case of proxying to clustered managed servers, when you use the WebLogicCluster parameter in your httpd.conf or weblogic.conf file to specify a list of WebLogic Servers, the plug-in uses that list as a starting point for load balancing among the members of the cluster. After the first request is routed to one of these servers, a dynamic server list is returned containing an updated list of servers in the cluster. The updated list adds any new servers in the cluster and deletes any that are no longer part of the cluster or that have failed to respond to requests. This list is updated automatically with the HTTP response when a change in the cluster occurs.

Mysql

Failover, Cookies, and HTTP Sessions

When a request contains session information stored in a cookie or in the POST data, or encoded in a URL, the session ID contains a reference to the specific server instance in which the session was originally established (called the primary server). A request containing a cookie attempts to connect to the primary server. If that attempt fails, the plug-in attempts to make a connection to the next available server in the list in a round-robin fashion. That server retrieves the session from the original secondary server and makes itself the new primary server for that same session. See Figure 3-1.

Note:

If the POST data is larger than 64K, the plug-in will not parse the POST data to obtain the session ID. Therefore, if you store the session ID in the POST data, the plug-in cannot route the request to the correct primary or secondary server, resulting in possible loss of session data.

Https Apache Server

Figure 3-1 Connection Failover

Description of 'Figure 3-1 Connection Failover'

Apache Http Server Version 2.0 Login

Apache Http Server 2.0 End Of Support

In this figure, the Maximum number of retries allowed in the red loop is equal to ConnectTimeoutSecs/ConnectRetrySecs.