Chapter 4: Apache
|
| < Day Day Up > |
|
Oracle E-Business Suite uses as its Internet engine a scaled down version of the Oracle 9iAS product. The full installation of 9iAS is a suite of products including a Web server, security features, and many add-on modules to assist you in your job of serving Web content to your customers. Oracle Financials version is scaled down, with fewer bells and whistles, but is still a complex set of products.
Oracle HTTP Server
At the core of Oracle's 9iAS product (either the scaled down or the full, robust version) is Oracle's version of its HTTP Server, a simple Web server based on the Apache Web Server. Apache documentation is widely available and there are several good books available if you want to know, in depth, what Apache is about, what it does, and what you can do with all of its features. Here we will touch on what core components you will need to be aware of and to some extent comfortable with, as they apply to the Oracle E-Business Suite.
Running the Apache version that ships with Oracle E-Business Suite does not require that you know all there is to know about Apache, only the pieces that you are likely to be concerned with on a somewhat routine basis. This chapter will, among other things, give you the information that you will need to maintain and configure this Apache-based set of services and help you troubleshoot some problems that you may find along the way.
Figure 4.1 shows, graphically, the basic directory structure that your Vision or other installation may have. You can extrapolate from here for your other environments.
Figure 4.1: Directory Structure
There are several files directly related to Apache that you will need to work with. Some are configuration files, some security files, and some are your logs. All are in the directories under /visora/iAS/Apache/Apache and usually located in the logically named subdirectories. The primary configuration file, and the file from which all of the other configuration files get called, is the httpd.conf file. A basic understanding of this file and what directives and containers are in it will help you to understand some of what is going on with Apache and will help you if you should need to open an iTAR with Oracle Support about anything with the Apache setup.
Running as an integral part of Apache is an include module called mod_jserv.so or just JServ. JServ, an open source servlet engine, brings with it the ability to communicate and accept servlet requests and to perform extensive Java related tasks through the Applications interface. The JVM™ (Java Virtual Machine) interface that runs is called JServer. While the Oracle HTTP Server that runs in the Oracle E-Business Suite is not as broadly functional as the one that runs within 9iAS V9.0.2, it brings with it full functionality and the ability to expand the capabilities of your server and to grow as the product suite and certification grows. While the engine behind Version 9.0.2 of the Application Server is Oracle 9iAS Containers for J2EE (OC4J), JServ was the primary servlet environment in earlier releases of Oracle 9i Application Server (1.0.2.2.2 is a case in point). The flexibility that it brings to the configuration, though, does not come without complexity to configuration interaction.
The configuration files are made up of variables and directives. A directive is a command that conveys information to the Apache server on specific actions to take in certain situations.
Httpd.conf
The httpd.conf file is one of the primary configuration files for your Apache service. It is a long file divided into three sections and each section has configurable parameters. Each section has a narrower focus than the section before, starting out with the overall operations and narrowing to the narrowest parameters. The values and variables found within this file and the files that it calls build upon each other. This file is commented somewhat extensively; however, if you do not know anything about what you are doing to begin with, you could soon find yourself lost in the somewhat terse, often limited information.
Global Environment
Section 1 is the Global Environment section. This section's directives affect how Apache operates overall. Things in this section tell Apache, mostly, about itself: where to find its log and configuration files, how many requests it can handle concurrently, and other things about its global environment.
ServerType
The ServerType variable can only ever have one of two values. If you are running on a Windows platform, you can only have one of the two. A Windows ServerType has to have a value of standalone; a UNIX platform can either be standalone or inetd.
ServerType Standalone
ServerRoot
The ServerRoot directive gives the uppermost directory under which Apache and its files can be found. It is important that the path not end with a trailing slash. Also important, do not alter the direction which the slashes appear in the path. If you are maintaining a Windows environment, the path may look odd, but it needs to stay that way.
ServerRoot "d:\visora\iAS/Apache/Apache"
LockFile
The LockFile directive specifies the full path, including the filename, to the LockFile. The LockFile is a file that Apache uses if it has been compiled with either the USE_FCNTRL_SERIALIZED_ACCEPT or the USE_FLOCK_SERIALIZED_ACCEPT parameter. Very often, this directive will be commented out. This directive is best left at its original value in this file; alter it only if the value in the ServerRoot directive is to be NFS (network file system) mounted. The LockFile has to be stored on a local disk and never on a NFS disk. If you need to find somewhere local to locate this file, it is best not to locate this file in a directory to which everyone has write access (like /var/temp or /usr/tmp). Putting this file in a location to which the world can freely write could leave your company open to denial of service attack. Again, make a note to not change the direction of the slashes after the iAS directory.
LockFile d:\visora\iAS/Apache/Apache/logs/httpd.lock
PidFile
The PidFile directive specifies a log file in which the server records the process identification (pid) number under which it was started. You can "more" this file from a command prompt through either UNIX or the MKS toolkit, or you can make a copy of it and open the copy if you are on a Windows machine. You cannot open the file directly. Do not try to edit this file. Again, never change the direction of the slashes in the directory paths in any of these directives.
PidFile d:\visora\iAS/Apache/Apache/logs/httpd.pid
ScoreBoardFile
The ScoreBoardFile directive specifies a log file containing information on internal server processes. It is a file that Apache uses to communicate between the parent server processes and any child processes. This file (and therefore this directive) is not required on every platform. The easiest way to find out if it is required on your platform is to start Apache and determine if the file is created. If it is created, it is needed. This file is created in the logs directory of the ServerRoot with all of the other log files. If you have multiple Apache server processes running on your server and your platform requires a scoreboard file, it is important that each server process have its own scoreboard file and that the same scoreboard file is not written to by more than one instance of Apache.
ScoreBoardFile d:\visora\iAS/Apache/Apache/logs/httpd.scoreboard
ResourceConfig
The ResourceConfig directive specifies a configuration file that likely will not contain any directives. There are several of these files that are holdovers from previous versions of Apache. You will, in all likelihood, have one of these files, but it will probably contain only the header comments. All of the directives and their associated information that would have been in this file have been migrated over time to the httpd.conf file. You will find this file in the conf directory under ServerRoot. Srm.conf is not big and while it is not really used, I would probably not clean it up, but leave it where it is.
conf/srm.conf
AccessConfig
The AccessConfig directive specifies another configuration file that likely will not contain any directives. You will probably have one of these files as well, but it will contain only the header comments. All of the directives and their associated information that would have been in this file have been migrated over time to the httpd.conf file. You will find this file in the conf directory under ServerRoot. Access.conf is another small file that can be left in place.
conf/access.conf
Timeout
The Timeout directive is the number of seconds that Apache will wait for a get, put, or post command or the amount of time between ACKs (acknowledgments of TCP-IP packet receipt) before a time-out occurs. Apache has plans to break this out into several configurable directives, similar to this one, but one each for gets, for puts, for posts, and for ACKs.
Timeout 300
KeepAlive
The KeepAlive directive allows Apache to determine if it should allow persistent connections or not. A persistent connection is usually only implemented for pipelining data from one server to the requesting client. Typically, the Web server will close the connection after returning the data that is requested, although this is never apparent to the end user. If it is set to on, KeepAlive allows more than one request per connection, off will cause Apache to allow only one request per connection. Allowing multiple requests to be sent over the same TCP-IP (Transmission Control Protocol/Internet Protocol) connection can cause up to 50 percent lower latency times for HTML documents, particularly if the documents are graphic heavy. Because we are dealing with Oracle Financials, which is not graphics intensive, but is Java based, deciding to set this directive in either fashion is a judgment call based on network traffic more than anything. KeepAlive and the following two directives MaxKeepAlive Requests and KeepAliveTimeout should be addressed as a group.
KeepAlive On
MaxKeepAliveRequests
The MaxKeepAliveRequests directive value is the maximum number of requests that Apache will allow during persistent connections. If this is set to 0, it will allow an unlimited number of requests. This makes some kind of intuitive sense, as there is no apparent reason that anyone would want to run a Web server that allowed no one to connect. Setting a higher value for this directive allows for better performance. This directive limits the number of requests that Apache will allow per connection if the KeepAlive directive is set to on.
MaxKeepAliveRequests 500
KeepAliveTimeout
The KeepAliveTimeout directive sets the number of seconds that Apache will wait from the end of the current request to the arrival of the next request coming from the same client through the same connection. Once any request has been received, this value comes into play. Setting this number too high may cause performance problems, particulary in a server that is heavily loaded as more of the server processes will be dedicated to waiting for subsequent requests from idle clients than to accepting new requests.
KeepAliveTimeout 15
MinSpareServers and MaxSpareServers
The MinSpareServers and MaxSpareServers directives work together regulating the server pool size. Apache dynamically adapts to load by attempting to maintain enough server processes to handle that load. Apache will periodically query for the number of servers waiting for a request. If it determines that there are fewer idle child server processes than the value for MinSpareServers, it will create enough more child processes to bring the number up to this minimum value. If it determines that there are more idle processes than the value of MaxSpareServers, it allows those above this value to die off. The default settings are usually sufficient for most configurations and tuning should only ever potentially need to be done only on extremely busy sites.
One note to remember, these are spare servers. This means that they are not currently handling requests. Neither the MinSpareServers nor the MaxSpareServers parameter in any way affect the total maximum number of requests that can be handled by the server. Further, this directive has no effect on a Windows-based machine, so tuning the numbers if your Apache is running on Windows will have no effect and the defaults should be left alone.
MinSpareServers 5 MaxSpareServers 10
StartServers
The StartServers directive indicates the number of servers that Apache starts initially on startup. The number of servers started is dynamically controlled by Apache and is determined by load; therefore, the default should be reasonable. On a Windows server, this directive has no effect as there is always one child that handles all requests and each of those requests are handled by separate threads. ThreadsPerChild directive has a similar effect on Windows as this directive does on UNIX. Apache on Windows is somewhat less configurable than it is on other OSs.
StartServers 5
MaxClients
The MaxClients directive limits the total number of servers running and the number of clients that can connect simultaneously. If this number of consecutive live connections is ever reached, subsequent connection attempts will be locked out. Typically connections to your server will no longer be active after the completion of a put or a get command. Setting this directive too low can have adverse effects on your implementation particularly if your implementation in any way sits on the Internet and is accessible by outside clients. Those connection attempts that try and are locked out will typically be queued up and handled by a child process after it is freed up. The maximum number that can be queued up is based on the ListenBacklog directive. The MaxClients directive acts as a brake to keep a runaway server from taking the system down. If you need to configure Apache to handle more than 256 clients, you will need to edit HARD_SERVER_LIMIT entry in the httpd.h header file and recompile Apache.
MaxClients 150
MaxRequestsPerChild
The MaxRequestsPerChild directive is the number of requests that each child is allowed to process before that child dies. The child process will elegantly exit so that there are no problems connected to prolonged use. Problems associated with allowing a single child process to handle too many requests are often connected to memory leaks or other resources problems, particularly in the libraries. Although this directive is not usually needed, there are some places where it will help. Assigning a finite value to this directive will reduce the number of processes that remain after the load is reduced on a busy server. A value of 0 for this directive means that there are unlimited requests. Setting the value to around 1000 or 1500 should be sufficient for most configurations. It is important to note that this value does not include the KeepAlive requests. For example, if a child process receives an initial request, then 15 or 20 subsequent requests from the same client over the same connection, would count as one request toward that child reaching this value. On a Windows platform, it is strongly advised that this directive be set to 0 (unlimited) because if a non-0 value is ever reached, the child process (the only child process remember, all processes are then handled by thread) dies and needs to be respawned, requiring a reread the configuration files. While the time involved would be minimal with this action, it could result in unexpected behavior if there are modifications to any of the configuration files that were not intended to be implemented yet.
MaxRequestsPerChild 1000
Listens
The Listens directive allows you to instruct Apache to listen to specific IP (Internet Protocol) address and port combinations in addition to the default. This is redefining the default action of listening to all IP interfaces on the port assigned in the Port directive. Listen can be used instead of BindAddress and Port combinations. If you assign Listen the value of a port only, it will listen to the newly assigned port (or ports) on all IP interfaces instead of just the port given in the Port directive. To avoid denial of service problems you can use IP addresses in the Listen directive. The first example shows a configuration listening to all IP interfaces on two separate ports:
Listen 80 Listen 8000
If you want to limit the server to accepting connections to two IP interfaces, one with port 80, the other on port 8000, your Listen directive would look like the following:
Listen 12.34.56.78:80 Listen 12.34.56.72:8000
BindAddress
The BindAddress directive gives you the ability to support virtual hosts. It is used to tell the server which IP address to listen on. It can contain a "*" (listen to all IP addresses), an IP address, or a fully qualified Internet domain name.
BindAddress *
Dynamic Shared Object Support
Apache is a modular program that allows you, the administrator, to choose the functionality to be included in the server by selecting a set of modules that bring the functionality with them that is required by the implementation. These modules can be compiled into the Apache binary, requiring a recompile if additional modules need to be added, or they can be compiled as Dynamic Shared Objects (DSO) that exist independent of the binary file, after the server has been built, by using the Apache Extension Tool (axps).
There are modules that are minimally required to be compiled into the binaries and others that can be allowed to stand alone. It is required that a module, mod_so.c and the main body module, core.c be compiled statically into Apache's core. Mod_so.c and core.c are the only two modules that have to be compiled into the core file and cannot be put into the DSO directive. Once the initial compilation including the mod_so.c module is complete, other modules can be placed into a DSO. Enabling this functionality is accomplished via Apache's configuration command -enable-<module>=shared option. Once the module is compiled in this manner, it will be a file with the naming convention mod_<module>.so that can be loaded dynamically into Apache runtime via the LoadModule directive in the httpd.conf file (this is a directive that comes with the mod_so.c module) at startup or restart.
DSO has several advantages. Flexibility is the chief advantage. By using these objects, you can run different server instances (e.g., standard Apache, secure SSL version, minimal server, PHP2, mod_per version, etc.) with a single installation. Pulling in third party modules to add features and flexibility easily extends what Apache can do. Some of these modules can include mod_plsql (required for running many of the Applications programs), mod_perl, and mod_fastcgi.
Not all platforms support dynamic loading of code into the address space. Because Apache pulls these modules in at runtime, it has to resolve symbolic links if they exist.
ExtendedStatus
The ExtendedStatus directive controls Apache's choice to provide full status information or to simply generate basic status information when the server-status handler gets called. Default is off. Off has the effect of leaving the ExtendedStatus directive commented out. The detailed information returned and the values of ExtendedStatus required for it to be returned are found in Table 4.1.
| Status Information | ExtendedStatus Setting Required |
|---|---|
| Number of children serving requests | Off or on |
| Number of idle children | Off or on |
| Server time started (or restarted) and the total time it has been running | Off or on |
| Status of each child | On |
| Number of requests that child has performed and the total number of bytes served by the child | On |
| Number of accesses and bytes served | On |
| Average number of requests per second | On |
| Number of bytes served per second | On |
| Average number of bytes per request | On |
| Current per child CPU percentage | On |
| Total CPU percentage used by Apache | On |
| Current hosts and requests being processed by each | On |
ExtendedStatus On
Main Server Environment
Section 2 of the httpd.conf file specifies the configuration of the main server. The main server is the one that picks up all requests that are not picked up by a virtual host definition. The directives and values in this section also give defaults to any containers that could be used by a virtual host later on. This will provide a default expected action, but will allow for the flexibility of adding custom configurations for each additional virtual host. Any directives in this section could be found inside of a virtual host (<Virtual Host>) definition in Section 3. Redefining the directives in the Virtual Host section overrides the settings and values in the Main Server Environment directives.
Port
The Port directive specifies which port the server listens on. This directive gets configured during your installation and, unless you are running more than one instance of Apache on your server, it will likely never need to be altered. If you intend to run on ports with numbers lower than 1023, you will need to run Apache Web Server initially as root (on UNIX) or as administrator (Windows). If you are running with a ServerType directive of inetd on UNIX, this directive will have no effect.
Port 11111
User/Group
The User/Group directive set specifies the name or number of the user and group that will be used to run Apache. On Sun, you should specify User "nouser" and Group "nogroup." On HP-UX, you may or may not be able to use shared memory as "nobody." There is a suggested workaround if this is the case. You will need to create User "www" and use that user as the one who will run Apache. If you want Apache to run as a different user or group than these values, you will need to start Apache as root or administrator (for Windows) initially, allowing it to be switched later. Be extremely cautious. Some UNIX version kernels refuse to set the group (setgid) or IPC_SET (semctl) to an unsigned Group value over 60,000. If you find this to be the case in your system, do not use the Group "nobody." If you are running with a ServerType directive of inetd on UNIX, this directive will have no effect.
User nobody Group nobody
ServerAdmin
The ServerAdmin directive can be used to set the default e-mail address that is included in some of the error messages and pages that the server generates. It is through this mechanism that users outside your immediate company accessing your server will know who to contact and know how to contact you if they encounter problems. Leaving it at the default will provide you with fewer sleepless moments, but presents a highly unprofessional front.
ServerAdmin you@yourcompany.com
ServerName
The ServerName directive is what you would use if you were planning on setting up a server with the canonical name of something other than what you wanted to use for Web services. It is a common practice to name the server one thing, but to alias it in a Domain Name System (DNS) server with another name. This allows you to list your Web service under one name while maintaining any actual named server machines under that alias in DNS and changing out the server as needed. This not only provides you with an ability to switch out servers easier, but also allows for some obfuscation of names, adding a potential layer of security. It also allows you to maintain a duplicate backup server and allows the sysadmins to perform upgrades on servers transparently; it also allows you to restore your server to another machine at another site in the event of a disaster and not be concerned with the true server's name and then you can switch it back again at the home site. The ServerName directive in the httpd.conf file sets the host name of the server, further allowing redirection URLs. If there is no value set in this directive, the server tries to extrapolate the server's name from its own IP address. While this may work in theory, it is likely not going to work in all cases and the name that it may return may not be the preferred host name of the server. If you are using name-based virtual hosts, specifying the ServerName inside of the <VirtualHost> directive body specifies what host name will be needed in the requests Host:Port header to match the particular virtual host.
Remember, you cannot just invent host names and put them in this directive and hope they work. You have to have defined in DNS a valid name for your host even if there is no alias for it. If you do not understand how DNS works and you do not know what valid names your server can take on, work with your network administrators to either create one that you both agree on or determine one that has already been assigned. If there is not currently a valid value in DNS for your server, other than its canonical name, you can place its IP address here for the value of the directive. Anyone, including all end users of your system, will then need to access Apps using this address.
ServerName myserver.mydomain.mycompany.com
DocumentRoot
When Apache decides what file to serve for a given request, its default behavior is to append the URL path for the request to the trailing end of the value specified in this directive. The DocumentRoot directive, therefore, sets the uppermost directory in the tree out of which Apache will serve its Web pages. If this directive is coupled with the ServerName directive, it will alias the path to the pages with the name specified in the ServerName; otherwise, it will append the path from the requested URL to the document root. This is only the default directory out of which Apache will serve pages. You can use symbolic links and further aliases to point to other locations from which you want to serve them. It is important that you not end the value for this directive with a trailing "/." A different DocumentRoot can be specified for different virtual hosts.
DocumentRoot "d:\viscomn\portal"
To allow for different levels of security at the Apache level, each directory that Apache can access can be configured differently with respect to what services and features are enabled or disabled based on directory (and applying to its subdirectories). Initially, you configure the default value to be very restrictive with respect to what is and is not allowed.
It is important here to remember that you are, at this point, setting many values to disabled. You will need to enable them deliberately further on. If things do not work as anticipated, you may need to check that the functionality has been enabled.
The first directive set says that from the root directory no one is allowed to follow symbolic links:
<Directory/> Options FollowSymLinks AllowOverride None </Directory>
Now, you set your document root up to allow the ability to list an index of all files in your directory tree. This directive will give anyone who wants it the ability to list all of the files in your directory tree. This may have its advantages, in that it allows easy drill down access to find files via a browser, but remember that this also gives people the ability to find any files via a browser and gain a broader understanding of your environment via the understanding of the way in which these accessible files are laid out. They may not have the ability to find the location of those files in any other way and someone malicious could find a way to exploit this ability.
Directory gives the upper bounds of the directory tree to which you are granting this ability.
The Options portion of the command is the explicit option or options that you are enabling. In this case, the ability to follow symbolic links.
AllowOverride controls which options the .htaccess file has the ability to override (these files are security files that can allow you to limit the access that any particular user or group of users might have).
Order controls the order in which to determine who is allowed to retrieve information from the server. By default, Apache allows access to everyone. Depending on your circumstances, this may or may not be the action that you would like it to take. You can use the Order parameter to limit access to certain information to a single machine, to a domain or subdomain, or any combination of those situations. Adding a line below Allow specifying Deny from 123.46 (if you had 123.45 and 123.46 as the two subnets that had machines that could access your Apps) would limit what the users of any machine with an IP of 123.46.*.* could see.
Allow specifies who explicitly can retrieve the information:
<Directory "d:\viscomn\portal"> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow, deny Allow from all </Directory>
UserDir
The UserDir directive sets a specific directory to append onto a user's home directory if a ~<user> type request is received. If the following were to be the entry for this directive, only user1, user2, and user3 would have a UserDir privilege due to the initial UserDir being designated as disabled. In many cases, Apache will allow you to determine that you will be granting access in the Least Privileges model. Least Privilege allows that users should only be granted the amount of privilege that will permit them to perform the given job but no more.
UserDir disabled UserDir enabled user1 user2 user3
If you wanted to allow all users to have this access ability except user4, user5, and user6, you would put in the following directives:
UserDir enabled UserDir disabled user4 user5 user6
This directive is, in all probability, commented out in your Apps Apache httpd.conf file and it would probably be best to leave it that way. Opening access up further than is necessary in the configuration of Apps Apache would be best left to contacting Oracle Support if it is necessary. Necessity would probably be tied to certain customization situations.
#UserDir public_html
The following code shows how to configure UserDir directive directories for a site where the specified directories are open for read-only access. This is a commented out example from a working httpd.conf file. It allows gets and posts (for posting from a form), but denies everyone from putting, deleting, patching, copying, moving, locking, or unlocking any files in that directory through that interface. It is only through the Web interface that this is true. If the files are accessible to too broad an audience at the server level, people will be able to perform these actions directly on the server.
#<Directory/home/*/public_html> # AllowOverride FileInfo AuthConfig Limit # Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec # <Limit GET POST OPTIONS PROPFIND> # Order allow,deny # Allow from all # </Limit> # <Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> # Order deny,allow # Deny from all # </Limit> #</Directory>
DirectoryIndex
The DirectoryIndex directive specifies a list of resources that Apache will look for in a client request for an index of a directory. Achieving this result is accomplished by placing a trailing "/" at the end of the URL string. Figure 4.2 shows the result of having the DirectoryIndex directive set to a file without a relative path and having the Options Index set in the DirectoryRoot such that a user could view an index of all of the files in the specified directory.
Figure 4.2: Results of a DirectoryIndex Directive
DirectoryIndex index.html
If your httpd.conf file set the DirectoryIndex value as above, then entering http://myserver/docs would return a value of http://myserver/docs/index.html if that file exists. If index.htm exists in that directory, but not index.html, or if no version exists in that directory, the result of a similar search can be seen in Figure 4.2, which lists all files in the respective directory.
If, however, users always specify a relative path, or a full valid path to a default file, even if the Options Index is set in the DirectoryRoot directive, they will have returned to them a valid Web page. This directive can take on several values if they are specified in a space-delimited list. If you make sure that in at least one of these places there is a valid default html file (index.htm or index.html), you will ensure that no one will be able to get directory listings of your whole directory structure by simply navigating through browser pages.
DirectoryIndex index.html index.txt/OA_HTML/US/index.html/OA_HTML/US/index.htm
AccessFileName
The AccessFileName directive specifies the name of the file for which Apache will look in each directory for any directory specific access control information. This feature can allow you to limit the access of any user or group of users to the contents of that directory. It is not necessary that the file be named .htaccess, this is what it is named by convention. Following conventions has its advantages and its disadvantages. Following conventions allows anyone walking into your environment to be able to quickly and easily gain understanding of some of the security measures that you have in place by determining the locations of these files and accessing the information that they contain. By the same logic, this means the same thing to anyone who would gain inappropriate access to the server and alter the contents of these files or determine what access people have to the different directory structures. If you want to name it .config or .secure or .buffy or .hank, you can name it whatever you want. As long as you maintain the same naming standard throughout, and put that name in the AccessFileName directive, you should not have any problems.
The .htaccess files provide a simple way to make configuration changes on a directory-by-directory basis. A file by this name and containing one or more configuration directives (and there are many directives that can be placed in it) is placed in a particular document directory. The directives apply to that directory and all of its subdirectories. The directives available to be placed in this file are many of the same directives that can be found in the major configuration files for Apache and JServ environments.
AccessFileName.htaccess
The .htaccess file is a simple text file just like httpd.conf file that is more of a script that Apache loads and runs than a simple file. The naming convention reflects the UNIX origination of Apache. Beginning with a dot (inferring that in UNIX environment it is typically somewhat hidden), .htaccess is the full filename. There is nothing before the dot and it does not get connected in any way to any other file. Similar to the .profile file, it just is.
Although placing a .htaccess file in a directory affects that directory and all subdirectories below it, you can change the control information in the lower directories by placing still more .htaccess files in those directories as well. Apache will locate the nearest .htaccess file and use that file's directives as the basis for its access control.
Before you go off and plant .htaccess everywhere, read through the following description and make sure you do not do anything redundant. It is possible to cause an infinite loop of redirects or errors if you place something too unusual in the .htaccess. There are three primary reasons that you should seriously consider not using an override file, despite how inviting it looks to directory-based access control.
One reason to avoid the use of an override file is the performance hit that can occur when one is used. When AllowOverride is set to allow the use of .htaccess files (whatever you choose to name them), Apache will look in every directory it accesses for a .htaccess file. Thus, permitting this file to be used once causes a performance hit (no matter how minimal in most cases, the overall degradation can be high on a busy site), whether or not you actually even use them. Also contributing to performance degradation is the fact that access files get loaded every time a document is requested. If there is not an access file in the directory that you are accessing a document from, Apache looks in all higher level directories in search of an access file that might have an affect on the contents of the current access directory. If there is such a file in the directory that you are accessing, it will check the upper level directories anyway to see if there might be a directive in one of their access files (there or not) that might impact the current directory. This means that if a user requests a file out of the /www/htdocs/example directory and this feature is enabled, Apache must look for all of the following files:
/.htaccess /www/.htaccess /www/htdocs/.htaccess /www/htdocs/example/.htaccess
Another consideration concerns security. By using this directive, you are permitting users to modify server configuration, which may result in situations and changes over which you have very little or no control. Carefully consider whether or not you really want to be giving users this privilege. While this may be granting more security that you intend, it may also be limiting a user's ability to accomplish a job, leading to the unnecessary logging of self-imposed support requests. While there are situations where I fully believe that iTARs and Metalink are very valuable tools, if there is any way to limit the need to deal with a support analyst, I am all for it.
Any directive and any measure that you can implement via a .htaccess file can be implemented via the httpd.conf configuration file. Since you have access to and control of that file, you should take advantage of the elegance and simplicity (and limit the holes and hits) that using one central file can provide.
Some sites do not allow use of .htaccess files, since (depending on what the files are doing) they can dramatically slow down a server that is overloaded with domains if they are all using .htaccess files. I cannot stress this enough: You need to make sure you are allowed to use .htaccess before you actually use it. Some things that the .htaccess file can do can compromise a server's configuration that has been specifically set up by the administrator, so do not get yourself into trouble.
| Caution | Your .htaccess file will not work if there is a blank line above the first line that you type in. Be careful when editing it; if one of the lines in the file is so long that the editor you are using has to wrap it down to the next line it may cause inconsistent results. |
The lines immediately following the AccessFileName directive (separated only by comments) prevent the contents of the .htaccess files from being viewed by clients via the Web. Because your .htaccess file contains control and authorization information for the directories on your server, you do not want most people to have access to this file for security reasons.
This directive says, "if I am using a .htaccess file, regardless of where that file is located, if the file starts with ".ht" do not let anyone view the contents." It is good to construct this directive in this manner, as many sites create password files that are often named something like .htpasswd and this directive will protect people from not only viewing the .htaccess file, but will also prevent them from unauthorized viewing of these other files as well.
<Files ~ "^\.ht"> Order allow,deny Deny from all </Files>
CacheNegotiatedDocs
The CacheNegotiatedDocs directive suggests to the proxy servers that they not cache documents by overriding the default Apache action of sending a Pragma: no-cache command along with each document that it sends on the basis of content. The default action is to have this command commented out in the httpd.conf file (telling the proxy servers that they should follow the typical performance). As you are dealing with continually changing information in your environment, leaving this at its default behavior is advised.
#CacheNegotiatedDocs
UseCanonicalName
There are many situations in which Apache has to construct self-referential URLs (a URL that refers back to the same server that the call is coming from). If the UseCanonicalName directive is set to on, Apache uses the ServerName and Port directives to construct the canonical name for the server which it then uses in all self-referential URLs.
There are three values that UseCanonicalName can take: off, on, and DNS. The DNS value is intended to be used with mass IP-based virtual hosting to support clients that are still using setups that do not provide a host value. Remember that you may be dealing with backward compatibility issues. With this UseCanonicalName set to DNS, Apache has to do a reverse DNS lookup to resolve what server the IP address references and this can cause some degree of performance degradation.
If UseCanonicalName is set to off, Apache will form the self-referential URLs using the host name and port only if the client supplies them; otherwise, it will use the canonical name.
The default for this directive is to be set to on.
If you are using a server with a short name (often the name of the Web server machine is www or www1) and the user enters http://www/mydirectory Apache (with UseCanonicalName set to on), the request will be redirected to http://www.company.com/mydir. With UseCanonicalName set to off, it would redirect the request to literally the directory and file that the user typed.
UseCanonicalName On
TypesConfig
The TypesConfig directive specifies where Apache can go to find the typing configuration file. Typically this file is named mime.types and usually requires no editing. The filename that is given as the value for TypesConfig is always relative to the value that you provided for ServerRoot, so you do not have to provide the full path to the file providing it is within the same directory tree that ServerRoot is the root for.
Entries in mime.types contain references to the type and a space-delimited list of filename extensions and it appears mime.types allows the browser to understand what plug-in or application you want to associate with what extension that your users may access.
type/subtype file_extenetion1 file_extenetion2 file_extenetion3… While you can add types to this file if needed for local use, it is highly recommended that you use the AddType directive in the httpd.conf file to accomplish this.
d:\visora\iAS/Apache/Apache/conf/mime.types
Example of entries that you might find in the mime.types file:
application/vnd.koan application/vnd.lotus-1-2-3 application/vnd.lotus-approach application/vnd.lotus-freelance application/vnd.lotus-notes application/vnd.lotus-organizer application/vnd.lotus-screencam application/vnd.lotus-wordpro application/vnd.mediastation.cdkey application/vnd.meridian-slingshot application/vnd.mif mif
DefaultType
If Apache cannot determine what type a file is from its extension (or if it is extensionless or its extension is not located in either an AddType directive or in the mime.types file), it will use the value assigned to this directive to determine what kind of file to assume (right or wrong) that it is. If most of the content of your server is flat text files or HTML documents, you can safely set this to text/plain. If, however, much of your content is binary format (e.g., applications, images) you might want to set it to application/octet-stream. This will keep the browser from trying to display an unknown image format or application with an undefined extension as text. This occasionally happened in the early- to mid-1990s when new types were coming out frequently and older browsers did not know what to do with them. Historically this was located in the srm.conf file, but has now been migrated to httpd.conf.
DefaultType text/plain
MIMEMagicFile
The mod_mime_magic module allows Apache to use various hints that can be found in the first few bytes of a file to attempt to determine its type if it cannot make that determination in any other way. The MIMEMagicFile directive enables this module's use. The default file containing the hints for mod_mime_magic is located in the ServerRoot/conf directory and is named magic. This module is not part of the default server and it needs to be added in the DSO section with a LoadModule directive or recompiled into the server. The MIMEMagicFile directive is enclosed within an <IfModule> container so that the directive is ignored if the module to which it refers is not loaded.
<IfModule mod_mime_magic.c> MIMEMagicFile d:\visora\iAS/Apache/Apache/conf/magic </IfModule>
Example entries that might be seen in the magic file:
0 lelong 0x0064732E >12 lelong 1 audio/x-dec-basic >12 lelong 2 audio/x-dec-basic >12 lelong 3 audio/x-dec-basic >12 lelong 4 audio/x-dec-basic >12 lelong 5 audio/x-dec-basic >12 lelong 6 audio/x-dec-basic >12 lelong 7 audio/x-dec-basic
It is highly unlikely that you would ever edit this file and it would be wise to only do so with the full support and knowledge of Oracle Support.
HostnameLookups
The HostnameLookups directive enables DNS lookups so that the host name can be logged and used (often this is required in CGI in its remote_host variable). HostnameLookups can take on three values: on, off, and double. Double allows Apache to do a double reverse DNS; after the first (reverse) lookup is done to retrieve the host name from DNS, another forward lookup is done to verify that result. At least one of the IP addresses in the forward lookup must match the original address. Regardless of the value of HostnameLookup, when mod_access module is being used, a double reverse lookup is done for added security (although the result in this case may not always be available to CGI for use in its variables). The default (and default value used by Apps) currently is off, saving on often unnecessary network traffic and considerable latency time observed by users by virtue of Apache doing the reverse lookup.
HostnameLookups Off
ErrorLog
The ErrorLog directive specifies the location of the error log file containing Apache's errors. If the path does not begin with either a drive specification (for Windows users) or a "/" for UNIX/Linux users, the path is assumed to be relative to the ServerRoot directive value. This is the default assumption in many cases within this file and the files that it calls. If the file path begins with a "|", it is assumed that it is the command that Apache is supposed to use to spawn the error log. With Apache, regardless of what platform you are on, do not change the directions of any of the slashes in the path.
ErrorLog d:\visora\iAS/Apache/Apache/logs/error_log
LogLevel
The LogLevel directive adjusts the amount of detail and the level of information that gets recorded in the ErrorLog log file. Table 4.2 shows the levels available and what level of detail goes along with each. They are listed in the table in order of decreasing significance of information. Whatever level is specified, all messages from that level and every level of increased significance is recorded in the file. This means that critical log level information will include alert level messages and emergency messages as well. It also means that info will include notice, warn, error, critical, alert, and emergency. This may be more information than you are intending so be careful with its use. It is highly suggested that a level of at least critical be maintained.
| LogLevel | Meaning |
|---|---|
| emerg | Emergencies—system is unusable. |
| alert | Action must be taken immediately. |
| crit | Critical conditions exist and should be addressed. |
| error | Error conditions (some of these errors are expected). |
| warn | Warning conditions. |
| notice | Normal but significant condition exists. |
| info | Informational entries will be written. |
| debug | Debugging level messages. |
Apps defaults the value to warn, which causes a verbose and lengthy log file that often contains irrelevant information. A level of error should be sufficient to alert you to things that may not be running correctly but will limit what is likely not of interest to you. Oracle Support will often have you reset this value to allow for the gathering of more information if you find that you are experiencing difficulties in your environment. Make sure that you change it back later or you will find that you have extremely large log files.
LogLevel warn
Custom logs are written in a customizable format, may be directly written to a file, or indirectly by means of an external program. The LogFormat directive specifies the format in which those custom files are written. Table 4.3 provides the English interpretation of what the variable values that can be used in the string specify.
| Format Variable | English Interpretation |
|---|---|
| %P | The process ID of the child process. |
| %p | Canonical port of serving server. |
| %{< FOOBAR >}o | Contents of Foobar with header line(s). |
| %{< FOOBAR >}n | Contents of note Foobar other module. |
| %m | Request method. |
| %l | Remote log name. |
| %{<FOOBAR>}I | Contents of variable Foobar with header line(s). |
| %H | Request protocol. |
| %h | Remote host. |
| %f | Filename. |
| %{< FOOBAR >}e: | Contents of environment variable FOOBAR. |
| %c | Connection status at response time. "X" = Connection aborted before completion. "+" = Connection kept alive after response. "-" = Connection closed after response. |
| %b | Bytes sent not including headers in CLF or Common Log File format. |
| %B | Bytes sent not including headers. |
| %A | Local IP address. |
| %q | Query string. |
| %r | First line of request. |
| %s | Status or original request. |
| %t | Common log format time. |
| %{Format}t | Time formatted. |
| %T | Request served time in seconds. |
| %u | Remote user (may not be valid). |
| %U | URL path requested without query string. |
| %V | Server name per UseCanonicalName directive. |
| %v | Canonical ServerName requesting server. |
| %a | Remote IP address. |
LogFormat "%h%l%u%t \"%r\"%>s%b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%h%l%u%t \"%r\"%>s%b" common LogFormat "%{Referer}i ->%U" referrer LogFormat "%{User-agent} i" agent
CustomLog
The CustomLog directive specifies the location and format that the access, agent, and referrer log files should have. The formats—common, agent, and referrers—refer back to the format above with the trailing tag bearing that name. Uncomment those logs that you want to maintain on your system. If you want to have all of this information (agent, access, and referrer) stored in a single file, you can comment out even the common one in this list and uncomment the combined.
CustomLog /export/home/hays/my_apache/apache_1.3.11/logs/acc ess_log common #CustomLog /export/home/hays/my_apache/apache_1.3.11/logs/ref erer_log referer #CustomLog /export/home/hays/my_apache/apache_1.3.11/logs/age nt_log agent #CustomLog /export/home/hays/my_apache/apache_1.3.11/logs/acc ess_log combined
ServerSignature
The ServerSignature directive provides the ability for Apache to place a trailing footer line under any server-generated documents. This line (available with ServerSignature value of on or e-mail) is particularly useful when placed in error message pages. It will place a line informing the user of the server version number, serving host, and, if the directive is given the value of e-mail, a mailto: link that will direct e-mail to the address specified in the ServerAdmin directive. In Oracle E-Business Suite (where many users are internal), this is often a handy way to allow users to quickly send you where they are and what their error conditions were. If you have implemented any of the "i" modules (e.g., iReceivables, iStore, iProcurement) this may become an e-mail headache unless you redirect the e-mail address to a central problem resolution address that is used only for this purpose. Remember, this value can be overridden in the Virtual Host section by a virtual host container directive, so you can specify that internal customers can send e-mail but limit what external customers are permitted to do. The default for this directive is off.
ServerSignature On
Alias
The Alias directive comes as part of the mod_alias module and provides the means to allow manipulation and control of URLs when requests are processed by Apache server. Again, this module either needs to be compiled into the Apache core or be included in the DSO include directive. Alias is used to create a map between URL strings and file system paths, particularly those paths outside of the DocumentRoot tree structure. A trailing "/" (as in /icons/ in the example below) forces Apache to require that exact string including the trailing slash to be a part of the referencing URL string; a reference to /icons/ would redirect, a reference to /icons would not. That means that a reference to http://myserver.mycompany.com/icons/mail.ico would result in the server retrieving the mail.ico icon file from the http://myserver.mycompany.com/export/home/hays/my_apache/apache_1.3.11/ icons directory. The directory container following the Alias directive allows security to be placed on the redirect directory if needed.
Alias/icons/"d:\visex- tras\extras/Apache/Apache/icons/" <Directory "d:\visex- tras\extras/Apache/Apache/icons/" Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all </Directory>
ScriptAlias
The ScriptAlias directive provides the same functionality and behaviors as the Alias directive, but for primarily CGI scripts. It refers to the target directory typically containing CGI scripts that will be processed by the mod_cgi module's CGI script handler.
ScriptAlias/cgi-bin/"d:\visex- tras\extras/Apache/Apache/cgi-bin/" <Directory "d:\visextras\extras/Apache/Apache/cgi- bin"> AllowOverride None Options None Order allow,deny Allow from all </Directory>
Redirect
The Redirect directive maps an old URL into a new one. This allows you to redirect requests to new locations of old files without having to recode all links in all referring documents. The new URL is returned to the calling client and the client then attempts to retrieve the document again with the new address. The format for this directive is Redirect OldURL NewURL. This should not be used instead of fixing all known references, but should be a stopgap measure to make sure that anything that you have not found gets redirected properly to new locations.
Redirect http://myserver.my.company.com/thisold- page.html http://myserver.my.company.com/new- path/to/thisoldpage.html
IndexOptions
The IndexOptions directive specifies the behavior of directory indexing. Valid formatting can either be IndexOptions option option option or IndexOptions +option +option -option depending on which Apache version you are dealing with. The "+|-" syntax became available with Apache 1.3.3 and is likely available in your implementation; however, the regular syntax will work as well. Options for this directive are in Table 4.4.
| Option | Option Description |
|---|---|
| DescriptionWidth=[n | *] | Width of description column in number of characters. |
| FancyIndexing | Enables fancy indexing of directories (setting this option will enable the ability to add many of the other options). |
| FoldersFirst | Subdirectories appear first in listing followed by files. Only available if FancyIndexing. |
| IconHeight[=pixels] | Causes the server to include height and width attributes in the IMG or Image tag for the icon so browsers can precalculate the page layout instead of waiting for all images to load. |
| IconsAreLinks | Makes icons part of anchor for the filename. Available only with FancyIndexing. |
| IconWidth[=pixels] | Works together with IconHeight. |
| IgnoreCase | Filenames sorted in case insensitive manner. Available only with FancyIndexing. |
| NameWidth=[n | *] | Specify width of the filename column in bytes. "*" Indicates that the column is automatically sized to longest filename allowing you to not have to do any recalculation when you add files to a directory. |
| ScanHTMLTitles | Allows extraction of the title from HTML documents for FancyIndexing (can be CPU and I/O intensive). |
| SuppressColumnSorting | Column headings made into links for sorting. Available only with FancyIndexing. |
| SuppressDescription | Suppresses the file description. Available only with FancyIndexing. |
| SuppressHTMLPreamble | Causes the display to start with the header file contents, provided that the header file contains appropriate HTML instructions. |
| SuppressLastModified | Suppresses the display of the last modification date. Available only with FancyIndexing. |
| SuppressSize | Suppresses the file size. Available only with FancyIndexing. |
| TrackModified | This returns the Last Modified and E Tag values for the listed directory in the HTTP header. This option is best used for UNIX servers due to the way that Windows does formatting. |
IndexOptions FancyIndexing
This can be further narrowed to directory specific IndexOptions as follows:
<Directory/OA_HTML/docs> IndexOptions FancyIndexing </Directory> <Directory/OA_HTML/docs/spec> IndexOptions ScanHTMLTitles </Directory>
The "+" and "-" prefixes attached to a keyword are applied to the current IndexOptions settings whether they are inherited from a higher level directory or are directly applied just on this directory. If an unprefixed option is processed, it has the effect of clearing out all of the inherited options and all incremental settings that have been acquired so far. This includes all options in the same IndexOptions directive. It does allow the further acquiring of options from that point forward, however. For example, if you have the following set of IndexOptions directives, you will process ScanHTMLTitles, add the IconsAreLinks option, then clear both of those options out because FancyIndexing is neither yes nor no, only exists and is therefore on. At this point you have the equivalent of IndexOptions FancyIndexing. Processing the next directive with the option +SupressSize has the net effect of having a single directive of IndexOptions FancyIndexing +SupressSize.
IndexOptions +ScanHTMLTitles -IconsAreLinks Fancy- Indexing IndexOptions +SupressSize
AddIcon
The AddIcon directive instructs the server what icon you want to have shown for each different type of file, filename, or extension. These directives also only apply for those directories for which FancyIndexing is defined as an option.
AddIconByEncoding (CMP,/icons/compressed.gif) x- compress x-gzip AddIconByType (TXT,/icons/text.gif) text/* AddIconByType (IMG,/icons/image2.gif) image/* AddIconByType (SND,/icons/sound2.gif) audio/* AddIconByType (VID,/icons/movie.gif) video/* AddIcon /icons/binary.gif.bin.exe AddIcon /icons/binhex.gif.hqx AddIcon /icons/tar.gif.tar AddIcon /icons/world2.gif.wrl.wrl.gz.vrml.vrm.iv AddIcon /icons/compressed.gif.Z.z.tgz.gz.zip
DefaultIcon
The DefaultIcon directive sets a generic default icon to display for files when Apache cannot determine what other icon should be used. This directive is only applicable for use with IndexOptions FancyIndexing.
DefaultIcon /icons/unknown.gif
AddDescription
The AddDescription directive allows Apache to place a particular defined short description in the display for any file or directory in server generated index lists. This allows users to have an understanding of what kind of file they are dealing with, if that is important to you. It can become a maintenance problem if you have an extensive list of file extensions that you want to maintain in this section. This directive is only applicable for use with IndexOptions FancyIndexing.
AddDescription "GZIP compressed document." gz AddDescription "tape archive." tar AddDescription "GZIP compressed tar archive." tgz
ReadmeName
The ReadmeName directive instructs Apache what README file, by default, to look for in the given directory. This assumes that you want to provide the ability for a user to access the README files in your directories and gain the information that might be in there. Not a bad idea for well-informed internal users, but it might be ill advised for a user coming in from the outside of your company who might have the intention to use this information for illicit means. It will start by looking for filename.htm or filename.html then if it does not find either one, it will look for filename.txt.
ReadmeName README
HeaderName
The HeaderName directive instructs Apache what filename to insert at the top of an index listing. Apache will by default start by looking for filename.htm or filename.html. Then, if it does not find either one, it will look for filename.txt.
HeaderName HEADER
IndexIgnore
The IndexIgnore directive adds additional files to the list it maintains of files that it should hide when listing the contents of a directory. The argument to this directive is a space-separated list of file extensions, partial filenames, and wildcarded filenames or extensions (shell script style wildcarding), expressions, or full filenames that you want Apache to ignore. Any value added to this directive adds to the list of files that Apache ignores, rather than replacing that list. By default the full list contains ".". This means that the .htaccess or the .htpass files would be excluded from any index listing. The inclusion of the READMEs in this list counteracts anything that might have been accomplished in the ReadMeName directive.
IndexIgnore README readme*.conf.properties
AddEncoding
The AddEncoding directive allows Apache to allow certain browsers (those with the capabilities to do so) to uncompress information. It maps the given filename extensions to specific encoding types. Anything added by means of this directive will add to the existing list instead of replacing it unless that extension already exists in the Apache maintained list. If Apache already has an extension of the given type in its internal list, setting this directive will override those values; so care must be taken to ensure that you are not overriding anything that you do not intend to. The following examples would direct Apache that anything with a gz or tgz extension would be read as encoded using x-gzip encoding and anything with a Z extension would be interpreted as being encoded with x-compress. The extension is case insensitive and can be entered with or without the leading dot.
AddEncoding x-compress Z AddEncoding x-gzip gz tgz
AddLanguage
The AddLanguage directive allows you to instruct Apache what language to infer a given document is written in. This adds the flexibility of allowing developers to be writing documents in the language they are going to be accessed in. You can then use content negotiation to give the browser a file that it can interpret. With the global nature of many businesses and the support that Oracle now builds into its product for more and more languages, this setting allows you to build customized interfaces into extensions to your system into the language format of the users who will be accessing that information.
The suffix does not have to be the same as the language keyword. For example, Polish would be pl if following net-standard coding, but you can use AddLanguage pl.po to limit the ambiguity that may result for developers between Polish spoken-written language and Perl scripts. The following lists typical defaults for these languages: Danish (da), Dutch (nl), English (en), Estonian (ee), French (fr), German (de), Greek-Modern (el), Italian (it), Portuguese (pt), Luxembourgeois (ltz), Spanish (es), Swedish (sv), Catalan (ca), Czech (cz). And this list adds to that default list:
AddLanguage da.dk AddLanguage nl.nl AddLanguage en.en AddLanguage et.ee AddLanguage fr.fr AddLanguage de.de AddLanguage el.el AddLanguage it.it AddLanguage pt.pt AddLanguage ltz.lu AddLanguage ca.ca AddLanguage es.es AddLanguage sv.se AddLanguage cz.cz
LanguagePriority
The LanguagePriority directive instructs Apache in the precedence of languages to present in case the requesting client (the end user's browser) does not have a preference set. This directive assists content negotiation in case it is determined that more than one language could be used. The list is in order of decreasing preference. In this case, the precedent order is English, Spanish, and French.
LanguagePriority en es fr
AddType
The AddType directive allows you to extend the functionality of mime.types without having to resort to editing the mime.types file. Adding types to this list is the preferred method of adding functionality. AddTypes maps the given file extension to a specific content type. These types are typically added for functionality that is not currently part of the Apache distribution. As the Internet grows, this is an easy place to add the functionality of the newer technology without necessarily having to upgrade every time a new function is released.
#AddType application/x-httpd-php3 .php3 #AddType application/x-httpd-php3-source .phps #AddType application/x-httpd-php .php #AddType application/x-httpd-php-source .phps AddType application/x-tar .tgz
AddHandler
The AddHandler directive allows you to map a certain file extension to a certain existing handler or to a downloadable plug-in. There are mappings already in place in Apache for most existing file types. If you map an extension that already exists in the Apache chore list to another handler, it will override the default value already in the default. Care must be taken to ensure that you do not create unanticipated side effects.
#AddHandler cgi-script .cgi #AddType text/html .shtml #AddHandler server-parsed .shtml
Action
The Action directive provides you the means to define media types that will be executed by whatever interpreter is defined for that extension whenever a file with that call's extension gets accessed. This allows some file extensions to be handled by one certain CGI script while a different script handles another. While the previous few directives are very useful if a little risky to alter, this one will allow you to provide a far higher level of flexibility with the inclusion of newer versions of interpreters while allowing previous versions to continue to function successfully until a migration to the newer technology can take place.
Action image/gif/cgi-bin/images.cgi AddHandler my-file-type.xyz Action my-file-type/cgi-bin/program.cgi
MetaDir
The MetaDir directive specifies the directory where Apache can find metadata information files. These files contain additional HTTP headers that can be included when sending a document and are usually located within a hidden subdirectory of the upper level directory housing the files for which access is being attempted. If the value that is assigned to MetaDir is just a dot ("."), Apache will attempt to look within the same directory as the file being accessed. Again, the dot notation means that the directory is hidden unless accessed via the proper method (ls -al).
MetaDir.metainfo
MetaSuffix
The MetaSuffix directive works with the MetaDir directive to fully provide Apache with the extension of the file within the MetaDir directive that contains the meta information. The default file extension for this directive is the .meta extension, but by setting this directive you can reassign this suffix to whatever you choose to use.
#MetaSuffix.meta
BrowserMatch
The BrowserMatch directive modifies the normal behavior that a browser will have in response to certain HTTP requests. Because you cannot always determine what brand or version of a browser that a client might be using, these directives can customize the response that Apache will use when it serves content to the different browsers that call. For example, KeepAlive is not always stable for a Mozilla/2-based browser (Netscape 2 and other browsers that use the same type base code). Internet Explorer Version 4.0b2 is known to have a somewhat incompatible implementation of HTTP 1.1 such that it also does not fully support KeepAlive. One of the things that any Web developer has to keep in mind when developing content is to build for the least common denominator. Build your content to be accessible by anyone from anywhere. While this is something that is usually easily remembered in most cases, this feature can also assist your implementation to become more accessible to users of the system who have disabilities that would possibly mean that they could not use the site otherwise (vision impaired, for example).
BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade- 1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0
Allow Server Reports
The ServerStatus directive in a location container will allow server status reports to be presented to the browser for viewing if they have the URL configuration of http://myserver/server-status. You will need to alter this container directive, changing the your_domain.com to your particular domain and uncomment it to make this directive work.
#<Location/server-info> # SetHandler server-info # Order deny,allow # Deny from all # Allow from.your_domain.com #</Location>
ProxyRequests
A proxy server is a server or service that sits between a client machine and a real or regular server (e.g., your Oracle E-Business Suite server). The proxy server's job is to intercept requests made to the regular server and try to fill the request. If the proxy server cannot fill the request on its own, the request gets forwarded on to the Applications Server. The mod_proxy module provides a proxy cache for Apache.
The ProxyRequests directive allows (on) or prevents (off) Apache from functioning as a proxy server. Setting this directive to off does not prevent you from being able to use other proxy servers. If you want to enable ProxyRequests, uncomment the following container enclosed directives; before you do, make sure you have secured your server. An open proxy server can be very dangerous.
<Directory proxy:*> Order Deny,Allow Deny from all Allow from mycompany.com </Directory>
Once it has been secured, uncomment the following:
#<IfModule mod_proxy.c> #ProxyRequests On # #<Directory proxy:*> # Order deny,allow # Deny from all # Allow from.your_domain.com #</Directory>
Notice the beginning line in the previous example is the command IfModule <module name>. This is the beginning of an IfModule container. This container continues and includes everything that appears in the file through the /IfModule command. In this case, all following commands apply in some way to the proxy settings on the server.
ProxyVia
The ProxyVia directive controls the flow of requests along a chain of proxy servers. Primarily, it is used to help deal with the handling of Via: HTTP headers. Table 4.5 shows the possible settings that ProxyVia can take on and the meaning to the server and the end user for those settings.
| Setting | Meaning |
|---|---|
| Off | No special processing is performed. Requests or replies containing a Via: header are passed through unchanged. This is the default setting. |
| On | Each request and reply processed will have a Via: header line appended for this host. |
| Full | Each Via: header line appended by this server will have the Apache server version shown as a Via: comment field. |
| Block | Every proxy request will have all of its existing Via: header lines removed and no new lines will be generated. |
#ProxyVia On
CacheRoot
The CacheRoot directive specifies the name of the directory that will contain cache files for the server; it must be a directory to which the HTTP Server can write. While setting CacheRoot enables proxy caching, without it you can still continue to have proxy functionality (if ProxyRequests is set to on) but no caching functionality would be available.
#CacheRoot "d:\visora/Apache/Apache/proxy"
CacheSize
The CacheSize directive specifies the desired space usage of the cache specified in the CacheRoot directive in kilobytes. While it may grow somewhat beyond this size, Apache's garbage collection will delete files until it is back at or below this number. If you are going to use cache, set this value to at least 20 to 40 percent below the actual amount of space allocated to the CacheRoot directory.
#CacheSize 5
CacheGcInterval
The CacheGcInterval directive specifies the number of hours after which the Apache service should check the cache and delete files above the space usage specified in the CacheSize directive. Many of these directives come in sets and build upon each other to provide full functionality and full control. This directive accepts a float value, so 1.5 is a valid value and garbage collection will occur (if this is the value that you choose to set for the directive) every 90 minutes. If this is left unset while the previous two are set, no garbage collection will occur and the cache in the CacheDir will grow until it runs out of space, making CacheSize irrelevant.
#CacheGcInterval 4
CacheMaxExpire
The CacheMaxExpire directive specifies the maximum number of hours a cached document will be allowed to be maintained on the proxy cache server before a new request is directed directly to the primary server. Any document in the cache could be, at most, this number of hours out of date.
#CacheMaxExpire 24
CacheLastModifiedFactor
The CacheLastModifiedFactor directive helps Apache determine the expiration date for a document for which the originating HTTP Server did not supply an expiration date. The formula for this calculation is:
Expiration-period = time-in-hours-since-last- modification * CacheLastModifiedFactor
If a document has a last modified date of a week ago (168 hours) and a CacheLastModiedFactor of 0.1, that would mean that the Expiration Period for that particular page would end after 16.8 hours.
EP = 168 *.1 = 16.8
If the result of this calculation is larger than CacheMaxExpire, CacheMaxExpire prevails. Again, this directive really applies only if you are using caching on the server.
#CacheLastModifiedFactor 0.1
CacheDefaultExpire
The CacheDefaultExpire directive specifies a default expiration time in hours of a document that gets fetched into the cache via a protocol that does not support expiration times. The CacheMaxExpire does not override this setting.
#CacheDefaultExpire 1
NoCache
The NoCache directive specifies a list of words, host names, and or domain names (space separated) from which this proxy server does not cache documents. If Apache can determine the domain name-IP connection for a domain contained in this list, addressing it by its IP would have the same effect on the caching (or not caching) of documents as having it referenced by name. Setting NoCache to "*" has the effect of disabling caching completely.
#NoCache a_domain.com another_domain.edu joes.garage_sale.com
This is the end of the IfModule container and the end of the directives that are only in effect if the server is going to have the proxy server settings turned on. This is how you can apply some kind of if, then, or else logic to the directives, adding flexibility to the server and to your environment.
#</IfModule>
Virtual Hosts
Section 3 of the httpd.conf file is the Virtual Hosts section. You configure containers and directives in this section that will allow you to maintain multiple domains and host names on one machine, differentiated by apparent host name. If there are several companies sharing a Web server, each will likely want to have their own domain without requiring visitors to know extraneous path information. Apache supports both IP-based and name-based virtual hosts. Virtual host containers are set up for different hosts.
Virtual host refers to the practice of maintaining more than one server service on one physical machine, each service differentiated by its apparent host name. One common example is in cases where different companies are sharing a physical Web server, yet it is highly desirable that each company has its own domain. The physical box may be named Bullwinkle; Company 1 may have licensed its domain www.mycompany.com and Company 2 may have licensed www.yourcompany.com. These individual domains can coexist on the same server through the implementation of each by way of Virtual Host directives.
IP-based implies that the server that you are dealing with must have a different, distinct IP address for each IP-based virtual host that you intend to configure. This is usually achieved by configuring the physical machine to have several physical network connections or to use one of the virtual interfaces that are supported by most OSs. IP-based virtual hosts make use of the IP address of the incoming connection to determine which virtual host it needs to serve. Therefore it is necessary to have a separate IP address for each separate host or for each domain.
Name-based virtual hosting relies on the client making the request to deliver the host name as part of the HTTP header that it sends. This allows many different hosts and many different domains to use the same IP address. Name-based virtual hosting is typically simpler to implement. You simply need to work with your networking people to configure the DNS server to map each host name to the correct IP address. Then you configure the Apache HTTP Server to recognize these different host names and test the resolution of the names to the correct places. Name-based virtual hosting would make the network folks at your company somewhat happier as it eases demand for one of the scarcest commodities in many corporations, IP addresses. Therefore, if you are going to be using virtual hosting in any way, you should attempt to use name-based virtual hosting unless there is a specific and compelling reason to choose IP-based virtual hosting.
The <VirtualHost> and </VirtualHost> container tags are used to enclose each group of directives that applies to each particular virtual host. Any directive that is allowed to be in a virtual host may be included between these two tags. Addr can be the IP address of the virtual host or a fully qualified domain name for the IP address of the virtual host.
Each virtual host must correspond to a different IP address, a different port number, or a different host name for the server. In the case of a different IP address, the server must be configured to accept packets for multiple addresses. This is particularly important if the machine you are dealing with does not have multiple physical network interfaces; it needs to be accomplished using ifconfig alias command (if your OS supports it).
#NameVirtualHost 12.34.56.78:80 #NameVirtualHost 12.34.56.78
Nearly any Apache directive can go into a virtual host container. If you put a directive into one of these containers, the value that you specify here overrides any value that you may have specified anywhere else and overrides the default values. Careful planning is necessary if you are considering using this section.
#<VirtualHost ip.address.of.host.some_domain.com> # ServerAdmin webmaster@host.some_domain.com # DocumentRoot/www/docs/host.some_domain.com # ServerName host.some_domain.com # ErrorLog logs/host.some_domain.com-error_log # CustomLog logs/host.some_domain.com-access_log common #</VirtualHost> #<VirtualHost _default_:*> #</VirtualHost>
|
| < Day Day Up > |
|
EAN: 2147483647
Pages: 122