From: André Malo Date: Mon, 18 Apr 2005 15:43:00 +0000 (+0000) Subject: Update Spanish translation X-Git-Tag: 2.0.55~244 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=8299941328b3b284b1c7b105542f9af6332524f6;p=thirdparty%2Fapache%2Fhttpd.git Update Spanish translation Translated by: Jesús Blanco Reviewed by: Daniel López * docs/manual/mod/core.xml.es New file git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x@161768 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/core.xml.es b/docs/manual/mod/core.xml.es new file mode 100644 index 00000000000..185daae431d --- /dev/null +++ b/docs/manual/mod/core.xml.es @@ -0,0 +1,3382 @@ + + + + + + + + + +core +Funcionalidades básicas del servidor HTTP Apache que +están siempre presentes +Core + + +AcceptPathInfo +Especifica si los recursos aceptan información de +path añadida (trailing pathname information) +AcceptPathInfo On|Off|Default +AcceptPathInfo Default +server config +virtual hostdirectory +.htaccess +FileInfo +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
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-isa, 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> + + + + + + +AccessFileName +Nombre del fichero de configuración distribuida +AccessFileName filename [filename] ... +AccessFileName .htaccess +server configvirtual host + + + +

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> + + +AllowOverride +Ficheros de Configuración +Ficheros .htaccess + + + +AddDefaultCharset +Parámetro del conjunto de caracteres que se +añade cuando el tipo de contenido de una respuesta es +text/plain o text/html +AddDefaultCharset On|Off|charset +AddDefaultCharset Off +server config +virtual hostdirectory +.htaccess +FileInfo + + +

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

+ +AddCharset + + + +AddOutputFilterByType +Asigna un filtro de +salida a un tipo MIME en particular +AddOutputFilterByType filter[;filter...] +MIME-type [MIME-type] ... +server config virtual +hostdirectory +.htaccess +FileInfo +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> + + + Nota

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.

+ + + +AddOutputFilter +SetOutputFilter +Filtros + + + +AllowEncodedSlashes +Determina si se acepta el uso de separadores de +ubicación codificados en las URLs +AllowEncodedSlashes On|Off +AllowEncodedSlashes Off +server configvirtual host + +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.

+ + Nota

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.

+ + +AcceptPathInfo + + + +AllowOverride +Tipos de directivas que cuyo uso está permitido en los ficheros .htaccess +AllowOverride All|None|directive-type +[directive-type] ... +AllowOverride All +directory + + +

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.

+ + Solamente disponible en las secciones + <Directory> + + 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.

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

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

+ + +AccessFileName +Ficheros de +Configuración +Ficheros .htaccess + + + +AuthName +Ambito de autorización para su uso en +autentificación HTTP +AuthName auth-domain +directory.htaccess + +AuthConfig + + +

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.

+ + + Autentificación, Autorización y + Control de Acceso + + + +AuthType +Tipo de autentificación de usuarios +AuthType Basic|Digest +directory.htaccess + +AuthConfig + + +

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.

+ +>Autentificación, Autorización y +Control de Acceso + + + +CGIMapExtension Técnica para localizar +un intérprete de scripts CGI +CGIMapExtension cgi-path +.extension +directory.htaccess + +FileInfo +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.

+ + + + +ContentDigest +Activa la generación de cabeceras de respuesta HTTP +Content-MD5 +ContentDigest On|Off +ContentDigest Off +server configvirtual host +directory.htaccess + +Options +Experimental + + +

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.

+ + + + +DefaultType +Tipo de contenido MIME por defecto que usará el servidor si no +puede determinar el tipo MIME en concreto del documento a servir +DefaultType MIME-type +DefaultType text/plain +server configvirtual host +directory.htaccess + +FileInfo + + +

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.

+ + + + +Directory Engloba a un grupo de directivas +que se aplicarán solamente al directorio del sistema de ficheros +especificado y a sus subdirectorios +<Directory directory-path> +... </Directory> server +configvirtual host + + + +

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:

+ +
    +
  • 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

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

+ +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 Incluye las directivas que se +aplican a los directorios y subdirectorios del sistema de ficheros que +equivalen a una expresión regular +<DirectoryMatch regex> +... </DirectoryMatch> server +configvirtual host + + + +

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 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 +Directorio principal que contiene la estructura de +directorios visible desde la web +DocumentRoot directory-path +DocumentRoot /usr/local/apache/htdocs +server configvirtual host + + + +

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.

