From: Astrid Malo Date: Tue, 18 May 2004 11:14:59 +0000 (+0000) Subject: new translation X-Git-Tag: 2.0.50~101 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3ac14ca4130a6d8d9fb9b3b80bf9c042c8298539;p=thirdparty%2Fapache%2Fhttpd.git new translation Committed by: Jesus Blanco Reviewed by: Daniel Lopez git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/APACHE_2_0_BRANCH@103693 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/leader.xml.es b/docs/manual/mod/leader.xml.es new file mode 100644 index 00000000000..4c8a27cd4b8 --- /dev/null +++ b/docs/manual/mod/leader.xml.es @@ -0,0 +1,105 @@ + + + + + + + + +leader +Variante experimental del MPM estándar +worker +MPM +leader.c +mpm_leader_module + + + Warning +

Este módulo es todavía experimental, lo que + significa que podría no funcionar como es debido.

+ + +

Este módulo es una variante experimental del módulo + de multiprocesamiento estándar worker. Usa + un patrón de diseño Leader/Followers para coordinar el + trabajo entre las hebras. Para más información, consulte + http://deuce.doc.wustl.edu/doc/pspdfs/lf.pdf.

+ +

Para usar el MPM leader, añada + --with-mpm=leader como argumento al script + configure en el momento de compilar + httpd.

+ +

Este módulo de multiprocesamiento depende de operaciones + atómicas compare-and-swap del APR para sicronizar las + hebras. Si está compilando el servidor para una máquina + x86 y no necesita soportar la arquitectura 386, o está + compilando para una máquina SPARC y no necesita ejecutar el + servidor en chips pre-UltraSPARC, añada + --enable-nonportable-atomics=yes como argumento al + script configure. Esto hará que APR implemente + las operaciones atómicas usando opciones más eficientes + que no están presentes en CPUs antiguas.

+ + +AcceptMutex + +CoreDumpDirectory + +EnableExceptionHook + +Group + +Listen + +ListenBacklog + +SendBufferSize + +LockFile + +MaxClients + +MaxMemFree + +MaxRequestsPerChild + +MaxSpareThreads + +MinSpareThreads + +PidFile + +ScoreBoardFile + +ServerLimit + +StartServers + +ThreadLimit + +ThreadsPerChild + +User + + + + + + + diff --git a/docs/manual/mod/prefork.xml.es b/docs/manual/mod/prefork.xml.es new file mode 100644 index 00000000000..d16cfaa76a2 --- /dev/null +++ b/docs/manual/mod/prefork.xml.es @@ -0,0 +1,190 @@ + + + + + + + + + +prefork +Implementa un servidor web pre-forking y no +hebrado +MPM +prefork.c +mpm_prefork_module + + +

Este Módulo de MultiProcesamiento (MPM) implementa un + servidor web pre-forking y no hebrado que trata las peticiones de + una manera similar a como lo hacía Apache 1.3. Esto es + apropiado para sitios web que necesitan evitar el hebrado para ser + compatibles con librerías que no son seguras cuado se usan + hebras. Es también el mejor MPM para aislar cada + petición, de manera que si suge un problema con una + petición, esto no afecte al resto.

+ +

Este MPM está muy autorregulado, de manera que muy pocas + veces es necesario ajustar los valores de sus directivas de + configuración. El valor que se fije en la directiva + MaxClients debe ser lo + suficientemente grande para tratar tantas peticiones + simultáneas como espere recibir su sitio web, pero lo + suficientemente pequeño para asegurarse de que hay memoria + RAM suficiente para todos los procesos.

+ +Especificar las direcciones y los puertos +que usa Apache + +
Cómo funciona

Un + solo proceso de control es el responsable de lanzar los procesos + hijo que escuchan las peticiones que se puedan producir y las + sirven cuando llegan. Apache siempre intenta mantener varios + procesos de sobra o en espera, que estén + disponibles para servir peticiones cuando lleguen. Así, los + clientes no tienen que esperar a que un nuevo proceso hijo sea + creado para ser atendidos.

