Funcionalidad Básica de Apache

AcceptPathInfo Directiva

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

Una petición será aceptada solamente si se refiere literalmente a una ruta que existe. Por tanto, una petición con información de path añadida (trailing pathname information) después de un nombre de fichero que existe, del tipo /test/here.html/more como en el ejemplo de arriba, devolverá el mensaje de error 404 NOT FOUND.

On

Una petición será aceptada si la componente anterior a la información de path añadida (trailing pathname information) se refiere a un fichero que existe. El ejemplo de arriba /test/here.html/more será aceptado si /test/here.html se refiere a un fichero válido.

Default

El tratamiento de las peticiones con información de path añadida (trailing pathname information) está determinado por el handler responsable de la petición. El handler básico para ficheros normales rechaza por defecto las peticiones de PATH_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:

AccessFileName Directiva

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:

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

Consulte también

• AllowOverride
• Ficheros de Configuración
• Ficheros .htaccess

AddDefaultCharset Directiva

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 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".

Consulte también

• AddCharset

AddOutputFilterByType Directiva

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.

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.

Consulte también

• AddOutputFilter
• SetOutputFilter
• Filtros

AllowEncodedSlashes Directiva

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.

Consulte también

• AcceptPathInfo

AllowOverride Directiva

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.

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.

AuthConfig

Permite usar directivas de autentificación (AuthDBMGroupFile, AuthDBMUserFile, AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, etc.).

FileInfo

Permite usar directivas que controlan los tipos de documento (DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, y mod_mime las directivas Add* y Remove*, etc.).

Indexes

Permite el uso de directivas que controlan el indexado de directorios (AddDescription, AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName, etc.).

Limit

Permite el uso de directivas que controlan el acceso al host (Allow, Deny y Order).

Options

Permite usar directivas que controlan funcionalidades específicas de directorios (Options y XBitHack).

Ejemplo:

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.

Consulte también

• AccessFileName
• Ficheros de Configuración
• Ficheros .htaccess

AuthName Directiva

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:

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.

Consulte también

• Autentificación, Autorización y Control de Acceso

AuthType Directiva

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.

Consulte también

• >Autentificación, Autorización y Control de Acceso

CGIMapExtension Directiva

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.

ContentDigest Directiva

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:

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.

DefaultType Directiva

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:

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.

<Directory> Directiva

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:

También pueden usar expresiones regulares extendidas, añadiendo el carácter ~. Por ejemplo:

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

para acceder al documento /home/web/dir/doc.html los pasos son:

• Se aplica la directiva AllowOverride None (desactivando los ficheros .htaccess).
• Se aplica la directiva AllowOverride FileInfo (para el directorio /home).
• Se aplica cualquier directiva 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

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

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>.

Consulte también

• Documentación de cómo funcionan las secciones <Directory>, <Location> y <Files> para obtener más información sobre la forma en que se combinan estas secciones cuando se recibe una petición

<DirectoryMatch> Directiva

<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:

equivaldrá a los directorios en /www/ cuyo nombre consista en tres números.

Consulte también

• <Directory> si quiere una descripción completa de cómo se usan conjuntamente las expresiones regulares con la directiva <Directory>
• Modo de funcionamiento de las secciones <Directory>, <Location> y <Files> para obtener más información sobre como se combinan estas secciones cuando se recibe una petición

DocumentRoot Directiva

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:

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.

Consulte también

• Cómo traducir URLs a ubicaciones del sistema de ficheros

EnableMMAP Directiva

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:

• En algunos sistemas con más de un procesador, el mapeo de memoria puede reducir el rendimiento de httpd.
• Con un 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:

Para ficheros montados en NFS, puede desactivar esta funcionalidad explícitamente para los archivos implicados especificando:

EnableSendfile Directiva

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:

• En algunas plataformas puede que el soporte de sendfile no funcione porque al compilar Apache no se detectó correctamente, especialmente si los binarios fueron construidos en una máquina y después se han trasladado a otra cuando el soporte para sendfile ya no funcionaba.
• En Linux, el uso de send file provoca fallos de comprobación de TCP_checksum en ciertas tarjetas de red que usan IPv6
• Si 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:

Para archivos montados en NFS o SMB, esta funcionalidad puede ser desactivada explícitamente para los ficheros que puedan ocasionar problemas mediante:

ErrorDocument Directiva

En el caso de que aparezca un problema o error, puede configurar Apache para hacer una de las siguientes cuatro cosas,

1. devolver un mensaje de error estándar
2. devolver un mensaje de error personalizado
3. redireccionar la petición a una ruta-URL local
4. redireccionar la petición a una URL externa

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:

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.

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.

Consulte también

• Documentación sobre personalización de respuestas

ErrorLog Directiva

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.

Si el file-path empieza con un barra vertical (|) entonces se asume que es un comando para procesar el registro de errores (error_log).

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).

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.

Consulte también

• LogLevel
• Archivos Log de Apache

FileETag Directiva

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:

INode

Para incluir el número de inodo en el cálculo

MTime

Para incluir en el cálculo la hora y la fecha en que el fichero fue modificado por última vez

Size

Para incluir en el cálculo el número de bytes que ocupa el fichero

All

Para incluir en el cálculo todos los campos disponibles. Esto es equivalente a:

FileETag INode MTime Size

None

Si el documento está basado en un fichero, ningún campo ETag será incluido en la respuesta

Las 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.

<Files> Directiva

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:

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.

Consulte también

• Cómo funcionan las secciones <Directory>, <Location> and <Files> para obtener una información más detallada sobre cómo se combinan estas diferentes secciones cuando se recibe una petición

<FilesMatch> Directiva

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:

equivaldría a la mayoría de los formatos gráficos de Internet.

Consulte también

• Cómo funcionan las secciones <Directory>, <Location> and <Files> para obtener información detallada sobre la forma en que estas secciones se combinan cuando se recibe una petición

ForceType Directiva

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:

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:

HostnameLookups Directiva

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.

IdentityCheck Directiva

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.

<IfDefine> Directiva

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-name
• !parameter-name

En 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:

<IfModule> Directiva

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:

• module name
• !module name

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.

Include Directiva

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:

O especificando rutas relativas al directorio ServerRoot:

Si ejecuta apachectl configtest le aparecerá una lista con los ficheros que están siendo procesados durante la comprobación de la configuración:

Consulte también

• apachectl

KeepAlive Directiva

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.

Consulte también

• MaxKeepAliveRequests

KeepAliveTimeout Directiva

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.

<Limit> Directiva

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:

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> Directiva

<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:

LimitInternalRecursion Directiva

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.

LimitRequestBody Directiva

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:

LimitRequestFields Directiva

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:

LimitRequestFieldSize Directiva

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:

LimitRequestLine Directiva

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:

LimitXMLRequestBody Directiva

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:

<Location> Directiva

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.

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:

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:

Consulte también

• Cómo funcionan las secciones <Directory>, <Location> y <Files> si quiere obtener una información detallada sobre cómo se combinan esas secciones cuando se recibe una petición

<LocationMatch> Directiva

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:

equivaldría a las URLs que contengan la subcadena /extra/data ó /special/data.

Consulte también

• Cómo funcionan las secciones <Directory>, <Location> y <Files> si quiere obtener una explicación detallada de cómo se combinan esas secciones cuando se recibe una petición

LogLevel Directiva

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:

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:

MaxKeepAliveRequests Directiva

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:

NameVirtualHost Directiva

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:

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.

De manera opcional puede especificar un número de puerto en el que debe usarse el host virtual basado en el nombre, por ejemplo

Las direcciones IPv6 deben escribirse entre corchetes, como se muestra en el siguiente ejemplo:

Para recibir peticiones en todas las interfaces de red, puede usar * como argumento