+ +Cómo traducir URLs a +ubicaciones del sistema de ficheros + + + +EnableMMAP +Permite el uso de mapeo de memoria para leer archivos mientras se +sirven +EnableMMAP On|Off +EnableMMAP On +server configvirtual host +directory.htaccess + +FileInfo + + +

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:

+ + + 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> + + + + + +EnableSendfile +Permite el uso del soporte de sendfile del kernel para servir ficheros @@@@@ Use the kernel sendfile support to deliver files to the client @@@@@ +EnableSendfile On|Off +EnableSendfile On +server configvirtual host +directory.htaccess + +FileInfo +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:

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

+ + + 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> + + + + + +ErrorDocument +Es lo que el servidor devuelve al cliente si se produce +algún error +ErrorDocument error-code +document server +configvirtual host +directory.htaccess + +FileInfo 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,

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

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.

+ + +Documentación sobre +personalización de respuestas + + + +ErrorLog +Ubicación del fichero en +el que se almacenan los mensajes de error + ErrorLog file-path|syslog[:facility] +ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows y OS/2) +server configvirtual host + + + +

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.

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

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

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

+ + Nota

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.

+ + +LogLevel +Archivos Log de Apache + + + +FileETag +Atributos de fichero usados para crear la ETAG de la +cabecera de respuesta HTTP +FileETag component ... +FileETag INode MTime Size +server configvirtual host +directory.htaccess + +FileInfo + + +

+ 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 +Contiene directivas que se aplican a los ficheros cuyos +nombres coincidan con los que se especifiquen +<Files filename> ... </Files> +server configvirtual host +directory.htaccess + +All + + +

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.

+ + +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 +Contiene las directivas que se aplican a los ficheros +cuyos nombres equivalen a las expresiones regulares que se especifiquen +<FilesMatch regex> ... </FilesMatch> +server configvirtual host +directory.htaccess + +Todas + + +

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.

+ + +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 +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 +ForceType MIME-type|None +directory.htaccess + +FileInfo +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> + + + + + +HostnameLookups Activa la resolución de +DNS de las direcciones IP de los clientes +HostnameLookups On|Off|Double +HostnameLookups Off server +configvirtual host +directory + + +

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 +Activa que se registre en los archivos log la entidad RFC1413 del usuario remoto +IdentityCheck On|Off +IdentityCheck Off +server configvirtual host +directory + +

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 +Engloba directivas que serán procesadas solo si se +cumple una determinada condición al iniciar el servidor +<IfDefine [!]parameter-name> ... + </IfDefine> +server configvirtual host +directory.htaccess + +All + + +

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:

+ + + httpd -DReverseProxy ...
+
+ # httpd.conf
+ <IfDefine ReverseProxy>
+ + LoadModule rewrite_module modules/mod_rewrite.so
+ LoadModule proxy_module modules/libproxy.so
+ + </IfDefine> + + + + + +IfModule +Engloba directivas que se procesan de forma condicional +según esté presente o ausente un módulo específico +<IfModule [!]module-name> ... + </IfModule> +server configvirtual host +directory.htaccess + +Todas + + +

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.

+ + Esta sección debe usarse solo si necesita tener un + fichero de configuración que funcione tanto si está como + si no está un determinado módulo disponible. En + condiciones normales, no es necesario usar directivas en + secciones IfModule. + + + + +Include +Incluye otros ficheros de configuración dentro de +los ficheros de configuración del servidor +Include file-path|directory-path +server configvirtual host +directory + +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 + + + +apachectl + + + +KeepAlive +Permite que se establezcan conexiones HTTP +persistentes +KeepAlive On|Off +KeepAlive On +server configvirtual host + + + +

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.

+ + +MaxKeepAliveRequests + + + +KeepAliveTimeout +Tiempo que el servidor esperará peticiones subsiguientes +en conexiones persistentes +KeepAliveTimeout seconds +KeepAliveTimeout 15 +server configvirtual host + + + +

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 +Restringe la aplicación de los controles de acceso incluidos a solo ciertos métodos HTTP +<Limit method [method] ... > ... + </Limit> +server configvirtual host +directory.htaccess + +Todas + + +

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.