+ +

Las directivas StartServers, MinSpareServers, MaxSpareServers, y MaxClients regulan la forma en que + el proceso padre crea hijos para servir peticiones. En general, + Apache funciona bien sin hacer muchas modificaciones en los + valores por defecto de estas directivas, de manera que la mayor + parte de los sitios web no necesitan ajustar esas directivas a + valores diferentes. Los sitios web que necesiten servir más + de 256 peticiones simultáneas pueden necesitar incrementar el + valor de MaxClients, + mientras que los sitios web con memoria limitada pueden necesitar + decrementar MaxClients + para evitar que el rendimiento del servidor se degrade (pasando + los contenidos de memoria al disco y de vuelta a memoria). Puede + obtener más información sobre como mejorar el + rendimiento del proceso de creación de procesos en la + documentación sobre mejora + del rendimiento.

+ +

El proceso padre de Apache se inicia normalmente como usuario + root en Unix para que escuche en el puerto 80, sin + embargo, los procesos hijo se crean con menores privilegios de + usuario. Las directivas User y Group se usan para determinar los + privilegios de los procesos hijo de Apache. Los procesos hijo + deben ser capaces de leer todos los contenidos que van a servir, + pero deben tener los menores privilegios posibles.

+ +

La directiva MaxRequestsPerChild controla + cómo el servidor recicla frecuentemente los procesos + eliminando los antiguos y creando nuevos.

+
+ +BS2000Account + +CoreDumpDirectory + +EnableExceptionHook + +PidFile + +Listen + +ListenBacklog + +LockFile + +MaxClients + +MaxMemFree + +MaxRequestsPerChild + +ScoreBoardFile + +SendBufferSize + +ServerLimit + +StartServers + +User + +Group + +AcceptMutex + + + +MaxSpareServers +Número máximo de procesos hijo en espera que +puede tener el servdor +MaxSpareServers number +MaxSpareServers 10 +server config + + +

La directiva MaxSpareServers determina + el número máximo de procesos hijo en espera + deseado. Un proceso en espera es aquel que no está atendiendo + ninguna petición. Si hay más de + MaxSpareServers procesos hijo en espera, + entonces el proceso padre elimina el exceso.

+ +

Ajustar este parámetro debe ser necesario solo en sitios + web con muchas visitas. Fijar un valor alto para este + parámetro es una mala idea casi siempre. Si fija un valor por + debajo de MinSpareServers, + Apache ajustará automáticamente el valor a MinSpareServers + 1.

+ +MinSpareServers +StartServers + + + +MinSpareServers +Número mínimo de procesos hijo en espera +MinSpareServers number +MinSpareServers 5 +server config + + +

La directiva MinSpareServers fija el + número mínimo de procesos hijo en espera. Un + proceso en espera es aquel que no está atendiendo ninguna + petición. Si hay menos procesos hijo en espera que + MinSpareServers, entonces el proceso padre + crea nuevos procesos hijo a un ritmo máximo de uno por + segundo.

+ +

Ajustar este parámetro debe ser necesario solo en sitios + web con muchas visitas. Fijar un valor alto para este + parámetro es una mala idea casi siempre.

+ +MaxSpareServers +StartServers + + + + + + + + diff --git a/docs/manual/mod/worker.xml.es b/docs/manual/mod/worker.xml.es new file mode 100644 index 00000000000..9622e9c7141 --- /dev/null +++ b/docs/manual/mod/worker.xml.es @@ -0,0 +1,202 @@ + + + + + + + + +worker +Módulo de MultiProcesamiento que implementa un +servidor web híbrido multihebra-multiproceso +MPM +worker.c +mpm_worker_module + + +

Este Módulo de MultiProcesamiento (MPM) implementa un + servidor híbrido multiproceso-multihebra. Usando hebras para + atender peticiones, el servidor puede servir un mayor número + de peticiones con menos recursos de sistema que un servidor basado + únicamente en procesos. No obtante, se mantiene casi por + completo la estabilidad de un servidor basado en procesos + manteniendo la capacidad multiproceso, pudiendo cada proceso tener + muchas hebras.

