Apache Core Features 4
Syntax:
EBCDICConvert On|Off[=direction] extension [extension] ...
Context:
server config, virtual host, directory, .htaccess
Status:
core
Override:
FileInfo
Compatibility:
The configurable EBCDIC conversion is only available in Apache 1.3.19 and later, and on EBCDIC
based platforms.
The EBCDICConvert directive maps the given filename extensions to the specified conversion
setting (On or Off). File extensions may be specified with or
without a leading dot.
If the optional format On=direction (or Off=direction)
is used, where direction is one of In, Out or InOut,
then the directive only applies to the specified transfer direction (In: uploaded
content in a PUT or POST request, Out: returned content in a GET or POST request,
and InOut: conversion in both directions).
Otherwise, InOut (conversion in both directions) is implied.
Conversion configuration based on file extension is tested prior to configuration based on
MIME type, to allow for generic MIME based rules to be overridden by a more specific file
extension (several file extensions may exist for the same MIME type).
Example:
With a configuration like the following, the normal *.html files contain HTML
text in EBCDIC encoding, while *.ahtml files contain HTML text in ASCII encoding:
# *.html and *.ahtml contain HTML text:
AddType text/html .html .ahtml
# *.ahtml is not converted (contains ASCII text already):
EBCDICConvert Off .ahtml
# All other text/html files presumably contain EBCDIC text:
EBCDICConvertByType On text/html
See also:
EBCDICConvertByType and
Overview of the EBCDIC Conversion
Functions
Syntax:
EBCDICConvertByType On|Off[=direction] mimetype [mimetype] ...
Context:
server config, virtual host, directory, .htaccess
Status:
core
Override:
FileInfo
Compatibility:
The configurable EBCDIC conversion is only available in Apache 1.3.19 and later, and on EBCDIC
based platforms.
The EBCDICConvertByType directive maps the given MIME type (optionally containing
wildcards) to the specified conversion setting (On or Off).
If the optional format On=direction (or Off=direction)
is used, where direction is one of In, Out or InOut,
then the directive only applies to the specified transfer direction (In: uploaded
content in a PUT or POST request, Out: returned content in a GET or POST request,
and InOut: conversion in both directions).
Otherwise, InOut (conversion in both directions) is implied.
Example:
A useful standard configuration should at least contain the following defaults:
# All text documents are stored as EBCDIC files:
EBCDICConvertByType On text/* message/* multipart/*
EBCDICConvertByType On application/x-www-form-urlencoded \
model/vrml application/postscript
# All other files are assumed to be binary:
EBCDICConvertByType Off */*
If you serve ASCII documents only, for example from an NFS mounted unix server, use:
# All documents are ASCII already:
EBCDICConvertByType Off */*
See also:
EBCDICConvert and
Overview of the EBCDIC Conversion
Functions
Syntax:
EBCDICKludge On|Off
Default:
EBCDICKludge Off
Context:
server config, virtual host, directory, .htaccess
Status:
core
Override:
FileInfo
Compatibility:
EBCDICKludge is only available in Apache 1.3.19 and later, and on EBCDIC based platforms. It
is deprecated and will be withdrawn in a future version.
The EBCDICKludge is provided for the backward compatible behavior with apache versions
1.3.0 through 1.3.18. In these versions, all files with MIME types starting with
"text/", "message/" or "multipart/" or with type
"application/x-www-form-urlencoded" would be converted by default, all other
documents were returned unconverted. Only if a MIME type "text/x-ascii-subtype"
was configured for a certain document, the document was assumed to be in ASCII format already,
and was not converted again. Instead, the "x-ascii-" was removed
from the type, resulting in the MIME type "text/subtype" being
returned for the document.
If the EBCDICKludge directive is set to On, and if none of the file extensions
configured with the EBCDICConvert directive matches in the
current context, then the server tests for a MIME type of the format type/x-ascii-subtype.
If the document has such a type, then the "x-ascii-" substring
is removed and the conversion set to Off. This allows for overriding the implicit
assumption that all text files are stored in EBCDIC format, for example when serving documents
from an NFS mounted directory with ASCII documents.
By using the EBCDICKludge, there is no way to force one of the other MIME types (e.g.,
model/vrml) to be treated as an EBCDIC text file. Use of the
EBCDICConvertByType
directive mentioned above is the preferred way to configure such a conversion. (Before Apache
version 1.3.19, there was no way at all to force these binary documents to be treated as
EBCDIC text files.)
See also:
EBCDICConvert,
EBCDICConvertByType and
Overview of the EBCDIC Conversion
Functions
Syntax:
ErrorDocument error-code document
Context:
server config, virtual host, directory, .htaccess
Status:
core
Override:
FileInfo
Compatibility:
The directory and .htaccess contexts are only available in Apache 1.1 and later.
In the event of a problem or error, Apache can be configured to do one of four things,
- output a simple hardcoded error message
- output a customized message
- redirect to a local URL-path to handle the problem/error
- redirect to an external URL to handle the problem/error
The first option is the default, while options 2-4 are configured using the ErrorDocument
directive, which is followed by the HTTP response code and a message or URL.
Messages in this context begin with a single double-quote character ("),
which does not form part of the message itself. Apache will sometimes offer additional
information regarding the problem/error.
URLs can begin with a slash (/) for local URLs, or be a full URL which the client can
resolve. 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
Note that when you specify an ErrorDocument that points to a remote URL (ie.
anything with a method such as "http" in front of it), Apache will send a redirect
to the client to tell it where to find the document, even if the document ends up being on the
same server. This has several implications, the most important being that the client will not
receive the original error status code, but instead will receive a redirect status code. This
in turn can confuse web robots and other clients which try to determine if a URL is valid
using the status code. In addition, if you use a remote URL in an ErrorDocument 401,
the client will not know to prompt the user for a password since it will not receive the 401
status code. Therefore, if you use an "ErrorDocument 401" directive then it
must refer to a local document.
See Also: documentation of
customizable responses. See the
HTTP specification for a
complete list of the status codes and their meanings.
Syntax:
ErrorLog file-path|syslog[:facility]
Default:
ErrorLog logs/error_log (Unix)
Default:
ErrorLog logs/error.log (Windows and OS/2)
Context:
server config, virtual host
Status:
core
The error log directive sets the name of the file to which the server will log any errors
it encounters. If the file-path does not begin with a slash (/) then it is assumed to
be relative to the ServerRoot. If the file-path begins with
a pipe (|) then it is assumed to be a command to spawn to handle the error log.
Examples
ErrorLog logs/vhost1.error
or
ErrorLog |/usr/local/bin/errorlog.pl
Apache 1.3 and above: Using syslog instead of a filename
enables logging via syslogd(8) if the system supports it. The default is to use syslog
facility local7, but you can override this by using the syslog:facility
syntax where facility can be one of the names usually documented in syslog(1).
For example:
ErrorLog syslog
or
ErrorLog syslog:user
SECURITY: See the
security
tips document for details on why your security could be compromised if the directory where
logfiles are stored is writable by anyone other than the user that starts the server.
See also: LogLevel and
Apache Log Files
Syntax:
FileETag component ...
Context:
server config, virtual host, directory, .htaccess
Override:
FileInfo
Status:
core
Compatibility:
only available in Apache 1.3.23 versions and later.
The FileETag directive configures the file attributes that are used to create the ETag
(entity tag) response header field when the document is based on a file. (The ETag value is
used in cache management to save network bandwidth.) In Apache 1.3.22 and earlier, the ETag
value was always formed from the file's inode, size, and last-modified time (mtime).
The FileETag directive allows you to choose which of these -- if any -- should be used. The
recognized keywords are:
- INode
- The file's i-node number will be included in the calculation
- MTime
- The date and time the file was last modified will be included
- Size
- The number of bytes in the file will be included
- All
- All available fields will be used (equivalent to '
FileETag INode MTime Size')
- None
- If a document is file-based, no ETag field will be included in the response
The INode, MTime, and Size keywords may be prefixed with either '+' or '-', which allow
changes to be made to the default setting inherited from a broader scope. Any keyword
appearing without such a prefix immediately and completely cancels the inherited setting.
If a directory's configuration includes 'FileETag INode MTime Size',
and a subdirectory's includes 'FileETag -INode', the setting for that
subdirectory (which will be inherited by any sub-subdirectories that don't override it) will
be equivalent to 'FileETag MTime Size'.
Syntax:
<Files filename> ... </Files>
Context:
server config, virtual host, .htaccess
Status:
core
Compatibility:
only available in Apache 1.2 and above.
The <Files> directive provides for access control by filename. It is comparable to
the <Directory> directive and <Location>
directives. It should be matched with a </Files> directive. The directives given within
this section will be applied to any object with a basename (last component of filename)
matching the specified filename. <Files> sections are processed in the
order they appear in the configuration file, after the <Directory> sections and .htaccess
files are read, but before <Location> sections. Note that <Files> can be nested
inside <Directory> sections to restrict the portion of the filesystem they apply to.
The filename argument should include a filename, or a wild-card string, where `?'
matches any single character, and `*' matches any sequences of characters. Extended regular
expressions can also be used, with the addition of the ~ character. For example:
<Files ~ "\.(gif|jpe?g|png)$">
would match most common Internet graphics formats. In Apache 1.3 and later, <FilesMatch> is preferred, however.
Note that unlike <Directory> and <Location> sections, <Files>
sections can be used inside .htaccess files. This allows users to control access to their own
files, at a file-by-file level. For example, to password protect a single file within a
particular directory, you might add the following to your .htaccess file:
<Files admin.cgi>
Require group admin
</Files>
Remember that directives apply to subdirectories as well, so this will also protect files
called admin.cgi in subdirectories, unless specifically overridden.
(See Require for details on using the Require
directive)
See also:
How
Directory, Location and Files sections work for an explanation of how these different
sections are combined when a request is received
Syntax:
<FilesMatch regex> ... </FilesMatch>
Context:
server config, virtual host, .htaccess
Status:
core
Compatibility:
only available in Apache 1.3 and above.
The <FilesMatch> directive provides for access control by filename, just as the <Files> directive does. However, it accepts a regular expression. For
example:
<FilesMatch "\.(gif|jpe?g|png)$">
would match most common Internet graphics formats.
See also:
How Directory,
Location and Files sections work for an explanation of how these different sections are
combined when a request is received
|