+ + Es mejor usar una sección LimitExcept en lugar de + una sección Limit cuando se quiere restringir el + acceso, porque una sección LimitExcept protege contra métodos + arbitrarios. + + + + + +LimitExcept +Restringe los controles de acceso a todos los métodos +HTTP excepto a los que se especifiquen +<LimitExcept method [method] ... > + ... </LimitExcept> +server configvirtual host +directory.htaccess + +Todas + + +

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> + + + + + + +LimitInternalRecursion +Determina el número máximo de redirecciones internas y +subpeticiones anidadas +LimitInternalRecursion number [number] +LimitInternalRecursion 10 +server configvirtual host + +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.

+ + Ejemplo + LimitInternalRecursion 5 + + + + + +LimitRequestBody +Restringe el tamaño total del cuerpo de las peticiones +HTTP enviadas desde el cliente +LimitRequestBody bytes +LimitRequestBody 0 +server configvirtual host +directory.htaccess + +Todas + + +

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 + + + + + + +LimitRequestFields +Limita el número de campos de la cabecera de las +peticiones HTTP del cliente que serán aceptadas +LimitRequestFields number +LimitRequestFields 100 +server config + + +

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 + + + + + + +LimitRequestFieldSize +Limita el tamaño permitido de las cabeceras de las peticiones HTTP de los clientes +LimitRequestFieldsize bytes +LimitRequestFieldsize 8190 +server config + + +

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 + + + En condiciones normales, no debe modificarse el valor que + viene por defecto. + + + + + +LimitRequestLine +Limita el tamaño la línea de petición HTTP que será +aceptada +LimitRequestLine bytes +LimitRequestLine 8190 +server config + + +

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 + + + En condiciones normales, no debe modificarse el valor que + viene por defecto. + + + + +LimitXMLRequestBody +Limita el tamaño del cuerpo de una petición XML +LimitXMLRequestBody bytes +LimitXMLRequestBody 1000000 +server configvirtual host +directory.htaccess +All + + +

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 + + + + + + +Location +Aplica las directivas que contiene solo a las URLs que tengan una equivalencia con los valores que se especifiquen +<Location + URL-path|URL> ... </Location> +server configvirtual host + + + +

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.

+ + Cuándo usar <directive + type="section">Location</directive> + +

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> + + + Comentarios sobre la barra : /

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.

+ + +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 +Aplica las directiva que incluye solo a las URLs que tengan equivalencia con alguna de las expresiones regulares que se especifiquen +<LocationMatch + regex> ... </LocationMatch> +server configvirtual host + + + +

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.

+ + +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 +Controla la extensión de los mensajes que se almacenan +en el ErrorLog +LogLevel level +LogLevel warn +server configvirtual host + + + +

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 + + + Nota

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.

+ + + + + +MaxKeepAliveRequests +Número de peticiones permitidas en una conexión +persistente +MaxKeepAliveRequests number +MaxKeepAliveRequests 100 +server configvirtual host + + + +

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 + + + + + +NameVirtualHost +Designa una dirección IP para usar hosting virtual basado en nombres +NameVirtualHost addr[:port] +server config + + +

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.

+ + Nota +

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 [fe80::a00:20ff:fea7:ccea]:8080 + + +

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

+ + + NameVirtualHost * + + + Argumento de la directiva <directive type="section">VirtualHost</directive> +

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>
+ + + + +Documentación sobre hosting +virtual + + + + +Options +Configura las funcionalidades disponibles en un directorio en particular +Options + [+|-]option [[+|-]option] ... +Options All +server configvirtual host +directory.htaccess + +Options + + +

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:

+ +
+
All
+ +
Todas las opciones excepto MultiViews. Este es + el valor por defecto.
+ +
ExecCGI
+ +
Se permite la ejecución de scripts CGI usando + mod_cgi.
+ +
FollowSymLinks
+ +
+ + El servidor seguirá los enlaces simbólicos en este + directorio + +

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