+ +

Las directivas más importantes que se usan para controlar + este MPM son ThreadsPerChild, que controla el + número de hebras que tiene cada proceso hijo y MaxClients, que controla el + número máximo de hebras que pueden crearse.

+ +Especificar las direcciones y los +puertos que usa Apache + +
Cómo funciona

Un + solo proceso de control (el padre) es el responsable de crear los + procesos hijo. Cada proceso hijo crea un número fijo de + hebras del servidor de la forma que se especifica en la directiva + ThreadsPerChild, + así como una hebra de escucha que escuchará si se + producen peticiones y las pasará a una hebra del servidor + para que la procese.

+ +

Apache siempre intenta mantener en reserva cierto número + de hebras de sobra o en espera, que están + preparadas para servir peticiones en el momento en que + lleguen. Así, los clientes no tienen que esperar a que se + creen nuevas hebras o procesos para que sean atendidas sus + peticiones. El número de procesos que se crean al principio + está determinado por la directiva StartServers. Después durante + el funcionamiento del servidor, Apache calcula el número + total de hebras en espera entre todos los procesos, y crea o + elimina procesos para mantener ese número dentro de los + límites especificados en las directivas MinSpareThreads y MaxSpareThreads. Como este proceso + está bastante autorregulado, no es muy habitual que sea + necesario modificar los valores que estas directivas traen por + defecto. El número máximo de clientes que pueden ser + servidos simultáneamente (por ejemplo, el número + máximo de hebras entre todos los procesos) está + determinado por la directiva MaxClients. El número + máximo de procesos hijo activos está determinado por el + valor especificado en la directiva MaxClients dividido por el valor + especificado en la directiva + ThreadsPerChild.

+ +

Hay dos directivas que establecen límites estrictos al + número de procesos hijo activos y al número de hebras + del servidor en un proceso hijo, y puede cambiarse solo parando + completamente el servidor y volviendo a iniciarlo. La directiva + ServerLimit marca el + límite estricto de procesos hijo activos posibles, y debe ser + mayor o igual al valor de la directiva MaxClients dividido por el valor + de la directiva + ThreadsPerChild. El valor de la directiva ThreadLimit es el límite + estricto del número de hebras del servidor, y debe ser mayor + o igual al valor de la directiva ThreadsPerChild. Si los valores + de esas directivas no son los que vienen por defecto, deben + aparecer antes que el resto de directivas del módulo + worker.

+ +

Además del conjunto de procesos hijo activos, puede haber + otros procesos hijo que están terminando pero en los que al + menos una hebra del servidor está todavía tratando una + conexión con un cliente. Puede haber hasta MaxClients procesos terminando, + aunque el número real de estos procesos que puede esperarse + es mucho menor. Este comportamiento puede evitarse desactivando la + eliminación individual de procesos hijo, lo que se hace de la + siguiente manera:

+ +
    +
  • fijar el valor de la directiva + MaxRequestsPerChild a cero
    • + +
  • fijar el valor de la directiva MaxSpareThreads al mismo valor + que la directiva MaxClients
    • +
+ +

Una configuración típica del sistema de control de + procesos y hebras del módulo de MPM worker + prodría ser como sigue:

+ + + ServerLimit 16
+ StartServers 2
+ MaxClients 150
+ MinSpareThreads 25
+ MaxSpareThreads 75
+ ThreadsPerChild 25 + + +

Mientras que el proceso padre se inicia con privilegios de + usuario root en Unix para usar el puerto de escucha + 80, los procesos hijo y las hebras se inician con menores + privilegios de usuario. Las directivas User y Group se usan para determinar los + privilegios con los que se iniciarán los procesos hijo. Los + procesos hijo deben ser capaces de leer los contenidos que van a + servir, pero solo los permisos extrictamente necesarios para + cumplir su tarea. Además. a menos que se use suexec, los privilegios fijados en estas + directivas son los que que van a heredar los scripts CGI.

+ +

