Versi�n 2.0 del Servidor HTTP Apache

| Descripci�n: | Funcionalidades b�sicas del servidor HTTP Apache que est�n siempre presentes |
|---|---|
| Estado: | Core |
AcceptPathInfo
AccessFileName
AddDefaultCharset
AddOutputFilterByType
AllowEncodedSlashes
AllowOverride
AuthName
AuthType
CGIMapExtension
ContentDigest
DefaultType
<Directory>
<DirectoryMatch>
DocumentRoot
EnableMMAP
EnableSendfile
ErrorDocument
ErrorLog
FileETag
<Files>
<FilesMatch>
ForceType
HostnameLookups
IdentityCheck
<IfDefine>
<IfModule>
Include
KeepAlive
KeepAliveTimeout
<Limit>
<LimitExcept>
LimitInternalRecursion
LimitRequestBody
LimitRequestFields
LimitRequestFieldSize
LimitRequestLine
LimitXMLRequestBody
<Location>
<LocationMatch>
LogLevel
MaxKeepAliveRequests
MaxRanges
NameVirtualHost
Options
Require
RLimitCPU
RLimitMEM
RLimitNPROC
Satisfy
ScriptInterpreterSource
ServerAdmin
ServerAlias
ServerName
ServerPath
ServerRoot
ServerSignature
ServerTokens
SetHandler
SetInputFilter
SetOutputFilter
TimeOut
TraceEnable
UseCanonicalName
<VirtualHost>| Descripci�n: | Especifica si los recursos aceptan informaci�n de path a�adida (trailing pathname information) |
|---|---|
| Sintaxis: | AcceptPathInfo On|Off|Default |
| Valor por defecto: | AcceptPathInfo Default |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Disponible en la versiones de Apache 2.0.30 y posteriores |
Esta directiva controla si las peticiones que contienen
informaci�n de path a�adida (trailing pathname
information) a continuaci�n de un nombre de fichero existente
(o no existente en un directorio que s� existe) ser�n
aceptadas o rechazadas. La informaci�n de path a�adida
(trailing pathname information) puede pasarse a los scripts en la
variable de entorno PATH_INFO.
Por ejemplo, suponga que la ubicaci�n /test/
se refiere a un directorio que contiene un �nico fichero:
here.html. Entonces, tanto las peticiones a
/test/here.html/more como las peticiones a
/test/nothere.html/more toman /more como
PATH_INFO.
Los tres argumentos que puede tomar la directiva
AcceptPathInfo son:
Off/test/here.html/more
como en el ejemplo de arriba, devolver� el mensaje de error
404 NOT FOUND.On/test/here.html/more ser� aceptado si
/test/here.html se refiere a un fichero
v�lido.DefaultPATH_INFO. Los
handlers que sirven scripts, como cgi-script e isapi-handler, generalmente aceptan
PATH_INFO por defecto.El prop�sito principal de la directiva
AcceptPathInfo es permitirle hacer prevalecer su
propio criterio sobre el del handler acerca de si se debe aceptar
o rechazar PATH_INFO. Esto es necesario por ejemplo,
cuando use un filtro, como INCLUDES, para generar contenido
basado en PATH_INFO. El handler b�sico
rechazar�a normalmente la petici�n. Puede usar la
siguiente configuraci�n para activar dicho script:
<Files "mypaths.shtml">
Options +Includes
SetOutputFilter INCLUDES
AcceptPathInfo On
</Files>
| Descripci�n: | Nombre del fichero de configuraci�n distribuida |
|---|---|
| Sintaxis: | AccessFileName filename [filename] ... |
| Valor por defecto: | AccessFileName .htaccess |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
Durante el procesamiento de una petici�n el servidor busca el primer fichero de configuraci�n de esta lista de nombres en cada directorio de la ruta del documento, siempre y cuando los ficheros de configuraci�n distribuida est�n activados para ese directorio. Por ejemplo:
AccessFileName .acl
Antes de devolver el documento
/usr/local/web/index.html, el servidor leer�
/.acl, /usr/.acl,
/usr/local/.acl y /usr/local/web/.acl
buscando directivas, a menos que hayan sido desactivados con
<Directory />
AllowOverride None
</Directory>
| Descripci�n: | Par�metro del conjunto de caracteres que se
a�ade cuando el tipo de contenido de una respuesta es
text/plain o text/html |
|---|---|
| Sintaxis: | AddDefaultCharset On|Off|charset |
| Valor por defecto: | AddDefaultCharset Off |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
Esta directiva especifica un valor por defecto para el
par�metro del conjunto de caracteres que se a�ade
a�ade si solo si el tipo de contenido de una respuesta es
text/plain o text/html. EL valor
pecificado en esta directiva no prevalecer� si cualquier otro
conjunto de caracteres es especificado en el cuerpo del documento
por medio de una etiqueta META, aunque a menudo, el
comportamiento exacto est� determinado por la
configuraci�n del cliente. Si se especifica
AddDefaultCharset Off, se desactiva esta
funcionalidad. AddDefaultCharset On activa el uso del
conjunto de caracteres por defecto interno de Apache,
iso-8859-1. Cualquier otro valor se asume que es el
charset a usar, que ser� uno los registrados
por la IANA como tipos MIME. Por ejemplo:
AddDefaultCharset utf-8
AddDefaultCharset debe ser usada solo
cuando todos los recursos de texto a los que se aplican se saben
que usan un determiando conjunto de caracteres (character
encoding) y no es conveniente etiquetar los documentos
individualmente. Un ejemplo es su uso en recursos que contienen
contenido generado, como CGIs antiguos, que puede ser vulnerables
a ataques debidos a que se incluye en el resultado datos
suministrados por el usuario. Tenga en cuenta, sin embargo, que
una mejor soluci�n es simplemente modificar (o borrar) esos
scripts, porque especificar un conjunto de caracteres por defecto
no protege a los usuarios que tengan activada en su navegador la
opci�n "auto-detect character encoding".
| Descripci�n: | Asigna un filtro de salida a un tipo MIME en particular |
|---|---|
| Sintaxis: | AddOutputFilterByType filter[;filter...]
MIME-type [MIME-type] ... |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Disponible en las versiones de Apache 2.0.33 y posteriores |
Esta directiva activa un filtro de salida en particular para las peticiones en funci�n del tipo MIME de la respuesta.
El siguiente ejemplo usa el filtro DEFLATE, del
m�dulo mod_deflate. Este filtro comprime la
parte de la respuesta de la petici�n (ya sea est�tica o
din�mica) que est� etiquetada como
text/html o text/plain antes de ser
enviada al cliente.
AddOutputFilterByType DEFLATE text/html text/plain
Si quiere que los contenidos sean procesados por m�s de un
filtro, debe separar sus nombres con puntos y comas
(;). Tamb�n es posible usar la directiva
AddOutputFilterByType para cada uno de los
filtros.
La configuraci�n que se muestra m�s abajo hace que
todos los scripts etiquetados como text/html sean
procesados primero por el filtro INCLUDES y
posteriormente por el filtro DEFLATE.
<Location /cgi-bin/>
Options Includes
AddOutputFilterByType INCLUDES;DEFLATE text/html
</Location>
Activar filtros con la
directiva AddOutputFilterByType puede no
funcionar parcial o totalmente. Por ejemplo, no se aplica
ning�n filtro si es posible determinar el tipo MIME y se
aplica en su lugar DefaultType, incluso si el DefaultType es el mismo.
Si quiere estar seguro de que se apliquen los filtros, asigne
el tipo de contenido a un recurso expl�citamente, por ejemplo
con la directiva AddType o con ForceType. Determinar el tipo de
contenido dentro de un script CGI (que no sea del tipo nph)
tambi�n es seguro.
Los filtros de salida por tipo no se aplican nunca en peticiones proxy.
| Descripci�n: | Determina si se acepta el uso de separadores de ubicaci�n codificados en las URLs |
|---|---|
| Sintaxis: | AllowEncodedSlashes On|Off |
| Valor por defecto: | AllowEncodedSlashes Off |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Disponible en las versines de Apache 2.0.46 y posteriores |
La directiva AllowEncodedSlashes
perimite usar URLs que contienen separadores de ubicaci�n
codificados (%2F para / y
%5C para \ en funci�n del
sistema). Normalmente, tales URLs se rechazan y se devuelve un
mensaje de error 404 (Not found).
Especificar el valor On en la directiva
AllowEncodedSlashes es �til sobre todo
cuando se usa junto con PATH_INFO.
Permitir barras codificadas
no implica su decodificado. La aparici�n
de %2F o %5C (seg�n el sistemas
de que se trate) se dejar� como tal en la cadena de
caracteres que conforma la de otra manera URL decodificada.
| Descripci�n: | Tipos de directivas que cuyo uso est� permitido en los ficheros .htaccess |
|---|---|
| Sintaxis: | AllowOverride All|None|directive-type
[directive-type] ... |
| Valor por defecto: | AllowOverride All |
| Contexto: | directory |
| Estado: | Core |
| M�dulo: | core |
Cuando el servidor encuentra un fichero .htaccess
(como se explica en la directiva AccessFileName) es necesario saber que
directivas presentes en ese fichero pueden prevalecer sobre
las directivas de configuraci�n previas.
AllowOverride puede usarse solo en las
secciones <Directory> especificadas sin expresiones
regulares, nunca en las secciones <Location>, <DirectoryMatch> o <Files>.
Cuando el valor de esta directiva es None,
entonces los ficheros .htaccess son
ignorados completamente. En ese caso, el servidor ni siquiera
intentar� leer los archivos .htaccess
existentes.
Cuando el valor especificado en esta directiva es
All, entonces cualquier directiva que tenga Context .htaccess puede ser
usada en los ficheros .htaccess.
El tipo de directiva puede ser uno de los siguientes grupos de directivas.
AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, etc.).DefaultType, ErrorDocument, ForceType, LanguagePriority,
SetHandler, SetInputFilter, SetOutputFilter, y
mod_mime las directivas Add* y Remove*,
etc.).AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName,
etc.).Allow, Deny y Order).Options y XBitHack).Ejemplo:
AllowOverride AuthConfig Indexes
En el ejemplo de arriba todas las directivas que no est�n
en el grupo AuthConfig ni en el grupo
Indexes provocan un error interno del servidor.
| Descripci�n: | Ambito de autorizaci�n para su uso en autentificaci�n HTTP |
|---|---|
| Sintaxis: | AuthName auth-domain |
| Contexto: | directory, .htaccess |
| Prevalece sobre: | AuthConfig |
| Estado: | Core |
| M�dulo: | core |
Esta directiva especifica el nombre de dominio que se muestra
al solicitar autorizaci�n para acceder a un directorio. Este
nombre de dominio se muestra al cliente para que el usuario sepa
qu� nombre de usuario y contrase�a ha de introducir.
AuthName toma solamente un argumento; si
el nombre de dominio contiene alg�n espacio, debe escribirse
entre comillas. Para que funcione correctamente, esta directiva
debe usarse junto con las directivas AuthType y Require, y con directivas como
AuthUserFile y
AuthGroupFile.
Por ejemplo:
AuthName "Top Secret"
La cadena de caracteres que se especifique como valor de
AuthName ser� lo que aparecer� en el cuadro
de di�logo de acceso de la mayor�a de los
navegadores.
| Descripci�n: | Tipo de autentificaci�n de usuarios |
|---|---|
| Sintaxis: | AuthType Basic|Digest |
| Contexto: | directory, .htaccess |
| Prevalece sobre: | AuthConfig |
| Estado: | Core |
| M�dulo: | core |
Esta directiva selecciona el tipo de autentificaci�n de
usuarios que usar� para un directorio. Actualmente solamente
est�n implementadas las opciones Basic y
Digest.
Para que funcione correctamente, esta directiva tiene que ir
acompa�ada por las directivas AuthName y Require, y de directivas como
AuthUserFile y
AuthGroupFile.
| Descripci�n: | T�cnica para localizar un int�rprete de scripts CGI |
|---|---|
| Sintaxis: | CGIMapExtension cgi-path
.extension |
| Contexto: | directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Solamente NetWare |
Esta directiva se usa para controlar la forma en que Apache
encuentra el int�rprete para ejecutar scripts CGI. Por
ejemplo, si usa CGIMapExtension sys:\foo.nlm .foo,
todos los scripts CGI con extensi�n .foo se
pasar�n al int�rprete FOO.
| Descripci�n: | Activa la generaci�n de cabeceras de respuesta HTTP
Content-MD5 |
|---|---|
| Sintaxis: | ContentDigest On|Off |
| Valor por defecto: | ContentDigest Off |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Options |
| Estado: | Core |
| M�dulo: | core |
Esta directiva permite la generaci�n de cabeceras
Content-MD5 seg�n se definen en RFC1864 y
RFC2068.
MD5 es un algoritmo que genera una cadena de caracteres ("message digest", a veces llamado "huella dactilar") a partir de unos datos de longitud arbitraria. La forma en que funciona este algoritmo hace que con casi toda seguridad, si se producen alteraciones en los datos originales, el "message digest" generado tambi�n ser� diferente.
La cabecera Content-MD5 es una forma de comprobar
la integridad de un mensaje de principio a fin (MIC) para los
mensajes HTTP (entity-body). Un proxy o un cliente pueden
comprobar esta cabecera para detectar modificaciones accidentales
en el mensaje HTTP (entity-body) en tr�nsito. Cabecera de
ejemplo:
Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
Tenga en cuenta que el uso de esta directiva puede provocar un menor rendimiento de su servidor porque el "message digest" se genera en cada petici�n (los valores no se guardan).
La cebecera Content-MD5 se env�a solamente
cuando un documento es servido por core. Si el
documento es servido con cuaquier otro m�dulo, no se
env�a. Por ejemplo, los documentos SSI, las salidas de
scripts CGI, y las respuesta parciales (byte range responses) no
tienen esta cabecera.
| Descripci�n: | Tipo de contenido MIME por defecto que usar� el servidor si no puede determinar el tipo MIME en concreto del documento a servir |
|---|---|
| Sintaxis: | DefaultType MIME-type |
| Valor por defecto: | DefaultType text/plain |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
Hay veces en las que se pide al servidor que devuelva un documento cuyo tipo MIME no puede determinar.
El servidor tiene que informar al cliente del tipo de contenido
del documento. En el caso de que se trate de un tipo desconocido,
se usa el tipo DefaultType. Por ejemplo:
DefaultType image/gif
ser�a apropiado para un directorio que contenga muchas
imagenes tipo GIF cuyos nombres de fichero no tengan la
extensi�n .gif.
Tenga en cuenta que a diferencia de ForceType, esta directiva solamente
indica el tipo MIME por defecto. El resto de definiciones de tipos
MIME, incluidas las extensiones de fichero, que pueden identificar
el tipo MIME de que se trata prevalecen sobre esta opci�n por
defecto.
| Descripci�n: | Engloba a un grupo de directivas que se aplicar�n solamente al directorio del sistema de ficheros especificado y a sus subdirectorios |
|---|---|
| Sintaxis: | <Directory directory-path>
... </Directory> |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
Las directivas <Directory>
y </Directory> se usan para englobar un grupo
de directivas que se aplicar�n solamente al directorio
especificado y a sus subdirectorios. Puede incluir a cualquier
directiva cuyo uso est� permitido en un contexto
<directory>. Directory-path puede ser tanto la
ruta completa a un directorio, como una cadena de caracteres
comod�n que use las reglas de equivalencia de los shells de
Unix. En una cadena de caracteres comod�n, el car�cter
? equivale a cualquier car�cter individual, y
* equivale a cualquier secuencia de
caracteres. Tambi�n puede usar [] para expresar
rangos de caracteres. Ninguno de los caracteres comod�n
equivale al car�cter `/', de modo que <Directory
/*/public_html> no equivale a
/home/user/public_html, pero s� a
<Directory /home/*/public_html>. Ejemplo:
<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>
Tenga especial cuidado con los argumentos de
directory-path: tienen que equivaler literalmente a
la ruta del sistema de ficheros que Apache usa para acceder a
los ficheros. Las directivas aplicadas a un
<Directory> en particular no se
aplicar�n a los ficheros de ese mismo directorio pero que
sean accedidos mediante una ruta diferente, como por ejemplo
mediante enlaces simb�licos diferentes.
Tambi�n pueden usar expresiones regulares extendidas,
a�adiendo el car�cter ~. Por ejemplo:
<Directory ~ "^/www/.*/[0-9]{3}">
equivaldr�a a los directorios en /www/ cuyo
nombres consistan en tres n�meros.
Si varias (expresiones no regulares) secciones <Directory> equivalen al directorio (o a
uno de los directorios de los que es subdirectorio) que contiene
un documento, entonces las directivas se aplican seg�n el
criterio de la ruta equivalente m�s corta, junto con las
directivas de los archivos .htaccess. Por ejemplo, con
<Directory />
AllowOverride None
</Directory>
<Directory /home/>
AllowOverride FileInfo
</Directory>
para acceder al documento /home/web/dir/doc.html
los pasos son:
AllowOverride None
(desactivando los ficheros .htaccess).AllowOverride FileInfo
(para el directorio /home).FileInfo en
/home/.htaccess, /home/web/.htaccess y
/home/web/dir/.htaccess por ese orden.Las expresiones regulares no se tienen en cuenta hasta que todas las secciones normales hayan sido aplicadas. En ese momento todas se eval�an las expresiones regulares en el orden en que aparecen en el fichero de configuraci�n. Por ejemplo, con
<Directory ~ abc$>
# ... directivas aqu� ...
</Directory>
la secci�n de expresiones regulares no ser�
considerada hasta despu�s de que todas las directivas
<Directory> y los ficheros
.htaccess hayan sido aplicados. Solamente entonces
las expresiones regulares que tengan una equivalencia con
/home/abc/public_html/abc y la correspondiente
directiva <Directory>
ser�n aplicadas.
Tenga en cuenta que por defecto el acceso de Apache a
<Directory /> es Allow from All.
Esto significa que Apache servir� cualquier fichero que se
corresponda con una URL. Se recomienda que modifique este
comportamiento con un bloque del siguiente tipo
<Directory />
Order Deny,Allow
Deny from All
</Directory>
y haga prevalecer una configuraci�n diferente para los solamente para los directorios que usted quiera que sean accesibles. Consulte la secci�n Consejos de seguridad para obtener m�s informaci�n.
Las secciones "directory" se usan en el archivo
httpd.conf. Las directivas <Directory> no pueden anidarse, y no
pueden aparecer en una secci�n de tipo <Limit> o <LimitExcept>.
| Descripci�n: | Incluye las directivas que se aplican a los directorios y subdirectorios del sistema de ficheros que equivalen a una expresi�n regular |
|---|---|
| Sintaxis: | <DirectoryMatch regex>
... </DirectoryMatch> |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
<DirectoryMatch> y
</DirectoryMatch> se usan para englobar a un
grupo de directivas que se aplicar�n solamente al directorio
(y los subdirectorios de �ste) especificado, al igual que
<Directory>. Sin
embargo, en ese caso la directiva toma como argumento una
expresi�n regular. Por ejemplo:
<DirectoryMatch "^/www/.(.+)?[0-9]{3}">
equivaldr� a los directorios en /www/ cuyo nombre
consista en tres n�meros.
<Directory>
si quiere una descripci�n completa de c�mo se usan
conjuntamente las expresiones regulares con la directiva <Directory>| Descripci�n: | Directorio principal que contiene la estructura de directorios visible desde la web |
|---|---|
| Sintaxis: | DocumentRoot directory-path |
| Valor por defecto: | DocumentRoot /usr/local/apache/htdocs |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
Esta directiva especifica el directorio desde el cu�l
httpd servir� los ficheros. A menos que
especifique alguna otra equivalencia mediante una directiva
Alias, el servidor
a�ade la ruta de la URL solicitada a este directorio para
construir la ruta del documento a servir. Ejemplo:
DocumentRoot /usr/web
esto quiere decir que una petici�n de acceso a
http://www.my.host.com/index.html se refiere a
/usr/web/index.html en el sistema de ficheros.
El directorio que especifique en
DocumentRoot debe escribirlo sin barra al
final.
| Descripci�n: | Permite el uso de mapeo de memoria para leer archivos mientras se sirven |
|---|---|
| Sintaxis: | EnableMMAP On|Off |
| Valor por defecto: | EnableMMAP On |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
Esta directiva controla si httpd puede usar
mapeo de memoria en caso de ser necesario para leer los contenidos
de un archivo al servirlo. Por defecto, cuando el tratamiento de
una petici�n requiere acceder a los datos dentro de un
fichero -- por ejemplo, cuando se sirve un fichero analizado
sint�cticamente por el servidor con el m�dulo
mod_include -- Apache mapea en memoria el archivo
si el sistema operativo soporta esa operaci�n.
El mapeo de memoria supone a veces una mejora en el rendimiento. Sin embargo, en ciertos entornos, es mejor desactivar el mapeo de memoria para evitar problemas operacionales:
httpd.DocumentRoot montado en NFS,
httpd podr�a abortar su ejecuci�n
debido a un fallo de segmentaci�n si el fichero se borra o se
trunca mientras que httpd lo tiene mapeado en
memoria.Para configuraciones del servidor que son sensibles a estos problemas, debe desactivar el uso del mapeo en memoria especificando:
EnableMMAP Off
Para ficheros montados en NFS, puede desactivar esta funcionalidad expl�citamente para los archivos implicados especificando:
<Directory "/path-to-nfs-files">
EnableMMAP Off
</Directory>
| Descripci�n: | Permite el uso del soporte de sendfile del kernel para servir ficheros @@@@@ Use the kernel sendfile support to deliver files to the client @@@@@ |
|---|---|
| Sintaxis: | EnableSendfile On|Off |
| Valor por defecto: | EnableSendfile On |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Disponible en las versiones de Apache 2.0.44 y posteriores |
Esta directiva controla si httpd puede usar
el soporte de sendfile del kernel para transmitir contenidos de
ficheros al cliente. Por defecto, cuando se est� procesando
una petici�n que no requiere acceso a los datos de un fichero
-- por ejemplo, cuando se sirve un fichero est�tico -- Apache
usa sendfile para servir los contenidos del fichero directamente a
la red, sin leer el fichero si el sistema operativo lo
permite.
El mecanismo sendfile evita operaciones separadas de lectura y env�o, y reservas de buffer. Sin embargo, en algunas plataformas o en algunos sistemas de ficheros, es mejor desactivar esa funcionalidad para evitar problemas operacionales:
DocumentRoot est�
montado en red (por ejemplo, NFS o SMB), el kernel puede que no
sea capaz de servir el fichero de red a trav�s de su
cache.Para configuraciones del servidor que son sensibles a estos problemas, debe desactivar esta funcionalidad especificando:
EnableSendfile Off
Para archivos montados en NFS o SMB, esta funcionalidad puede ser desactivada expl�citamente para los ficheros que puedan ocasionar problemas mediante:
<Directory "/path-to-nfs-files">
EnableSendfile Off
</Directory>
| Descripci�n: | Es lo que el servidor devuelve al cliente si se produce alg�n error |
|---|---|
| Sintaxis: | ErrorDocument error-code
document |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | El uso de las comillas (") en los mensajes de texto es diferente en Apache 2.0 |
En el caso de que aparezca un problema o error, puede configurar Apache para hacer una de las siguientes cuatro cosas,
La primera opci�n es la que se usa por defecto, mientras
que el resto se pueden configurar usando la directiva
ErrorDocument, la cual ha de seguirse del
c�digo de respuesta HTTP y una URL o un mensaje. Apache
ofrece a veces otra informaci�n adicional sobre el problema o
error.
Las URLs pueden empezar por una barra (/) para URLs locales, o pueden ser una URL completa que el cliente pueda resolver. Tambi�n se puede hacer que el nevagador despliegue un mensaje. Ejemplos:
ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Lo sentimos no podemos permitirle el acceso a esta p�gina hoy"
Adicionalmente, el valor especial default puede
ser usado para que Apache use los mensajes literales que trae por
defecto. Aunque bajo circunstancias normales no es necesario,
default restaura los mensajes literales de Apache en
configuraciones que de otra manera heredan una directiva
ErrorDocument ya existente.
ErrorDocument 404 /cgi-bin/bad_urls.pl
<Directory /web/docs>
ErrorDocument 404 default
</Directory>
Tenga en cuenta que si usted especifica en
ErrorDocument un contenido que apunta a una
URL remota (por ejemplo, cualquier cosa que empiece por
http), Apache redireccionar� al cliente, incluso
si al final, el documento al que redirecciona est� en el
mismo servidor. Esto tiene varias implicaciones, la m�s
importante es que el cliente no recibir� el c�digo de
error original, sino que en su lugar recibir� el c�digo
de estado del redireccionamiento. Esto puede confundir a los
robots web y otros clientes que tratan de determinar si una URL es
v�lida usando el c�digo de estado. Adem�s, si usa
una URL remota en un ErrorDocument 401, el cliente no
sabr� pedir contrase�as al usuario porque no
recibir� el c�digo de estado 401. Por tanto, si
usa una directiva ErrorDocument 401 entonces
debe referirse a un documento local.
Microsoft Internet Explorer (MSIE) ignorar� por defecto los mensajes de error generados por el servidor cuando sean "demasiado peque�os" y los sustituir� por mensajes de error propios. El tama�o se considera peque�o seg�n el tipo de error de que se trate, pero en general, si su mensaje de error es de m�s de 512 bytes, MSIE mostrar� en mensaje del error generado por el servidor y no el suyo. Puede encontrar m�s informaci�n sobre este asunto en el art�culo de la Base de Datos de Conocimiento de Microsoft Q294807.
En las versiones de Apache anteriores a la 2.0, los mensajes se indicaban a�adiendoles dobles comillas (") al principio que no se cerraban al final del mensaje.
| Descripci�n: | Ubicaci�n del fichero en el que se almacenan los mensajes de error |
|---|---|
| Sintaxis: | ErrorLog file-path|syslog[:facility] |
| Valor por defecto: | ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows y OS/2) |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
La directiva ErrorLog determina el
nombre del fichero en el cual el servidor almacenar� los
mensajes de error en caso de que ocurra alguno. Si el
file-path no es absoluto, entonces se asume que es
relativo al valor especificado en la directiva ServerRoot.
ErrorLog /var/log/httpd/error_log
Si el file-path empieza con un barra vertical (|) entonces se asume que es un comando para procesar el registro de errores (error_log).
ErrorLog "|/usr/local/bin/httpd_errors"
Usar syslog en lugar de un nombre de fichero
permite almanecer los mesajes mediante syslogd(8) si el sistema lo
soporta. Por defecto se usa la utilidad de syslog
local7, pero puede cambiar esto usando
syslog:facility donde facility
es cualquiera de los nombres normalmente documentados en
syslog(1).
ErrorLog syslog:user
SEGURIDAD: Consulte la secci�n consejos sobre seguridad para obtener m�s informaci�n sobre c�mo se compromete la seguridad de su sistema si sobre el directorio en que se almacenan los ficheros log tiene permisos cualquier usuario que no sea �nicamente el que arranca el servidor.
Cuando se especifica una ruta a un fichero en una plataforma que no es Unix, hay que tener cuidado de usar solo barras (/) aunque el sistema permita barras invertidas (\). En general, lo mejor es usar siempre barras / en los ficheros de configuraci�n.
| Descripci�n: | Atributos de fichero usados para crear la ETAG de la cabecera de respuesta HTTP |
|---|---|
| Sintaxis: | FileETag component ... |
| Valor por defecto: | FileETag INode MTime Size |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
La directiva FileETag configura los
atributos de fichero que se usan para crear la ETag
(etiqueta de entidad) del campo cabecera de respuesta cuando el
documento est� basado en un fichero. (El valor de
ETag se usa en la gesti�n de cache para ahorrar
ancho de banda.) En Apache 1.3.22 y en versiones anteriores, el
valor de ETag se formaba siempre a partir
del inodo del fichero, su tama�o y la hora y la fecha en que
se modific� por �ltima vez (mtime). La directiva
FileETag permite elegir cu�l de esos
elementos quiere usar -- si es que se quiere usar alguno. Las
palabras clave reconocidas son:
FileETag INode MTime Size
ETag ser� incluido en la respuestaLas palabras clave INode, MTime, y
Size pueden ir precedidas por + o
-, lo cual permite hacer cambios en la configuraci�n
heredada de un �mbito m�s amplio. Cualquier palabra clave que
aparezca sin un prefijo cancela inmediatamente la configuraci�n
heredada.
Si la configuraci�n para un directorio incluye
FileETag INode MTime Size, y la de un subdirectorio
incluye FileETag -INode, la configuraci�n para
ese subdirectorio (que ser� heredada por cualquier
subdirectorio que no tenga un configuraci�n propia) ser�
equivalente a FileETag MTime Size.
| Descripci�n: | Contiene directivas que se aplican a los ficheros cuyos nombres coincidan con los que se especifiquen |
|---|---|
| Sintaxis: | <Files filename> ... </Files> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| M�dulo: | core |
La directiva <Files> limita el �mbito de aplicaci�n de las directivas que incluye seg�n el nombre de los ficheros. Es
comparable a <Directory> y <Location>. Debe cerrarse con </Files>. Las directivas usadas en
esta secci�n se aplicar�n a cualquier objeto con un nombre base
(�ltimo componente del nombre de fichero) que coincida con el nombre de fichero especificado. Las
secciones <Files> se
procesan en el orden en que aparecen en el fichero de
configuraci�n, despu�s de las secciones <Directory> y de leer los
ficheros .htaccess, pero antes de las secciones
<Location>. Tenga en cuenta que las directivas <Files>
pueden anidarse dentro de las secciones <Directory> para restringir la parte del
sistema de ficheros a la que se aplican.
El argumento filename puede incluir un nombre de
fichero, o una cadena de car�cteres comod�n, donde ?
equivale a cualquier car�cter individual, y *
equivale a cualquier secuencia de caracteres. Tambi�n pueden
usarse expresiones regulares extendidas, con la ventaja de que
tambien se puede usar el car�cter ~. Por
ejemplo:
<Files ~ "\.(gif|jpe?g|png)$">
equivaldr�a a la mayor�a de los formatos gr�ficos de
Internet. No obstante, es mejor usar <FilesMatch>.
Tenga en cuenta que a diferencia de las secciones <Directory> y <Location>, las secciones
<Files> pueden usarse dentro
de los ficheros .htaccess. Esto permite a los
usuarios controlar el acceso a sus propios archivos, a un nivel de
fichero a fichero.
| Descripci�n: | Contiene las directivas que se aplican a los ficheros cuyos nombres equivalen a las expresiones regulares que se especifiquen |
|---|---|
| Sintaxis: | <FilesMatch regex> ... </FilesMatch> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Todas |
| Estado: | Core |
| M�dulo: | core |
La directiva <FilesMatch>
limita el rango de las directivas incluidas seg�n el nombre de los
ficheros, como hace la directiva <Files>. Sin embargo, acepta
expresiones regulares. Por ejemplo:
<FilesMatch "\.(gif|jpe?g|png)$">
equivaldr�a a la mayor�a de los formatos gr�ficos de Internet.
| Descripci�n: | Hace que todos los ficheros cuyos nombres tengan una equivalencia con con lo que se especifique sean servidos como contenido del tipo MIME que se establezca |
|---|---|
| Sintaxis: | ForceType MIME-type|None |
| Contexto: | directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Perteneciente al n�cleo del servidor a partir de la versi�n de Apache 2.0 |
Cuando se usa en un fichero .htaccess o en una
secci�n <Directory>, <Location> o <Files>, esta directiva hace que todos los
ficheros cuyos nombres guarden una equivalencia con lo
especificado sean servidos como contenido
MIME-type. Por ejemplo, si tiene un directorio lleno de
ficheros GIF, pero no quiere etiquetarlos con .gif,
puede usar:
ForceType image/gif
Tenga en cuenta que a diferencia de DefaultType, esta directiva prevalece sobre
todas las asociaciones de tipo MIME, incluidas las extensiones de
nombre de fichero que puedan identificar de qu� tipo es un fichero.
Puede hacer que ForceType no prevalezca sobre el resto de directivas usando el valor None:
# forzar a todos los tipos de fichero a ser tratados como imagen/gif:
<Location /images>
ForceType image/gif
</Location>
# pero permitir la asociaci�n de tipos MIME normal aqu�:
<Location /images/mixed>
ForceType None
</Location>
| Descripci�n: | Activa la resoluci�n de DNS de las direcciones IP de los clientes |
|---|---|
| Sintaxis: | HostnameLookups On|Off|Double |
| Valor por defecto: | HostnameLookups Off |
| Contexto: | server config, virtual host, directory |
| Estado: | Core |
| M�dulo: | core |
Esta directiva activa la resoluci�n de DNS de manera que
los nombres de host puedan ser guardados en los archivos log (y
pasados a CGIs/SSIs en REMOTE_HOST). El valor
Double se refiere a hacer una busqueda de DNSs
inversa doble. Esto es, despu�s de hacer una busqueda
inversa, se hace una busqueda normal posteriormente sobre ese
resultado. Al menos una de las direcciones IP en la b�squeda
posterior debe equivaler a la direcci�n IP original. (En
terminolog�a de "tcpwrappers" se llama
PARANOID.)
Independientemente de lo que se especifique, cuando
mod_access se usa para controlar el acceso por
nombre de host, se har� una consulta inversa doble. Esto se
hace por seguridad. Tenga en cuenta que el resultado de una
busqueda inversa doble no est� disponible generalmente a no
ser que especifique HostnameLookups Double. Por
ejemplo, si especifica solo HostnameLookups On y se
hace una petici�n a un objeto protegido por restricciones de
nombre de host, independientemente de si la consulta inversa doble
falla o no, el resultado de la consulta inversa simple se
pasar� a los CGIs en REMOTE_HOST.
El valor por defecto es Off para ahorrar
tr�fico de red en aquellos sitios web que realmente no
necesitan hacer b�squedas inversas dobles. Tambi�n es
mejor para los usuarios finales porque no tienen que sufrir el
retardo adicional que introducen las b�squedas. Los sitios
web con mucha carga deben usar en esta directiva el valor
Off, porque las b�squedas de DNSs pueden
consumir una cantidad de tiempo considerable. La utilidad
logresolve, compilada por defecto en el
subdirectorio bin de su directorio de
instalaci�n, puede usarse m�s tarde para buscar nombres
de host en direcciones IP que est�n en los logs cuando no
est� en l�nea.
| Descripci�n: | Activa que se registre en los archivos log la entidad RFC1413 del usuario remoto |
|---|---|
| Sintaxis: | IdentityCheck On|Off |
| Valor por defecto: | IdentityCheck Off |
| Contexto: | server config, virtual host, directory |
| Estado: | Core |
| M�dulo: | core |
Esta directiva permite el almacenamiento en logs, seg�n se especifica en el RFC1413, del nombre de usuario remoto para casda conexi�n cuando la m�quina del cliente corra "identd" o un programa similar. Esta informaci�n se registra en el log de acceso.
La informaci�n que se registra con este procedimiento no debe ser considerada como fiable excepto para controles rudimentarios.
Tenga en cuenta que esto puede provocar serios problemas de retardo en los accesos a su servidor porque para cada petici�n hay que ejecutar una consulta de este tipo. Cuando hay firewalls involucrados, cada b�squeda puede probablemente fallar y a�adir 30 segundos de retardo cada vez que se intenta un acceso. De modo que en general, su uso no es muy �til en servidores p�blicos accesibles desde Internet.
| Descripci�n: | Engloba directivas que ser�n procesadas solo si se cumple una determinada condici�n al iniciar el servidor |
|---|---|
| Sintaxis: | <IfDefine [!]parameter-name> ...
</IfDefine> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| M�dulo: | core |
La secci�n <IfDefine
test>...</IfDefine> se usa para marcar
directivas que son condicionales. Las directivas que hay dentro de
una secci�n <IfDefine> se
procesan solo si test devuelve un resultado
positivo. Si el test produce un resultado negativo,
todo lo que haya entre los marcadores de comienzo y final
ser� ignorado.
El test en la secci�n de directivas <IfDefine> puede tomar una de las
siguientes dos formas:
!parameter-nameEn el primer caso, las directivas entre los marcadores de comienzo y final se procesan solo si el par�metro llamado parameter-name est� definido. El segundo formato hace lo contrario, y procesa las directivas solo si parameter-name no est� definido.
El argumento parameter-name se define cuando se
ejecuta httpd por la l�nea de comandos con la opci�n
-Dparameter, al iniciar el servidor.
Las secciones <IfDefine>
son anidables, lo cual puede usarse para implementar tests
simples con varios par�metros. Ejemplo:
httpd -DReverseProxy ...
# httpd.conf
<IfDefine ReverseProxy>
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/libproxy.so
</IfDefine>
| Descripci�n: | Engloba directivas que se procesan de forma condicional seg�n est� presente o ausente un m�dulo espec�fico |
|---|---|
| Sintaxis: | <IfModule [!]module-name> ...
</IfModule> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Todas |
| Estado: | Core |
| M�dulo: | core |
La secci�n <IfModule
test>...</IfModule> se usa para marcar
las directivas que se aplican si est� presente un m�dulo
espec�fico. Las directivas dentro de una secci�n <IfModule> solo se procesan si el
test produce un resultado positivo. Si el test da falso, todo
lo que haya entre los marcadores de inicio y final es
ignorado.
El test de las secciones <IfModule> puede tomar una de las siguientes
formas:
En el primer caso, las directivas entre los marcadores de
comienzo y final son procesados solo si el m�dulo llamado
module name est� incluido en Apache -- ya sea
porque est� compilado en el servidor o porque est�
cargado din�micamente usando LoadModule. El segundo formato hace lo contrario, y
solo se procesan las directivas si el m�dulo module
name no est� incluido.
El argumento module name es el nombre del fichero del
m�dulo en el momento en que fue compilado. Por ejemplo,
mod_rewrite.c. Si un m�dulo consiste en varios
archivos fuente, use el nombre del fichero que contenga la cadena
de caracteres STANDARD20_MODULE_STUFF.
Las secciones <IfModule>
son anidables, lo cual puede usarse para implementar tests simples
con varios m�dulos.
<IfModule>.| Descripci�n: | Incluye otros ficheros de configuraci�n dentro de los ficheros de configuraci�n del servidor |
|---|---|
| Sintaxis: | Include file-path|directory-path |
| Contexto: | server config, virtual host, directory |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Se pueden usar caracteres comod�n para encontrar equivalencias en las versiones de Apache 2.0.41 y posteriores |
Esta directiva permite la inclusi�n de otros ficheros de configuraci�n dentro de los ficheros de configuraci�n del servidor.
Los caracteres comod�n de tipo shell (fnmatch())
pueden usarse para incluir varios ficheros de una vez por orden
alfab�tico. Adem�s, si Include apunta a un
directorio, en lugar de a un fichero, Apache leer� todos los
ficheros en ese directorio y sus subdirectorios. Sin embargo, no se
recomienda incluir subdirectorios enteros, porque es f�cil dejar
accidentalmente ficheros temporales en un directorio y esto
provocar� que httpd aborte.
La ruta del fichero especificada puede ser absoluta, o relativa
a un directorio respecto al valor especificado en ServerRoot.
Ejemplos:
Include /usr/local/apache2/conf/ssl.conf
Include /usr/local/apache2/conf/vhosts/*.conf
O especificando rutas relativas al directorio ServerRoot:
Include conf/ssl.conf
Include conf/vhosts/*.conf
Si ejecuta apachectl configtest le aparecer�
una lista con los ficheros que est�n siendo procesados
durante la comprobaci�n de la configuraci�n:
root@host# apachectl configtest
Processing config file: /usr/local/apache2/conf/ssl.conf
Processing config file: /usr/local/apache2/conf/vhosts/vhost1.conf
Processing config file: /usr/local/apache2/conf/vhosts/vhost2.conf
Syntax OK
| Descripci�n: | Permite que se establezcan conexiones HTTP persistentes |
|---|---|
| Sintaxis: | KeepAlive On|Off |
| Valor por defecto: | KeepAlive On |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
La extensi�n Keep-Alive de HTTP/1.0 y la funcionalidad de
conexi�n persistente de HTTP/1.1 facilitan la posibilidad de
que se establezcan sesiones HTTP de larga duraci�n que
permiten que se puedan enviar m�ltiples peticiones sobre la
misma conexi�n TCP. En algunos casos, esto tiene como
resultado una reducci�n de casi el 50% en los tiempos de
retardo en el caso de documentos con muchas im�genes. Para
activar las conexiones Keep-Alive, especifique KeepAlive
On.
Para clientes HTTP/1.0, las conexiones Keep-Alive se usar�n solo si el cliente lo solicita espec�ficamente. Adem�s, una conexi�n Keep-Alive con un cliente HTTP/1.0 puede usarse solo cuando el tama�o del contenido es conocido con antelaci�n. Esto implica que el contenido din�mico, como puede ser el resultado de un CGI, p�ginas SSI y listados de directorios generados por el servidor, no usar�n por lo general conexiones Keep-Alive para clientes HTTP/1.0. Para clientes HTTP/1.1, las conexiones persistentes son las que se usan por defecto a no ser que se especifique lo contrario. Si el cliente lo solicita, se usar� @@@@@ chunked encoding @@@@@ para enviar contenido de tama�o desconocido sobre conexiones persistentes.
| Descripci�n: | Tiempo que el servidor esperar� peticiones subsiguientes en conexiones persistentes |
|---|---|
| Sintaxis: | KeepAliveTimeout seconds |
| Valor por defecto: | KeepAliveTimeout 15 |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
Es el tiempo en segundos que Apache esperar� peticiones
subsiguientes antes de cerrar una conexi�n persistente. Una
vez que una petici�n ha sido recibida, se aplica el valor
especificado en la directiva Timeout para cerrar la
conexi�n.
Espeficificar un valor alto para
KeepAliveTimeout puede provocar un menor
rendimiento en servidores con mucha carga. Cuanto mayor sea el
valor de timeout, mayor ser� el n�mero de procesos del
servidor se mantendr�n ocupados esperando en conexiones con
clientes no activos.
| Descripci�n: | Restringe la aplicaci�n de los controles de acceso incluidos a solo ciertos m�todos HTTP |
|---|---|
| Sintaxis: | <Limit method [method] ... > ...
</Limit> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Todas |
| Estado: | Core |
| M�dulo: | core |
Los controles de acceso se aplican normalmente a
todos los m�todos de acceso, y este es el
comportamiento que se busca casi siempre. En general, las
directivas de control de acceso no deben estar dentro de una
secci�n <Limit>.
El prop�sito <Limit>
es restringir el efecto de los controles de acceso a los
m�todos HTTP que se especifiquen. Para los dem�s
m�todos, las restricciones de acceso que est�n incluidas
en <Limit> no
tendr�n efecto. Los siguientes ejemplos aplican el
control de acceso solo a los m�todos POST,
PUT, y DELETE, no afectando al resto de
m�todos:
<Limit POST PUT DELETE>
Require valid-user
</Limit>
Los m�todos incluidos en la lista pueden ser uno o
m�s de los siguientes: GET,
POST, PUT, DELETE,
CONNECT, OPTIONS, PATCH,
PROPFIND, PROPPATCH, MKCOL,
COPY, MOVE, LOCK, y
UNLOCK. Los nombres de los m�todos
distinguen may�sculas de min�sculas. Si usa
GET tambi�n se restringir�n las peticiones
HEAD. El m�todo TRACE no puede
limitarse.
<LimitExcept> en lugar de
una secci�n <Limit> cuando se quiere restringir el
acceso, porque una secci�n <LimitExcept> protege contra m�todos
arbitrarios.| Descripci�n: | Restringe los controles de acceso a todos los m�todos HTTP excepto a los que se especifiquen |
|---|---|
| Sintaxis: | <LimitExcept method [method] ... >
... </LimitExcept> |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Todas |
| Estado: | Core |
| M�dulo: | core |
<LimitExcept> y
</LimitExcept> se usan para englobar un grupo
de directivas de control de acceso que se aplicar�n a
cualquier m�todo de acceso HTTP no
especificado en los argumentos; es lo contrario a lo
que hace una secci�n <Limit> y puede usarse para controlar
tanto m�todos est�ndar como no est�ndar o
m�todos no reconocidos. Consulte la documentaci�n de
<Limit> para
m�s detalles.
Por ejemplo:
<LimitExcept POST GET>
Require valid-user
</LimitExcept>
| Descripci�n: | Determina el n�mero m�ximo de redirecciones internas y subpeticiones anidadas |
|---|---|
| Sintaxis: | LimitInternalRecursion number [number] |
| Valor por defecto: | LimitInternalRecursion 10 |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Disponible en las versiones Apache 2.0.47 y posteriores |
Una redirecci�n interna ocurre, por ejemplo, cuando se usa
la directiva Action,
la cual internamente redirige la petici�n original a un
script CGI. Una subpetici�n es un mecanismo de Apache para
saber qu� ocurrir�a si se produjera una petici�n a
una URI. Por ejemplo, mod_dir usa subpeticiones
para buscar archivos especificados en la directiva DirectoryIndex.
LimitInternalRecursion hace que el
servidor no sufra un error irrecuperable cuando entra en un ciclo
infinito de redirecciones internas o subpeticiones. Tales ciclos
se producen normalmente por errores de configuraci�n.
La directiva guarda dos l�mites diferentes, los cuales se eval�an en para cada petici�n. El primer n�mero es el n�mero m�ximo de redirecciones internas, que pueden producirse una detr�s de otra. El segundo n�mero determina, la profundidad a la que subpeticiones pueden anidarse. Si especifica solo un n�mero, se asignar� a ambos l�mites.
LimitInternalRecursion 5
| Descripci�n: | Restringe el tama�o total del cuerpo de las peticiones HTTP enviadas desde el cliente |
|---|---|
| Sintaxis: | LimitRequestBody bytes |
| Valor por defecto: | LimitRequestBody 0 |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Todas |
| Estado: | Core |
| M�dulo: | core |
Esta directiva especifica el n�mero de bytes desde 0 (que significa sin l�mite) hasta 2147483647 (2GB) que se permite que tenga el cuerpo de una petici�n.
La directiva LimitRequestBody permite al
usuario especificar un l�mite al tama�o del cuerpo del
mensaje de las peticiones dentro del contexto en el que la
directiva aparece (server, per-directory, per-file o
per-location). Si la petici�n del cliente excede ese
l�mite, el servidor devolver� una respuesta de error en
lugar de servir la petici�n. El tama�o del cuerpo del
mensaje de una petici�n normal var�a mucho en
funci�n de la naturaleza del recurso y los m�todos
permitidos para ese recurso. Los scripts CGI usan normamente el
cuerpo del mensaje para acceder la informaci�n de formularios
HTML. Las implementaciones del m�todo PUT
requerir�n un valor al menos del mismo tama�o que
cualquier representaci�n que el servidor desee aceptar para
ese recurso.
Esta directiva le da al administrador del servidor un mayor control sobre el comportamiento anormal de peticiones de clientes, lo cual puede ser �til para evitar algunos tipos de ataques de denegaci�n de servicio.
Si, por ejemplo, permite que se suban archivos a una ubicaci�n en concreto, y quiere limitar el tama�o de los ficheros que se suban a 100K, puede usar la siguiente directiva:
LimitRequestBody 102400
| Descripci�n: | Limita el n�mero de campos de la cabecera de las peticiones HTTP del cliente que ser�n aceptadas |
|---|---|
| Sintaxis: | LimitRequestFields number |
| Valor por defecto: | LimitRequestFields 100 |
| Contexto: | server config |
| Estado: | Core |
| M�dulo: | core |
Number es un entero entre 0 (sin l�mite) hasta
32767. El valor por defecto se define por la constante
DEFAULT_LIMIT_REQUEST_FIELDS al compilar (y es de 100
campos para la cabecera).
La directiva LimitRequestFields permite
al administrador del servidor modificar el l�mite del
n�mero de campos de la cabecera permitidos en una
petici�n HTTP. Este valor tiene que ser mayor que el
n�mero de campos que tiene la cabecera de una petici�n
normal de un cliente. El n�mero de campos de la cabecera de
una petici�n usados por un cliente raramente pasa de 20, pero
esto puede variar seg�n las diferentes implementaciones, a
menudo dependiendo incluso de la configuraci�n que un usuario
haya hecho de su navegador para soportar negociaci�n de
contenidos detallada. Las extensiones opcionales de HTTP se
expresan muchas veces usando campos de cabecera de
petici�n.
Esta directiva le da al administrador del servidor un mayor control sobre el comportamiento anormal de peticiones de clientes, lo cual puede ser �til para evitar algunos tipos de ataques de denegaci�n de servicio. Debe incrementar el valor que se especifica en esta directiva si a los clientes normales les llegan mensajes de error que indican que se han enviado demasiados campos de cabecera en la petici�n.
Por ejemplo:
LimitRequestFields 50
| Descripci�n: | Limita el tama�o permitido de las cabeceras de las peticiones HTTP de los clientes |
|---|---|
| Sintaxis: | LimitRequestFieldsize bytes |
| Valor por defecto: | LimitRequestFieldsize 8190 |
| Contexto: | server config |
| Estado: | Core |
| M�dulo: | core |
Esta directiva especifica el n�mero de bytes
desde 0 hasta el valor de la constante definida al compilar
DEFAULT_LIMIT_REQUEST_FIELDSIZE (8190 por defecto)
que ser� permitido para una cabecera de las peticiones
HTTP.
La directiva LimitRequestFieldSize
permite al administrador del servidor reducir el l�mite del
tama�o permitido de una cabecera de las peticiones HTTP por
debajo del tama�o del buffer de entrada compilado en el
servidor. Este valor tiene que ser lo suficientemente grande para
que no quede por debajo del tama�o normal de una cabecera de
petici�n de un cliente. El tama�o de una cabecera de una
petici�n var�a mucho en funci�n de la
implementaci�n del cliente, a menudo depende incluso de la
configuraci�n del navegador que haya hecho el usuario para
soportar negociaci�n de contenido detallada.
Esta directiva le da al administrador del servidor un mayor control sobre el comportamiento anormal de peticiones de clientes, lo cual puede ser �til para evitar algunos tipos de ataques de denegaci�n de servicio.
Por ejemplo:
LimitRequestFieldSize 4094
| Descripci�n: | Limita el tama�o la l�nea de petici�n HTTP que ser� aceptada |
|---|---|
| Sintaxis: | LimitRequestLine bytes |
| Valor por defecto: | LimitRequestLine 8190 |
| Contexto: | server config |
| Estado: | Core |
| M�dulo: | core |
Esta directiva especifica el n�mero de bytes de
0 hasta el valor de la constante definida al compilar
DEFAULT_LIMIT_REQUEST_LINE ( @@@@ 8190 as distributed @@@@ ) que
se permitir� para la l�nea de petici�n HTTP.
La directiva LimitRequestLine permite al
administrador del servidor reducir el l�mite de tama�o
permitido de la l�nea de petici�n de las peticiones HTTP
de los clientes por debajo del tama�o del buffer de entrada
compilado con el servidor. Como la l�nea de petici�n
consiste en el m�todo HTTP, la URI y la versi�n del
protocolo, la directiva LimitRequestLine
impone una restricci�n en la longitud de la URI de la
petici�n permitida por el servidor. Este valor tiene que ser
lo suficientemente grande como para que admita el tama�o de
sus nombres de recurso, incluida la informaci�n que puede
ser pasada como parte de consulta de una petici�n
GET.
Esta directiva le da al administrador del servidor un mayor control sobre el comportamiento anormal de peticiones de clientes, lo cual puede ser �til para evitar algunos tipos de ataques de denegaci�n de servicio.
Por ejemplo:
LimitRequestLine 4094
| Descripci�n: | Limita el tama�o del cuerpo de una petici�n XML |
|---|---|
| Sintaxis: | LimitXMLRequestBody bytes |
| Valor por defecto: | LimitXMLRequestBody 1000000 |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| M�dulo: | core |
L�mite (en bytes) o tama�o m�ximo del cuerpo de una petici�n
basada en XML. Si se especifica el valor 0 se
desactiva este control.
Ejemplo:
LimitXMLRequestBody 0
| Descripci�n: | Aplica las directivas que contiene solo a las URLs que tengan una equivalencia con los valores que se especifiquen |
|---|---|
| Sintaxis: | <Location
URL-path|URL> ... </Location> |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
Una secci�n <Location>
aplica las directivas que contiene seg�n la URL de que se
trate. Es parecida a la directiva <Directory>, y tiene que terminar con una
directiva </Location>. Las secciones <Location> se procesan en el orden en que
aparecen en el fichero de configuraci�n, despu�s de leer
las secciones <Directory> y los ficheros
.htaccess, y despu�s de las secciones <Files>.
Las secciones <Location>
operan completamente fuera del sistema de ficheros. Esto tiene
varias consecuencias. La m�s importante, es que las
directivas <Location> no deben
usarse para controlar el acceso a ubicaciones del sistema de
ficheros. Como diferentes URLs pueden corresponderse con una misma
ubicaci�n de un sistema de ficheros, tales controles de
acceso pueden ser burlados.
<Location>Use <Location> para aplicar
las directivas que va a incluir a contenido que est� fuera
del sistema de ficheros. Para el contenido que est� en el
sistema de ficheros, use <Directory> y <Files>. Una excepci�n a esto es el
uso de <Location />, que es un modo f�cil
de aplicar una configuraci�n a un servidor entero.
Para todas las peticiones que no provengan de servidores proxy,
la URL de la que se buscan equivalencias es una ruta URL de la
forma /path/. Ning�n esquema, nombre de host,
puerto o cadena de consulta puede incluirse. Para peticiones
provenientes de servidores proxy, la URL de la que se buscan
euivalencias es de la forma scheme://servername/path,
y debe incluir el prefijo.
La URL puede usar caracteres comod�n. En una cadena de
caracteres comod�n, ? equivale a cualquier
car�cter, y * equivale a cualquier secuencia de
caracteres.
Tambi�n pueden usarse expresiones regulares extendidas,
con el car�cter adicional ~. Por ejemplo:
<Location ~ "/(extra|special)/data">
equivaldr� a las URLs que contengan la subcadena
/extra/data o /special/data. La
directiva <LocationMatch> se comporta de igual modo
que la versi�n de regex de <Location>.
El uso de <Location> es
especialmente �til cuando se combina con la directiva
SetHandler. Por ejemplo, para
permitir peticiones de status, pero solo de navegadores que
intenten acceder a foo.com, puede usar:
<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>
El
car�cter de la barra tiene un significado especial
dependiendo del lugar donde aparece en una URL. Los usuarios
puede estar no estar acostumbrada a que la barra tenga distintos
significados, por ejemplo, en los sistemas de ficheros, varias
barras consecutivas tienen el mismo significado que una sola
barra (por ejemplo, /home///foo es lo mismo que
/home/foo). Para las URL's esto no se cumple. La
directiva <LocationMatch> y la versi�n de
regex de <Location>
requieren que se especifiquen expl�citamente m�ltiples
barras solo si esa es su intenci�n.
Por ejemplo, <LocationMatch ^/abc>
podr�a equivaler a la petici�n de la URL
/abc pero no a la petici�n de la URL
//abc. La directiva (no regex) <Location> se comporta de manera similar cuando se
usa para peticiones provenientes de servidores proxy. Sin
embargo, cuando la directiva (no regex) <Location> se usa para peticiones no
provenientes de servidores proxy, a efectos de encontrar
equivalencias, m�ltiples barras equivaldr�n a una
sola. Por ejemplo, si especifica <Location
/abc/def> y la petici�n es a
/abc//def se producir� equivalencia.
| Descripci�n: | Aplica las directiva que incluye solo a las URLs que tengan equivalencia con alguna de las expresiones regulares que se especifiquen |
|---|---|
| Sintaxis: | <LocationMatch
regex> ... </LocationMatch> |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
La directiva <LocationMatch> limita la aplicaci�n
de las directivas que incluye a URLs que tengan equivalencia con
alguna de las expresiones regulares que se especifican, de manera
id�ntica a como lo hace <Location>. Sin embargo, toma las
expresiones regulares como argumentos en lugar de como una cadena
de caracteres. Por ejemplo:
<LocationMatch "/(extra|special)/data">
equivaldr�a a las URLs que contengan la subcadena
/extra/data � /special/data.
| Descripci�n: | Controla la extensi�n de los mensajes que se almacenan en el ErrorLog |
|---|---|
| Sintaxis: | LogLevel level |
| Valor por defecto: | LogLevel warn |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
LogLevel especifica el nivel al que se
detallan los errores que se almacenan en los logs de errores
(consulte la directiva ErrorLog). Los niveles
(levels) disponibles son, por orden decreciente:
| Level | Description | Example |
|---|---|---|
emerg |
Emergencias - sistema inutilizable. | "Un proceso hijo no puede abrir el fichero de lock (lock file). El programa va a terminar" |
alert |
Debe hacer algo inmediatamente. | "getpwuid: no pudo determinar el nombre de usuario a partir del uid" |
crit |
Condiciones cr�ticas. | "socket: No se encontr� un socket adecuado, el proceso hijo va a terminar" |
error |
Condiciones de error. | "Final prematuro de la cabecera del script"" |
warn |
Condiciones de advertencia. | "el proceso hijo 1234 no ha terminado, enviando otra vez SIGHUP" |
notice |
Condici�n normal, pero significativa. | "httpd: interceptada se�al SIGBUS, intentando hacer un volcado de memoria en ..." |
info |
Informaci�n. | "El servidor parece estar ocupado, (puede que necesite incrementar StartServers, o Min/MaxSpareServers)..." |
debug |
Mensajes de nivel debug | "Abriendo el fichero de configuraci�n ..." |
Cuando se especifica un determinado nivel, se escriben en el
log tambi�n los mensajes de todos los dem�s niveles por
encima. Por ejemplo, cuando se especifica LogLevel
info, tambi�n se escribir�n en el log los
mensajes de los niveles notice y
warn.
Se recomienda usar, al menos, el nivel crit.
Por ejemplo:
LogLevel notice
Cuando el fichero log es un fichero
normal y se escriben en el mensajes de nivel
notice, estos mensajes no podr�n ser
borrados. Sin embargo, esto no se aplica cuando se usa
syslog.
| Descripci�n: | N�mero de peticiones permitidas en una conexi�n persistente |
|---|---|
| Sintaxis: | MaxKeepAliveRequests number |
| Valor por defecto: | MaxKeepAliveRequests 100 |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
La directiva MaxKeepAliveRequests limita
el n�mero de peticiones permitidas por conexi�n cuando
KeepAlive est�
activado. Si se especifica el valor 0, el n�mero
de peticiones permitidas es ilimitado. Se recomienda que en esta
directiva se especifique un valor alto para obtener el m�ximo
rendimiento del servidor.
Por ejemplo:
MaxKeepAliveRequests 500
| Descripci�n: | Number of ranges allowed before returning the complete resource |
|---|---|
| Sintaxis: | MaxRanges default | unlimited | none | number-of-ranges |
| Valor por defecto: | MaxRanges 200 |
| Contexto: | server config, virtual host, directory |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Available in Apache HTTP Server 2.0.65 and later |
The documentation for this directive has not been translated yet. Please have a look at the English version.
| Descripci�n: | Designa una direcci�n IP para usar hosting virtual basado en nombres |
|---|---|
| Sintaxis: | NameVirtualHost addr[:port] |
| Contexto: | server config |
| Estado: | Core |
| M�dulo: | core |
Es necesario usar la directiva
NameVirtualHost es necesario usarla si
quiere configurar hosts virtuales basados en
nombres.
Aunque addr puede ser un nombre de host, se recomienda que use siempre una direcci�n IP, por ejemplo:
NameVirtualHost 111.22.33.44
Con la directiva NameVirtualHost se
especifica la direcci�n IP en la cual el servidor
recibir� las peticiones para los hosts virtuales basados en
nombres. Bsta ser� normalmente la direcci�n a la cual su
host virtual basado en nombres se resuelve. En los casos en que en
las peticiones las recibe un firewall (cortafuegos) o un proxy y
las redirige a una direcci�n IP diferente del servidor, debe
especificar la direcci�n IP del adaptador de red f�sico
de la m�quina que servir� las peticiones. Si tiene
m�ltiples hosts basados en nombres o m�ltiples
direcciones, repita la directiva para cada direcci�n.
Tenga en cuenta, que el "servidor principal" y cualquier
servidor _default_ nunca
servir�n una petici�n a un direcci�n IP
NameVirtualHost (a menos que por alguna
raz�n use NameVirtualHost pero no
especifique ning�n VirtualHost para
esa direcci�n).
De manera opcional puede especificar un n�mero de puerto en el que debe usarse el host virtual basado en el nombre, por ejemplo
NameVirtualHost 111.22.33.44:8080
Las direcciones IPv6 deben escribirse entre corchetes, como se muestra en el siguiente ejemplo:
NameVirtualHost [2001:db8::a00:20ff:fea7:ccea]:8080
Para recibir peticiones en todas las interfaces de red, puede
usar * como argumento
NameVirtualHost *
<VirtualHost>Tenga en cuenta que el argumento de la directiva <VirtualHost> debe coincidir
exactamente con el de la directiva NameVirtualHost.
NameVirtualHost 1.2.3.4
<VirtualHost 1.2.3.4>
# ...
</VirtualHost>
| Descripci�n: | Configura las funcionalidades disponibles en un directorio en particular |
|---|---|
| Sintaxis: | Options
[+|-]option [[+|-]option] ... |
| Valor por defecto: | Options All |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Options |
| Estado: | Core |
| M�dulo: | core |
La directiva Options controla qu�
funcionalidades del servidor est�n disponibles en un
directorio en particular.
En option puede especificar None, en
cuyo caso ninguna funcionalidad adicional estar� activada, o
puede especificar una o m�s de las siguientes opciones:
AllMultiViews. Este es
el valor por defecto.ExecCGImod_cgi.FollowSymLinksAunque el servidor siga los enlaces simb�licos, eso
no cambia la ruta usada para encontrar equivalencias en
las secciones <Directory>.
Tenga en cuenta
tambi�n que esta opci�n es ignorada si est�
dentro de una secci�n <Location>.
Includesmod_include.IncludesNOEXEC#exec cmd
y #exec cgi son desactivados. Aunque es posible
#include virtual (incluir de forma virtual) scripts
CGI desde directorios especificados con ScriptAlias.IndexesDirectoryIndex
(por ejemplo, index.html) en ese directorio,
entonces mod_autoindex devolver� una lista con
los contenidos del directorio.MultiViewsmod_negotiation.SymLinksIfOwnerMatch<Location>.Normalmente, si se pueden aplicar m�ltiples
Options a un directorio, entonces la
m�s espec�fica se aplica y las dem�s se ignoran;
las opciones no se fusionan. (Consulte c�mo se fusionan las
secciones.) Sin embargo, si todas las opciones en la
directiva Options van precedidas de un
s�mbolo + o -, las opciones se
fusionan. Cualquier opci�n precedida de un + se
a�ade a las opciones en ese momento activas, y las opciones
precedidas de un - se quitan de las activas en ese
momento.
Por ejemplo, sin ning�n s�mbolo + o
-:
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options Includes
</Directory>
entoces solo Includes tendr� efecto para el
directorio /web/docs/spec. Sin embargo, si la segunda
directiva Options usara un s�mbolo
+ y otro -:
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options +Includes -Indexes
</Directory>
entonces las opciones FollowSymLinks e
Includes estar�n activas para el directorio
/web/docs/spec.
El uso de -IncludesNOEXEC o -Includes
desactiva server-side includes completamente independientemente
de la configuraci�n anterior.
El comportamiento por defecto en ausencia de ninguna
configuraci�n es All.
| Descripci�n: | Selecciona qu� usuarios autentificados pueden acceder a un recurso |
|---|---|
| Sintaxis: | Require entity-name [entity-name] ... |
| Contexto: | directory, .htaccess |
| Prevalece sobre: | AuthConfig |
| Estado: | Core |
| M�dulo: | core |
Esta directiva selecciona qu� usuarios autentificados pueden acceder a un recurso. La sintaxis a usar es:
Require user userid [userid]
...Require group group-name [group-name]
...Require valid-userRequire debe ser usada de forma conjunta
con las directivas AuthName,
AuthType, y con directivas
como AuthUserFile y
AuthGroupFile (para
definir usuarios y grupos) para funcionar
correctamente. Ejemplo:
AuthType Basic
AuthName "Restricted Resource"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin
Los controles de acceso que se aplican de esta manera son
efectivos para todos los
m�todos. Esto es lo que normalmente se
quiere. Si quiere aplicar controles de acceso solo a
m�todos espec�ficos, mientras se dejan otros
m�todos sin protecci�n, use la directiva
Require en una secci�n <Limit>.
| Descripci�n: | Limita el consumo de tiempo de CPU que pueden hacer proceses creados por procesos hijo de Apache |
|---|---|
| Sintaxis: | RLimitCPU seconds|max [seconds|max] |
| Valor por defecto: | Unset; usa el valor por defecto del sistema operativo |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Todas |
| Estado: | Core |
| M�dulo: | core |
Toma 1 � 2 par�metros. El primer par�metro
se refiere al l�mite flexible de recursos para todos los
procesos y el segundo par�metro especifica el l�mite
m�ximo de recursos. Cada uno de los par�metros puede ser
un n�mero, � max para indicarle al servidor que
el l�mite debe fijarse al m�ximo permitido por la
configuraci�n del sistema operativo. Para elevar el
l�mite m�ximo de recursos es necesario que se est�
ejecutando el servidor como ususario root, o estar en
la fase inicial del arranque.
Esto se aplica a procesos nacidos de procesos hijo de Apache que est�n sirviendo peticiones, no a los procesos hijo de Apache propiamente dichos. Esto incluye a los scripts CGI y a los comandos de ejecuci�n SSI, pero no a procesos nacidos del proceso padre Apache tales como ficheros de registro redireccionados (piped logs).
Los l�mites de consumo de tiempo de la CPU se expresan en segundos por proceso.
| Descripci�n: | Limita el consumo de memoria que pueden hacer procesos creados por procesos hijo de Apache |
|---|---|
| Sintaxis: | RLimitMEM bytes|max [bytes|max] |
| Valor por defecto: | Unset; usa el valor por defecto del sistema operativo |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Todas |
| Estado: | Core |
| M�dulo: | core |
Toma 1 � 2 par�metros. El primer par�metro
especifica el l�mite flexible de recursos para todos los
procesos y el segundo par�metro especifica el l�mite
m�ximo de recursos. Cada uno de los par�metros puede ser
un n�mero, � max para indicarle al servidor que
el l�mite debe fijarse al m�ximo permitido por la
configuraci�n del sistema operativo. Para elevar el
l�mite m�ximo de recursos es necesario que se est�
ejecutando el servidor como ususario root, o estar en
la fase inicial del arranque.
Esto se aplica a procesos nacidos de procesos hijo de Apache que est�n sirviendo peticiones, no a los procesos hijo de Apache propiamente dichos. Esto incluye a los scripts CGI y a los comandos de ejecuci�n SSI, pero no a procesos nacidos del proceso padre Apache tales como ficheros de registro redireccionados (piped logs).
Los l�mites de consumo de memoria se expresan en bytes por proceso.
| Descripci�n: | Limita el n�mero de procesos que pueden crearse por parte de procesos creados por procesos hijo de Apache |
|---|---|
| Sintaxis: | RLimitNPROC number|max [number|max] |
| Valor por defecto: | Unset; usa el valor por defecto del sistema operativo |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | Todas |
| Estado: | Core |
| M�dulo: | core |
Toma 1 � 2 par�metros. El primer par�metro
especifica el l�mite flexible de recursos para todos los
procesos y el segundo par�metro especifica el l�mite
m�ximo de recursos. Cada uno de los par�metros puede ser
un n�mero, � max para indicarle al servidor que
el l�mite debe fijarse al m�ximo permitido por la
configuraci�n del sistema operativo. Para elevar el
l�mite m�ximo de recursos es necesario que se est�
ejecutando el servidor como usuario root, o estar en
la fase inicial del arranque.
Esto se aplica a procesos nacidos de la divisi�n de procesos hijo de Apache que est�n sirviendo peticiones, no a los procesos hijo de Apache propiamente dichos. Esto incluye a los scripts CGI y a los comandos de ejecuci�n SSI, pero no a procesos nacidos de la divisi�n del proceso padre Apache tales como ficheros de registro redireccionados (piped logs).
Limita el n�mero de procesos por usuario.
Si los procesos CGI
no est�n siendo ejecutados por
identificadores de usuario diferentes del identificador de
usuario que est� ejecutando el servidor web, esta directiva
limitar� el n�mero de procesos que el servidor puede
crear. Como resultado de esta situaci�n, en el
error_log aparecer�n mensajes del tipo
cannot fork.
| Descripci�n: | Interacci�n entre el control de acceso basado en host y la autentificaci�n de usuarios |
|---|---|
| Sintaxis: | Satisfy Any|All |
| Valor por defecto: | Satisfy All |
| Contexto: | directory, .htaccess |
| Prevalece sobre: | AuthConfig |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Influenciada por <Limit> y <LimitExcept> en las versiones de Apache 2.0.51 y
posteriores |
Especifica la pol�tica de acceso a seguir cuando se usan tanto
Allow como Require. El par�metro puede ser
All o Any. Esta directiva es solo �til
si se va restringir el acceso a un �rea concreta con un nombre de
usuario/contrase�a y direcci�n del cliente. En este caso
el comportamiento por defecto (All) es para requerir
que el cliente pase la restricci�n referente a la direcci�n
e introduzca un nombre de usuario y contrase�a
v�lidos. Con la opci�n Any el cliente podr� acceder
si cumple la restricci�n referente a la direcci�n o si introduce un
nombre de usuario y contrase�as v�lidos. Esto puede usarse para
restringir el acceso a una zona con una contrase�a, pero permitir
a los clientes de algunas direcciones en concreto que accedan sin
tener que introducir contrase�a alguna.
Por ejemplo, si quiere permitir que todo el mundo tenga acceso total a su intranet o a una parte de si sitio web, pero requerir que los visitantes de fuera de su intranet introduzcan una contrase�a, puede usar una configuraci�n similar a la siguiente:
Require valid-user
Allow from 192.168.1
Satisfy Any
A partir de la versi�n de Apache 2.0.51, puede limitarse
la aplicaci�n de las directivas
Satisfy a determinados m�todos en
particular mediante secciones <Limit> y <LimitExcept>.
| Descripci�n: | T�cnica para ubicar el int�rprete de scripts CGI's |
|---|---|
| Sintaxis: | ScriptInterpreterSource Registry|Registry-Strict|Script |
| Valor por defecto: | ScriptInterpreterSource Script |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Solo sistemas Windows; la opci�
Registry-Strict est� disponible en las versiones de
Apache 2.0 y posteriores |
Esta directiva se usa para controlar la manera que Apache
encuentra el int�rprete usado para ejecutar scripts CGI. La
configuraci�n por defecto es Script. Esto hace que
Apache use el int�rprete que aparece en la primera l�nea, la que
empieza por #!) en el script. En los sistemas Win32
esta l�nea tiene un aspecto similar a:
#!C:/Perl/bin/perl.exe
o, si perl est� en el PATH,
simplemente:
#!perl
Usar ScriptInterpreterSource Registry har�
que se busque en el Registro de Windows, en
HKEY_CLASSES_ROOT con la extensi�n del fichero
de script (por ejemplo, .pl) como clave de
b�squeda. El comando definido por la subclave del registro de
Windows Shell\ExecCGI\Command o, si esta no existe,
por la subclave Shell\Open\Command se usa para abrir
el script. Si no se encuentra ning�n resutlado, Apache
recurre al comportamiento de la opci�n
Script.
Tenga cuidado
cuando use ScriptInterpreterSource Registry con
ScriptAlias para
directorios, porque Apache intentar� ejecutar
cada fichero dentro de ese directorio. Lo
especificado en Registry puede causar llamadas
indeseadas a programas que normalmente no se ejecutan. Por
ejemplo, el programa por defecto para abrir ficheros
.htm en la mayor�a de los sistemas Windows es
Microsoft Internet Explorer, entonces cualquier petici�n HTTP
de un fichero .htm que exista dentro del script del
directorio har� que el ejecute de fondo el navegador en el
servidor. Con esto el servidor se bloquear� en m�s o
menos un minuto.
La opci�n Registry-Strict que es nueva en
Apache 2.0 hace lo mismo que Registry pero usa solo
la subclave Shell\ExecCGI\Command. La clave
ExecCGI no es de uso com�n. Debe ser configurada
manualmente en el registro de Windows y por tanto previene la
ejecuci�n accidental de procesos en su sistema.
| Descripci�n: | Direcci�n de email que el servidor incluye en los mensajes de error que se env�an al cliente |
|---|---|
| Sintaxis: | ServerAdmin email-address |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
ServerAdmin especifica la direcci�n de
e-mail que el servidor incluye en cualquier mensaje de error que
env�a al cliente.
Ser�a conveniente tener una direcci�n de email solo para esto, por ejemplo
ServerAdmin [email protected]
ya que los usuarios no siempre mencionan que est�n hablando del servidor!
| Descripci�n: | Nombres alternativos usados para un host cuando se intentan encontrar equivalencias a hosts virtuales basados en el nombre |
|---|---|
| Sintaxis: | ServerAlias hostname [hostname] ... |
| Contexto: | virtual host |
| Estado: | Core |
| M�dulo: | core |
ServerAlias especifica los nombres
alternativos para un host, para usarlo con hosts virtuales basados en el
nombre.
<VirtualHost *>
ServerName example.com
ServerAlias example.com server2
# ...
</VirtualHost>
| Descripci�n: | Nombre de host y n�mero de puerto que el servidor usa para identificarse |
|---|---|
| Sintaxis: | ServerName fully-qualified-domain-name[:port] |
| Contexto: | server config, virtual host |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | En la versi�n 2.0, esta directiva sustituye la
funcionalidad de la direciva Port de la
versi�n 1.3. |
La directiva ServerName especifica el
nombre de host y el puerto que usa el servidor para
identificarse. Esto se usa cuando se hace redirecci�n de URLs. Por
ejemplo, si el nombre de la maquina del servidor web es
simple.example.com, pero el la maquina tambi�n tiene
el alias DNS www.example.com y quiere que el servidor
web se identifique as�, debe usar la siguiente directiva:
ServerName www.example.com:80
Si no especifa ServerName, entonces el
servidor intentar� deducir en nombre de host haciendo una
busqueda reversa en la direcci�n IP. Si no se especifica
ning�n puerto en ServerName, entonces
el servidor usar� el puerto para las peticiones
entrantes. Para disfrutar de la m�xima fiabilidad y
predictibilidad, debe especificar explicitamente un nombre de host
y un puerto usando la directiva
ServerName.
Si est� usando hosts
virtuales basados en el nombre, la directiva
ServerName dentro de una secci�n <VirtualHost> especifica
qu� nombre de host debe aparecer en la cabecera de petici�n
Host: para coincidir con ese host virtual.
Consulte la descripci�n de la directiva UseCanonicalName para configuraciones
que determinan si URLs autoreferenciadas (por ejemplo, por el
m�dulo mod_dir module) se referir�n al puerto
especificado, o al n�mero de puerto dado en la petici�n del
cliente.
| Descripci�n: | URL que se usar� para hosts virtuales basados en nombre que son accedidos con un navegador incompatible |
|---|---|
| Sintaxis: | ServerPath URL-path |
| Contexto: | virtual host |
| Estado: | Core |
| M�dulo: | core |
The ServerPath directive sets the legacy
URL pathname for a host, for use with name-based virtual hosts.
| Descripci�n: | Directorio base de la instalaci�n del servidor |
|---|---|
| Sintaxis: | ServerRoot directory-path |
| Valor por defecto: | ServerRoot /usr/local/apache |
| Contexto: | server config |
| Estado: | Core |
| M�dulo: | core |
La directiva ServerRoot especifica el
directorio en el que ha sido instalado el servidor. Normalmente
contendr� los subdirectorios conf/ y
logs/. Las rutas que se especifican en otras
directivas (por ejemplo en Include o LoadModule) se toman como relativas a
este directorio.
ServerRoot /home/httpd
-d de
httpdServerRoot| Descripci�n: | Configura el pie de p�gina en documentos generados por el servidor |
|---|---|
| Sintaxis: | ServerSignature On|Off|EMail |
| Valor por defecto: | ServerSignature Off |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | All |
| Estado: | Core |
| M�dulo: | core |
La directiva ServerSignature permite la
configuraci�n de un pie de p�gina que se
a�adir� a documentos generados por el sevidor (mensajes
de error, listado de directorios generados por
mod_proxy, salida de
mod_info...). La raz�n por la que puede no
querer a�adir este pie de p�gina, es que en una cadena
de proxies, el usuario a menudo no tiene posibilidad de establecer
cual de los servidores encadenados ha retornado un mensaje de
error.
Esta directiva usa por defecto el valor Off, que
suprime la generaci�n del pie de p�gina (y por tanto, es
compatible con el comportamiento de Apache 1.2 y las versiones
anteriores). Si usa el valor On simplemte se
a�ade una l�nea con el n�mero de versi�n y el
valor de ServerName para el
host virtual que est� respondiendo la petici�n, y el
valor EMail crea las referencias adicionales
"mailto:" a lo especificado en la directiva ServerAdmin.
En las versiones 2.0.44 y posteriores, los detalles del n�mero
de la versi�n del servidor son controlados por la directiva
ServerTokens.
| Descripci�n: | Configura la cabecera de respuesta HTTP
Server |
|---|---|
| Sintaxis: | ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full |
| Valor por defecto: | ServerTokens Full |
| Contexto: | server config |
| Estado: | Core |
| M�dulo: | core |
Esta directiva controla si el campo Server de las
cabeceras de las respuestas que se env�an de vuelta a los clientes
incluye una descripci�n del sistema operativo gen�rico del
servidor as� como informaci�n sobre los modulos compilados en el
servidor.
ServerTokens Prod[uctOnly]Server:
ApacheServerTokens MajorServer:
Apache/2ServerTokens MinorServer:
Apache/2.0ServerTokens Min[imal]Server:
Apache/2.0.41ServerTokens OSServer: Apache/2.0.41
(Unix)ServerTokens Full (or not specified)Server: Apache/2.0.41
(Unix) PHP/4.2.2 MyMod/1.2Esta configuraci�n se aplica al servidor entero, y no puede ser activada o desactivada para unos hosts virtuales s� y para otros no.
En las versiones posteriores a la 2.0.44, esta directiva
tambi�n controla la informaci�n especificada en la directiva
ServerSignature.
| Descripci�n: | Hace que todos los ficheros que correspondan con el valor especificado sean procesados obligatoriamente por un handler |
|---|---|
| Sintaxis: | SetHandler handler-name|None |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Trasladado al n�cleo del servidor en Apache 2.0 |
Cuando se usa en un fichero .htaccess o en una
secci�n <Directory> r <Location>, esta directiva hace que todos
los ficheros cuyo nombre tenga equivalencia con el valor que
especifica sean tratados por el handler dado en
handler-name. Por ejemplo, si tiene un directorio cuyo
contenido quiere que sea tratado como as fichero de reglas de
mapas de im�genes, independientemente de las extensiones,
puede poner lo siguiente en un fichero .htaccess en
ese directorio:
SetHandler imap-file
Otro ejemplo: si quiere que el servidor despliegue un resumen
de su estado cuando se llame a una URL de
http://servername/status, puede poner lo siguiente en
el fichero httpd.conf:
<Location /status>
SetHandler server-status
</Location>
Puede evitar que se aplique lo especificado anteriormente en
una directiva SetHandler usando el valor
None.
| Descripci�n: | Especifica los filtros que procesar�n las peticiones de los clientes y el contenido de peticiones POST |
|---|---|
| Sintaxis: | SetInputFilter filter[;filter...] |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
La directiva SetInputFilter espcifica el
filtro o filtros que procesar�n las peticiones de los
clientes y el contenido de peticiones POST cuando son recibidas
por el servidor. El filtro o filtros especificados en esta
directiva se aplican adem�s de los definidos en otras partes,
incluyendo los especificados en la directiva AddInputFilter.
Si se especifica m�s de un filtro, deben separarse con puntos y comas en el orden en que deban procesar los contenidos.
| Descripci�n: | Especifica los filtros que procesar�n las respuestas del servidor |
|---|---|
| Sintaxis: | SetOutputFilter filter[;filter...] |
| Contexto: | server config, virtual host, directory, .htaccess |
| Prevalece sobre: | FileInfo |
| Estado: | Core |
| M�dulo: | core |
La directiva SetOutputFilter especifica
los filtros se usar�n para procesar las respuestas del servidor
antes de enviarlas al cliente. Esto es adem�s de los filtros
definidos en otras partes, incluidos los de la directiva
AddOutputFilter.
Por ejemplo, la siguiente configuraci�n procesar� todos los
archivos en el directorio /www/data/ con server-side
includes.
<Directory /www/data/>
SetOutputFilter INCLUDES
</Directory>
Si se especifica m�s de un filtro, deben separarse con puntos y comas en el orden en que deban procesar los contenidos.
| Descripci�n: | Cantidad de tiempo que el servidor esperar� para que ocurran determinados eventos antes de cerrar una petici�n |
|---|---|
| Sintaxis: | TimeOut seconds |
| Valor por defecto: | TimeOut 300 |
| Contexto: | server config |
| Estado: | Core |
| M�dulo: | core |
La directiva TimeOut define ahora la
cantidad de tiempo que Apache esperar� para tres cosas:
Lo planeado es hacer configurable por separado cada una de estas cosas. La cantidad de tiempo por defecto de 1200 usada antes de la versi�n 1.2, ha sido reducida hasta 300, que es en la mayor parte de las situaciones m�s de lo necesario. El tiempo usado por defecto no es menor porque puede que haya alguna parte del c�digo en que el contador de tiempo no se pone a cero como deber�a cuando se env�a un paquete.
| Descripci�n: | Determines the behaviour on TRACE
requests |
|---|---|
| Sintaxis: | TraceEnable [on|off|extended] |
| Valor por defecto: | TraceEnable on |
| Contexto: | server config |
| Estado: | Core |
| M�dulo: | core |
| Compatibilidad: | Available in Apache 1.3.34, 2.0.55 and later |
The documentation for this directive has not been translated yet. Please have a look at the English version.
| Descripci�n: | Configura la forma en que el servidor determina su propio nombre u puerto |
|---|---|
| Sintaxis: | UseCanonicalName On|Off|DNS |
| Valor por defecto: | UseCanonicalName On |
| Contexto: | server config, virtual host, directory |
| Estado: | Core |
| M�dulo: | core |
En muchas ocasiones, Apache tiene que construir una URL
autoreferenciada -- esto es, una URL que se refiere de
vuelta al mismo servidor. Con UseCanonicalName On
Apache usar� el nombre de host y puerto que est�n especificados en
la directiva ServerName para
construir el nombre can�nico del servidor. Este nombre se usa en
todas las URLs autoreferenciadas, y para los valores de
SERVER_NAME y SERVER_PORT en los
CGIs.
Con UseCanonicalName Off Apache formar� las
URLs autoreferenciadas usando el nombre de host y puerto
suministrados por el cliente. Si se ha suministrado esa
informaci�n (si no se ha suministrado, se usar� el
nombre can�nico, tal y como se ha definido arriba). Estos
valores son los mismos que se usan para implementar hosting virtual basado en
nombres, y est�n disponibles con los mismos clientes. Las
variables de CGI SERVER_NAME y
SERVER_PORT se construir�n con la
informaci�n suministrada por los clientes.
Un ejemplo de donde esto puede ser �til es en un servidor de
una intranet, donde los usuarios se conectan a la m�quina usando
nombres cortos como www. Se dar� cuenta de que si los
usuarios teclean un nombre corto, y una URL que es un directorio,
tal como http://www/splat, sin una barra al
final entonces Apache los rediccionar� a
http://www.domain.com/splat/. Si tiene la
autenfificaci�n activada, esto har� que el usuario se tenga que
autentificar dos veces (una para www y otra para
www.domain.com -- consulte las
preguntas m�s frecuentes sobre este asunto para obtener m�s
informaci�n). Pero si especifica el valor Off en
la directiva UseCanonicalName, entonces
Apache redireccionar� a http://www/splat/.
Hay una tercera opci�n, UseCanonicalName DNS, para
el caso en que se usa hosting virtual masivo basado en IP para
soportar clientes antiguos que no env�an la cabecera
Host:. Con esta opci�n Apache hace una busqueda de
DNS reversa en la direcci�n IP del servidor al que el cliente se
conect� para hacer funcionar las URLs autoreferenciadas.
Si los CGIs asumen los valores de SERVER_NAME,
puede que no funcionen con esta opci�n. El cliente es
esencialmente libre de dar cualquier valor que quiera como nombre
de host. Pero si el CGI solo usa SERVER_NAME para
constrir URLs autoreferenciadas, entonces no debe haber ning�n
problema.
| Descripci�n: | Contiene las directivas que se aplican solo a un nombre de host espec�fico o direcci�n IP |
|---|---|
| Sintaxis: | <VirtualHost
addr[:port] [addr[:port]]
...> ... </VirtualHost> |
| Contexto: | server config |
| Estado: | Core |
| M�dulo: | core |
<VirtualHost> y
</VirtualHost> se usan para incluir un grupo de
directivas que se aplicar�n solo a un host virtual en
particular. Cualquier directiva que est� permitido usar en un
contexto virtual host puede usarse. Cuando el servidor recibe una
petici�n de un documento de un host virtual en concreto, usa las
directivas de configuraci�n incluidas en la secci�n <VirtualHost>. Addr puede
ser:
*, el cual puede usarse en
combinaci�n con NameVirtualHost * para que
equivalga a todas las direcciones IP; o_default_, que se usa
solo con hosting virtual IP para detectar direcciones IP sin
emparejar.
<VirtualHost 10.1.2.3>
ServerAdmin [email protected]
DocumentRoot /www/docs/host.foo.com
ServerName host.foo.com
ErrorLog logs/host.foo.com-error_log
TransferLog logs/host.foo.com-access_log
</VirtualHost>
Las direcciones IPv6 deben especificarse entre corchetes porque el n�mero de puerto opcional no podr�a determinarse si no se hace as�. Un ejemplo de direcci�n IPv6 se mustra aqu� abajo:
<VirtualHost [2001:db8::a00:20ff:fea7:ccea]>
ServerAdmin [email protected]
DocumentRoot /www/docs/host.example.com
ServerName host.example.com
ErrorLog logs/host.example.com-error_log
TransferLog logs/host.example.com-access_log
</VirtualHost>
Cada host virtual se corresponde con una direcci�n IP
diferente, un n�mero de puerto diferente o un nombre de host
diferente para el servidor, en el primer caso la m�quina del
servidor debe estar configurada para aceptar paquetes IP para
m�ltiples direcciones. (Si la m�quina no tiene m�ltiples infaces
de red, entonces esto puede conseguirse con el comando
ifconfig alias -- si su sistema operativo lo
soporta).
El uso de <VirtualHost> no afecta
a las direcciones en las que escucha Apache. Puede que necesite
asegurarse de que Apache est� escuchando en la direcci�n correcta
usando Listen.
Cuando se usa hosting virtual basado en IP, puede
especificarse el nombre especial _default_, en cuyo
caso, este host virtual equivaldr� a cualquier direcci�n IP que no
est� especificamente listada en otro host virtual. En ausencia de
un host virtual _default_ el server config
"principal", consistente en todas las definiciones fuera de una
secci�n VirtualHost, se usa cuando la IP no coincide con ninguna.
(Pero tenga en cuenta que cualquier direcci�n IP que equivalga a
la directiva NameVirtualHost
no usar� ni el server config "principal" ni el host virtual
_default_ virtual host. Consulte la documentaci�n de
hosting virtual basado en
nombres para obtener m�s informaci�n.)
Puede especificar :port para cambiar el puerto
de equivalencia. Si no especifica ninguno, entonces por defecto se
usa el mismo puerto de la directiva Listen mas reciente del servidor
principal. Tambi�n puede especificar :* para hacer
coincidir con todos los puertos en esa direcci�n. (Esto se
recomienda cuando se usa con _default_.)
Consulte la documentaci�n de consejos de seguridad para obtener m�s informaci�n sobre por qu� pone en riesgo la seguridad si en el directorio donde almacena los archivos log tiene permisos de escritura alguien que no sea el usuario que inicia el servidor.