As you have learned, Indexes is one of the parameters you can use with the Options directive. You use the Indexes option to tell the HTTP Server whether it should produce an HTML page when a directory is requested. You add indexes to the list of options in this way:

  Options +Indexes

You have several options when a user requests a directory rather than a file:

• The HTTP Server can return a default file: You can use the DirectoryIndex directive, which follows, to specify the default file:
  
  DirectoryIndex index.html index.htm
  
  In the foregoing example, the server will first try to return the index.html and then the index.htm file.
  
• An HTML page of the directory contents can be generated and sent back
  
• A "permission denied" error can be issued
  
• A "file not found" error can be issued, as shown here:

  DirectoryIndex index.html /cgi-bin/error404.cgi

If you enable Indexes and none of the resources specified with the DirectoryIndex directive are found, by default the HTTP Server will generate an index of the directory. To avoid this default behavior, you must specify a non-relative URL as the (last) option for the DirectoryIndex directive, as illustrated in the preceding example.

Directory Listings

You may not want all users to have access to backup files and files such as the .profile and the .cshrc files. To prevent all files from showing up in file listings, you use the IndexIgnore directive. Any files you specify as options for the IndexIgnore directive will not appear in file listings. Heres a simple example:

  IndexIgnore .??* *~ *# *.bak HEADER* README*

The following are the results of using the IndexIgnore directive in the above manner:

• All backup, header, and readme files are not listed.
  
• Any filename that starts with a dot and is longer than three characters is ignored.

on the job:  Once you eliminate a file from being listed, through the IndexIgnore directive, that file can no longer be reinstated as part of a file listing.

Response Handling

When the Oracle HTTP Server encounters an error while processing a user's request, it first logs the error in the error_log file and then sends an error message to the client. Using the ErrorDocument directive, you can customize the Oracle HTTP Server's response in the form of an HTML document.

When the Oracle HTTP Server encounters an error, it can do one of the following four things:

• Send a simple hard coded message.
  
• Send a custom message.
  
• Redirect to a local URL-path.
  
• Redirect to an external URL.

By default, the Oracle HTTP Server will choose option 1 when it encounters errors. Since this means that the user will get an ugly error message, you must choose one of the options and customize the response of the Web server to error conditions. You can use the ErrorDocument directive to configure one of the other three options. You can specify an HTTP error-response code and a URL or a message when you use the ErrorDocument directive. Local URL paths start with a slash (/) relative to the DocumentRoot, or a full URL, if it's external. The HTTP Server can also provide a message to be displayed by the browser. Here are some examples:

  ErrorDocument 500 http://foo.example.com/cgi-bin/tester 
  ErrorDocument 404 /cgi-bin/bad_urls.pl
  ErrorDocument 401 /subscription_info.html
  ErrorDocument 403 "Sorry can't allow you access today"

You can also use the special value default, to specify the simple hardcode message by the HTTP Server, as shown here. Doing this will ensure that the simple hardcoded message will be restored, instead of inheriting an existing ErrorDocument value.

  ErrorDocument 404 /cgi-bin/bad_urls.pl
  <Directory /web/docs>
  ErrorDocument 404 default
  </Directory>

Expires Header

The Expires header in a document determines when a document becomes out of date. Using the ExpireActive directive, you can turn the sending of the Expires header on and off.

on the job:  Themod_expires module controls the Expires header.