La directiva MaxRequestsPerChild controla con + qué frecuencia el servidor recicla los procesos eliminando + los antiguos y creando nuevos.

+
+ +AcceptMutex + +CoreDumpDirectory + +EnableExceptionHook + +Group + +PidFile + +Listen + +ListenBacklog + +LockFile + +MaxClients + +MaxMemFree + +MaxRequestsPerChild + +MaxSpareThreads + +MinSpareThreads + +ScoreBoardFile + +SendBufferSize + +ServerLimit + +StartServers + +ThreadLimit + +ThreadsPerChild + +User + + + + + + + + diff --git a/docs/manual/new_features_2_0.xml.es b/docs/manual/new_features_2_0.xml.es new file mode 100644 index 00000000000..de5e3a4d1c1 --- /dev/null +++ b/docs/manual/new_features_2_0.xml.es @@ -0,0 +1,268 @@ + + + + + + + + + +Visión general de las nuevas funcionalidades de Apache +2.0 + + +

Este documento describe algunas de las diferencias más + importantes que existen entre las versiones 1.3 y 2.0 del Servidor + HTTP Apache.

+ + +Migrar su instalación de la +versión 1.3 a la 2.0 + +
+ Principales Mejoras + +
+
Hebrado en Unix
+ +
En los sistemas Unix que soportan hebras POSIX, la nueva + versión de Apache puede ejecutarse en modo híbrido + multiproceso-multihebra. Esto mejora la escalabilidad para + muchas aunque no para todas las configuraciones.
+ +
Nuevo sistema de configuración y compilación
+ +
El sistema de configuración y compilación ha sido + escrito de nuevo desde cero para basarlo en + autoconf y libtool. Esto hace que el + sistema de configuración de Apache se parezca ahora + más al de otros proyectos Open Source.
+ +
Soporte Multiprotocolo
+ +
La nueva versión tiene la infraestructura necesaria + para servir distintos protocolos. Por ejemplo, se ha escrito el + módulo mod_echo.
+ +
Soporte mejorado para las plataformas que no son tipo Unix
+ +
La versión 2.0 de Apache es más rápida y + más estable en sistemas que no son tipo Unix, tales como + BeOS, OS/2 y Windows, que la versión antigua. Con la + introducción de módulos de + multiprocesamiento (MPMs) específicos para cada + plataforma y del Apache Portable Runtime (APR), estas + plataformas tienen ahora implementada su propia API nativa, + evitando las capas de emulación POSIX que provocan + problemas y un bajo rendimiento.
+ +
Nueva interfaz de programación (API) de Apache
+ +
La API para los módulos ha cambiado significativamente + en la nueva versión. Muchos de los problemas de + ordención y prioridad de módulos de la versión + 1.3 deben haber desaparecido. Apache 2.0 hace automaticamente + mucho de lo que es necesario, y la ordenación de + módulos se hace ahora por hooks, lo que ofrece una mayor + flexibilidad. También se han añadido nuevas llamadas + que ofrecen capacidades adicionales sin tener que parchear el + núcleo del servidor Apache.
+ +
Soporte de IPv6
+ +
En los sitemas que soportan IPv6 con la libreria Apache + Portable Runtime, Apache soporta IPv6 listening sockets por + defecto. Además, las directivas Listen, NameVirtualHost, y VirtualHost soportan direcciones IPv6 + numéricas (por ejemplo, "Listen + [fe80::1]:8080").
+ +
Filtros
+ +
Los módulos de Apache pueden ahora escribirse para que + se comporten como filtros que actúan sobre el flujo de + contenidos tal y como salen del servidor o tal y como son + recibidos por el servidor. Esto permite, por ejemplo, que el + resultado de un script CGI sea analizado por las directivas + Server Side Include usando el filtro INCLUDES del + módulo mod_include. El módulo + mod_ext_filter permite que programas externos + actúen como filtros casi del mismo modo que los CGIs pueden + actuar como handlers.
+ +
Mensajes de error en diferentes idiomas
+ +
Los mensajes de error que se envían a los navegadores + están ahora disponibles en diferentes idiomas, usando + documentos SSI. Estos mensajes pueden personalizarse por el + administrador del sitio web para conseguir un look and feel + coherente con el resto de los contenidos.
+ +
Configuración simplificada
+ +
Muchas directivas que podían inducir a confusión + han sido simplificadas. Las directivas Port y + BindAddress han desaparecido; para configurar la + dirección IP en la que escucha el servidor ahora se usa + únicamente la directiva Listen; la directiva ServerName especifica el nombre del + servidor y el número del puerto solo para redirecionamiento + y reconocimento de host virtual.
+ +
Soporte de Unicode Nativo para Windows NT
+ +
Apache 2.0 en Windows NT usa ahora utf-8 para la + codificación de los nombres de fichero. Estos se mapean + directamente al sistema de ficheros Unicode subyanciente, + suministrando soporte para diferentes idiomas para todas + instalaciones en Windows NT, includidos Windows 2000 y Windows + XP. Este soporte no se extiende a Windows 95, 98 o ME, que + continúan usando la codificación que tenga la + máquina local para el acceso al sistema de + archivos.
+ +
Actulización de la librería de expresiones + regulares (regular expressions)
+ +
Apache 2.0 incluye la Librería de expresiones + regulares compatibles de/con Perl (PCRE). Ahora, cuando se + evalúan las expresiones tipo, se usa siempre la potente + sintaxis de Perl 5.
+ +
+
+ +
+ Mejoras en los módulos + +
+
mod_ssl
+ +
Módulo nuevo en Apache 2.0. Este módulo es una + interfaz para los protocolos de encriptado SSL/TLS de + OpenSSL.
+ +
mod_dav
+ +
Módulo nuevo en Apache 2.0. Este módulo implementa + la especificación del HTTP Distributed Authoring and + Versioning (DAV) para colgar y mantener contenidos web.
+ +
mod_deflate
+ +
Módulo nuevo en Apache 2.0. Este módulo permite + soportar nevagadores que requieren que el contenido sea + comprimido antes de ser servido, ahorrando ancho de banda.
+ +
mod_auth_ldap
+ +
Módulo nuevo en Apache 2.0.41. Este módulo permite + que se pueda usar una base de datos LDAP para almacenar las + credenciales en la autentificación básica HTTP. El + módulo de acompañamiento, mod_ldap + ofrece connection pooling y cache de resultados.
+ +
mod_auth_digest
+ +
Incluye soporte adicional para cache de sesiones entre + procesos usando memoria compartida.
+ +
mod_charset_lite
+ +
Módulo nuevo en Apache 2.0. Este módulo + experimental permite for traducción o recodificación + de sets de caracteres.
+ +
mod_file_cache
+ +
Módulo nuevo en Apache 2.0. Este módulo incluye la + funcionalidad que mod_mmap_static tenía en + Apache 1.3, e incorpora nuevas capacidades de cacheado.
+ +
mod_headers
+ +
Este módulo es mucho más flexible en Apache + 2.0. Ahora puede modificar las cabeceras de las peticiones + usadas por mod_proxy, y puede fijar + condicionalmente cabeceras de respuesta.
+ +
mod_proxy
+ +
El módulo proxy ha sido completamente reescrito para + aprovechar la nueva infraestructura de filtros y para + implementar de una manera más fiable un proxy que cumpla + con requerimientos de la especificación + HTTTP/1.1. Además, se han incorporado nuevas secciones de + configuración a la directiva Proxy que hacen mas fácil (e + internamente más rápido) el control de los sitios web + que usan proxys; las configuraciones de sobrecarga + <Directory "proxy:..."> no se soportan. El + módulo está ahora dividido en módulos + específicos para cada protocolo, incluidos + proxy_connect, proxy_ftp y + proxy_http.
+ +
mod_negotiation
+ +
La nueva directiva ForceLanguagePriority se puede usar para asegurarse + de que el cliente recibe siempre solo un documento, en lugar de + obtener una respuesta de tipo NOT ACCEPTABLE o MULTIPLE + CHOICES. Además, los algoritmos de negociación y + MultiView han sido modificados para ofrecer resultados más + consistentes y se ha incluido a nuevo tipo de correspondecia de + tipos (type map).
+ +
mod_autoindex
+ +
Ahora pueden configurarse listados de directorios + autoindexados para usar tablas HTML, darles formato de forma + más sencilla, y permitir control detallado del + ordenamiento, incluidos ordenamiento por versión, y + filtrado usando caracteres comodines de los listados de + directorios.
+ +
mod_include
+ +
Estas nuevas directivas permiten cambiar las etiquetas por + defecto de comienzo y final para elementos SSI y permiten que la + configuración de errores y el formato de la hora y la fecha + se hagan en el fichero de configuración pricipal en lugar + de en el documento SSI. Los resultados del análisis y la + agrupación de las expresiones tipo (ahora basadas en la + sintaxis de Perl 5) pueden ser devueltos usando las variables + $0 .. $9 del módulo + mod_include.
+ +
mod_auth_dbm
+ +
Ahora se soportan varias clases de bases de datos de tipo + DBM usando la directiva AuthDBMType.
+ +
+
+ + + + + diff --git a/docs/manual/upgrading.xml.es b/docs/manual/upgrading.xml.es new file mode 100644 index 00000000000..a3e9af54769 --- /dev/null +++ b/docs/manual/upgrading.xml.es @@ -0,0 +1,225 @@ + + + + + + + + + +Migrar su instalación de la versión 1.3 a la +2.0 + + +