+ +
Includes
+ +
+ Permite el uso de Server-side includes, del módulo mod_include.
+ +
IncludesNOEXEC
+ +
+ + Permite el uso de Server-side includes, pero #exec cmd + y #exec cgi son desactivados. Aunque es posible + #include virtual (incluir de forma virtual) scripts + CGI desde directorios especificados con ScriptAlias.
+ +
Indexes
+ +
+ Si se produce una petición a una URL que se corresponde con un directorio, + y no hay DirectoryIndex + (por ejemplo, index.html) en ese directorio, + entonces mod_autoindex devolverá una lista con + los contenidos del directorio.
+ +
MultiViews
+ +
+ Se permiten "MultiViews" de contenido negociado + "MultiViews" usando mod_negotiation.
+ +
SymLinksIfOwnerMatch
+ +
El servidor seguirá los enlaces simbólicos en los que el + fichero o directorio final pertenezca al mismo usuario que el + enlace. + + Nota Esta opción es ignorada si se pone + dentro de una sección 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.

+ + + Nota +

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.

+ + + + +Require +Selecciona qué usuarios autentificados pueden acceder a +un recurso +Require entity-name [entity-name] ... +directory.htaccess + +AuthConfig + + +

Esta directiva selecciona qué usuarios autentificados pueden + acceder a un recurso. La sintaxis a usar es:

+ +
+
Require user userid [userid] + ...
+
Solo los usuarios mencionados pueden acceder al + recurso.
+ +
Require group group-name [group-name] + ...
+
Solo los usuarios pertenecientes a los grupos mencionados + pueden acceder al recurso.
+ +
Require valid-user
+
Todos los usarios pueden acceder al recurso.
+
+ +

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

+ +Satisfy +mod_access + + + +RLimitCPU +Limita el consumo de tiempo de CPU que pueden hacer proceses creados +por procesos hijo de Apache +RLimitCPU seconds|max [seconds|max] +Unset; usa el valor por defecto del sistema operativo +server configvirtual host +directory.htaccess +Todas + + +

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.

+ +RLimitMEM +RLimitNPROC + + + +RLimitMEM +Limita el consumo de memoria que pueden hacer procesos creados por procesos hijo de Apache +RLimitMEM bytes|max [bytes|max] +Unset; usa el valor por defecto del sistema operativo +server configvirtual host +directory.htaccess +Todas + + +

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.

+ +RLimitCPU +RLimitNPROC + + + +RLimitNPROC +Limita el número de procesos que pueden crearse por parte de +procesos creados por procesos hijo de Apache +RLimitNPROC number|max [number|max] +Unset; usa el valor por defecto del sistema operativo +server configvirtual host +directory.htaccess +Todas + + +

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.

+ + Nota

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.

+ + +RLimitMEM +RLimitCPU + + + +Satisfy +Interacción entre el control de acceso basado en host +y la autentificación de usuarios +Satisfy Any|All +Satisfy All +directory.htaccess + +AuthConfig +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.

+ + + + Allow + Require + + + +ScriptInterpreterSource +Técnica para ubicar el intérprete de scripts CGI's +ScriptInterpreterSource Registry|Registry-Strict|Script +ScriptInterpreterSource Script +server configvirtual host +directory.htaccess +FileInfo +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.

+ + Seguridad

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.

+ + + + +ServerAdmin +Dirección de email que el servidor incluye en los +mensajes de error que se envían al cliente +ServerAdmin email-address +server configvirtual host + + + +

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 www-admin@foo.example.com + +

ya que los usuarios no siempre mencionan que están hablando + del servidor!

+ + + + +ServerAlias +Nombres alternativos usados para un host cuando se +intentan encontrar equivalencias a hosts virtuales basados en el +nombre +ServerAlias hostname [hostname] ... +virtual host + + +

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> + + +Documentación sobre hosting virtual con +Apache + + + +ServerName +Nombre de host y número de puerto que el servidor usa +para identificarse +ServerName fully-qualified-domain-name[:port] +server configvirtual host + +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. +

+ + +Problemas relacionados en DNS y +Apache +Documentación sobre hosting +virtual +UseCanonicalName +NameVirtualHost +ServerAlias + + + +ServerPath +URL que se usará para hosts virtuales basados en +nombre que son accedidos con un navegador incompatible +ServerPath URL-path +virtual host + + +

The ServerPath directive sets the legacy + URL pathname for a host, for use with name-based virtual hosts.

+ +Documentación sobre hosting virtual + + + +ServerRoot +Directorio base de la instalación del servidor +ServerRoot directory-path +ServerRoot /usr/local/apache +server config + + +

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.