Este documento recoge infomación crítica sobre el + proceso de actulización de la versión de Apache que + usa. Se trata de pequeños comentarios. Puede encontrar más + información tanto en Nuevas + funcionalidades, como en el archivo + src/CHANGES.

+ +Visión general de las +nuevas funcionalidades de Apache 2.0 + +
+ Cambios en el proceso de configuración y + compilación + +
    +
  • Apache usa ahora autoconf y + libtool en el proceso de + compilación. Este sistema es parecido aunque no igual + al sistema APACI de Apache 1.3.
    • + +
  • Además de la selección de módulos habitual + que puede hacer al compilar, en Apache 2.0 la mayor parte del + procesamiento de las petición es llevada a cabo por los Módulos de MultiProcesamiento + (MPMs).
    • +
+
+ +
+ Cambios en el proceso de la configuración inicial del + servidor + +
    +
  • Muchas directivas que no pertenicían al conjunto + básico en Apache 1.3 están ahora en los MPMs. Si desea + que el nuevo servidor de comporte de la forma más parecida + posible a Apache 1.3, debe seleccionar el Módulo de + MultiProcesamiento prefork. Otros MPMs tienen + diferentes directivas para controlar el proceso de creación + y procesamiento de peticiones.
    • + +
  • El módulo proxy ha + sido remodelado para ponerlo al día con la + especificación HTTP/1.1. Entre los cambios más + importantes está el que ahora el control de acceso al proxy + está dentro de un bloque Proxy en lugar de en un bloque + <Directory proxy:>.
    • + +
  • El procesamiento dePATH_INFO (la informacion de + path que aparece tras un nombre de fichero válido) ha + cambiado para algunos módulos. Módulos que fueron + previamente implementados como un handle pero ahora son + implementados como filtros puede que no acepten ahora peticiones + que incluyan PATH_INFO. Filtros como INCLUDES o PHP están implementados + encima del handler principal (core handler) core handler, y por + tanto rechazan peticiones con PATH_INFO. Puede usar + la directiva AcceptPathInfo + para forzar al handler principal a aceptar peticiones con + PATH_INFO y por tanto restaurar la habilidad de + usar PATH_INFO en server-side includes.
    • + +
  • La directiva CacheNegotiatedDocs toma + ahora como argumento on u off. Las + instacias existentes de CacheNegotiatedDocs deben reemplazarse por + CacheNegotiatedDocs on.
    • + +
  • + La directiva ErrorDocument no usa ya dobles + comillas al principio del argumento para indicar el mensaje de + texto que tiene que mostrarse. En lugar de esto, se debe poner + entre comillas todo el mensaje. Por ejemplo, + + + ErrorDocument 403 "Mensaje + + debe sustituirse por + + + ErrorDocument 403 "Mensaje" + + + Si el segundo argumento no es una URL o una ruta válida a + un archivo, será tratado como un mensaje de texto. +
    • + +
  • Las directivas AccessConfig y + ResourceConfig han desaparecido. Las instancias + existentes de estas directivas pueden sustituirse por la + directiva Include que tiene + una funcionalidad equivalente. Si hacía uso de los valores + por defecto de esas directivas sin incluirlas en los ficheros de + configuración, puede que necesite añadir Include + conf/access.conf e Include conf/srm.conf a + su fichero httpd.conf. Para asegurarse de que + Apache lee el fichero de configuración en el mismo orden + que asumían las antiguas directivas, las directivas + Include deben ser + reemplazadas al final del fichero httpd.conf, con + la de srm.conf precediendo a la de + access.conf.
    • + +
  • Las directivas BindAddress y Port + no existen ya. Las funcionalidades que ofrecían esas + directivas están ahora cubiertas por la directiva + Listen, que es mucho + más flexible.
    • + +
  • Otro uso de la directiva Port en Apache 1.3 era + fijar el número de puerto que se usaba para URLs + autoreferenciadas. La directiva equivalente en Apache 2.0 es la + nueva directiva ServerName: + este cambio se ha introducido para permitir la + especificación del nombre de host y del + número de puerto para URLs autorreferenciadas en una sola + directiva.
    • + +
  • La directiva ServerType ha dejado de existir. + El método usado para servir peticiones está ahora + determinado por la selección del Módulo de + MultiProcesamiento. Actualmente no hay diseñado un MPM que + pueda ser ejecutado por inetd.
    • + +
  • Los módulos mod_log_agent y + mod_log_referer que contenían las directivas + AgentLog, RefererLog y + RefererIgnore han desaparecido. Los logs de agente + y de referer están disponibles todavía usando la + directiva CustomLog del módulo + mod_log_config.
    • + +
  • las directivas AddModule y + ClearModuleList no están presentes en la nueva + versión. Estan directivas se usaban para asegurarse de que + los módulos pudieran activarse en el orden correcto. La + nueva API de Apache 2.0 permite a los módulos especificar + explícitamente su orden de activación, eliminando la + necesidad de estas directivas.
    • + +
  • La directiva FancyIndexing se ha eliminado. La + funcionalidad que cubría está ahora disponible a + través de la opción FancyIndexing de la + directiva IndexOptions.
    • + +
  • La técnica de negociación de contenido MultiViews + ofrecida por mod_negotiation es ahora más + estricta en su algoritmo de selección de ficheros y solo + seleccionará ficheros negociables. El antiguo + comportamiento puede restaurarse usando la directiva MultiviewsMatch.
    • + +
+
+ +
+ Cambios de menor importancia + +
    +
  • El módulo mod_auth_digest, que era + experimental en Apache 1.3, es ahora un módulo + estándar.
    • + +
  • El módulo mod_mmap_static, que era + experimental en Apache 1.3, ha sido sustituido por el + módulo mod_file_cache.
    • + +
  • La distribución de Apache ha sido reorganizada por + completo para que no contenga a partir de ahora el directorio + independiente src. En su lugar, el código + fuente se ha organizado a partir del directorio principal de la + distribución, y las intalaciones del servidor compilado + deben hecerse en un directorio diferente.
    • +
+
+ +
+ Módulos de terceras partes + +

La API de Apache 2.0 ha sufrido grandes cambios respecto a la + versión 1.3. Los módulos que se diseñaron para la + API de Apache 1.3 no funcionarán si no se + hacen las modificaciones necasarias para adaptarlos a Apache 2.0. + En la documentación para + desarrolladores puede encontrar información detallada + sobre este asunto.

+
+ + + + +