+ + Example + ServerRoot /home/httpd + + + +la opción -d de + httpd consejos se + seguridad para más información de como establecer + adecuadamente los permisos en + ServerRoot + + + +ServerSignature +Configura el pie de página en documentos generados +por el servidor +ServerSignature On|Off|EMail +ServerSignature Off +server configvirtual host +directory.htaccess + +All + + +

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.

+ +ServerTokens + + + +ServerTokens +Configura la cabecera de respuesta HTTP +Server +ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full +ServerTokens Full +server config + + +

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]
+ +
El servidor envía (por ejemplo): Server: + Apache
+ +
ServerTokens Major
+ +
El servidor envía (por ejemplo): Server: + Apache/2
+ +
ServerTokens Minor
+ +
El servidor envía (por ejemplo): Server: + Apache/2.0
+ +
ServerTokens Min[imal]
+ +
El servidor envía (por ejemplo): Server: + Apache/2.0.41
+ +
ServerTokens OS
+ +
El servidor envía (por ejemplo): Server: Apache/2.0.41 + (Unix)
+ +
ServerTokens Full (or not specified)
+ +
El servidor envía (por ejemplo): Server: Apache/2.0.41 + (Unix) PHP/4.2.2 MyMod/1.2
+
+ +

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

+ +ServerSignature + + + +SetHandler +Hace que todos los ficheros que correspondan con el valor +especificado sean procesados obligatoriamente por un +handler +SetHandler handler-name|None +server configvirtual host +directory.htaccess + +FileInfo +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.

+ + +AddHandler + + + + +SetInputFilter +Especifica los filtros que procesarán las peticiones de +los clientes y el contenido de peticiones POST +SetInputFilter filter[;filter...] +server configvirtual host +directory.htaccess + +FileInfo + + +

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.

+ +Documentación sobre Filtros + + + +SetOutputFilter +Especifica los filtros que procesarán las respuestas del +servidor +SetOutputFilter filter[;filter...] +server configvirtual host +directory.htaccess + +FileInfo + + +

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.

+ +Documentación sobre Filtros + + + +TimeOut +Cantidad de tiempo que el servidor esperará para que +ocurran determinados eventos antes de cerrar una +petición +TimeOut seconds +TimeOut 300 +server config + + +

La directiva TimeOut define ahora la + cantidad de tiempo que Apache esperará para tres cosas:

+ +
    +
  1. La cantidad de tiempo que tarda en recibir una + petición GET.
    2. + +
  2. La cantidad de tiempo entre la recepción de paquetes TCP + packets en una petición POST o PUT.
    3. + +
  3. La cantidad de tiempo entre ACKs en transmisiones de + paquetes TCP en las respuestas.
    4. +
+ +

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.

+ + + + +UseCanonicalName +Configura la forma en que el servidor determina su propio +nombre u puerto +UseCanonicalName On|Off|DNS +UseCanonicalName On +server configvirtual host +directory + + +

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.

+ + Advertencia + +

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.

+ + +ServerName +Listen + + + +VirtualHost +Contiene las directivas que se aplican solo a un nombre +de host específico o dirección IP +<VirtualHost + addr[:port] [addr[:port]] + ...> ... </VirtualHost> +server config + + +

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:

+ +
    +
  • La dirección IP del host virtual;
    • + +
  • Un nombre de dominio completo para la dirección IP del host + virtual;
    • + +
  • El carácter *, el cual puede usarse en + combinación con NameVirtualHost * para que + equivalga a todas las direcciones IP; o
    • + +
  • La cadena de caracteres _default_, que se usa + solo con hosting virtual IP para detectar direcciones IP sin + emparejar.
    • +
+ + Ejemplo + <VirtualHost 10.1.2.3>
+ + ServerAdmin webmaster@host.foo.com
+ 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 [fe80::a00:20ff:fea7:ccea]>
+ + ServerAdmin webmaster@host.example.com
+ 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).

+ + Nota

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

+ + Seguridad +

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.

+ + +Documentación sobre hosting virtual +Problemas relacionados con DNS y Apache +Especificar las direcciones y puertos que usa Apache +Cómo funcionan las secciones + <Directory>, <Location> y <Files> si quiere + una explicación completa de como se combinan esas secciones cuando + se recibe una petición + + +