Memoria del proyecto fin de carrera:

Integración de tecnologías a través de servidores Web

José Manuel López Franco

txapi@ei.uvigo.es

3 de septiembre de 2001
 A mi padre y
a mi novia Isabel
Prefacio

Ha pasado mucho tiempo “informáticamente hablando” desde los primeros servidores Web que
simplemente servían páginas bajo el protocolo HTTP, estos eran programas que no necesitaban
de un conocimiento demasiado avanzado ni para su instalación ni para su mantenimiento. Hoy
por hoy, la evolución es patente, siendo innumerables tanto los servidores Web disponibles en el
mercado como los servicios de alto nivel que se ofrecen en torno a ellos; esta evolución hace que
las tareas de configuración y mantenimiento de un servidor Web no sean triviales.

En este proyecto y ante la actual explosión tanto de Internet como de la World Wide Web, se
pretende hacer un análisis, desde el punto de vista de un administrador o Webmaster, de las
tecnologías asociadas al protocolo HTTP (servidores Web) y aplicar las mismas de forma práctica
instalando y configurando adecuadamente un servidor.

Objetivos básicos

A modo de resumen se puede decir que los objetivos básicos son dos:

1. Realizar un estudio teórico de las tecnologías más relevantes que se pueden usar en un
servidor Web.

2. Instalar y configurar un servidor Web sobre el que corran aplicaciones reales de ejemplo de
las tecnologías abordadas en la parte teórica.

Organización de esta memoria

Debido al carácter predominantemente teórico del proyecto, se ha optado por una organización de
la memoria que no se adecua al formato estándar indicado en el reglamento de proyectos fin de
carrera. Concretamente se ha dividido este documento en cuatro grandes partes:

1. Conceptos teóricos: El Web, servidores y tecnologías asociadas.

2. Aplicación práctica 1: Configuración de un servidor Web Apache.

i
ii

3. Aplicación práctica 2: Desplegando soluciones reales basadas en Web.

4. Conclusión y trabajos futuros.

5. Apéndices.

Conceptos teóricos: El Web, servidores y tecnologías asociadas

En esta primera parte se abordarán conceptos puramente teóricos sobre:

Servidores Web y de aplicaciones, con información sobre el estado del arte y una breve
descripción de los que se consideran más interesantes.

Fundamentos de la Word Wide Web (HTTP, etc.)

Otras tecnologías asociadas y de gran implantación en la actualidad (CGI, ASP, PHP, etc.).

La organización en capítulos es la siguiente:

Capítulo 1. Panorámica actual: donde se hace una introducción al WWW, y se comenta el

estado del arte en el campo de los servidores Web y de aplicaciones.

Capítulo 2. El protocolo HTTP: que trata los conceptos básicos del protocolo que subyace en
todas las implementaciones de servidores Web.

Capítulo 3. Ejecución de programas externos: donde se explican algunas de las tecnologías

que permiten extender la funcionalidad de los servidores Web mediante la ejecución de
programas externos (CGI,Servlets, etc.).

Capítulo 4. Código embebido en HTML: presentación teórica de algunos lenguajes que

permiten embeber código dentro de las páginas HTML (ASP, JSP, etc.).

Capítulo 5. HTTP seguro: un vistazo general a las técnicas que se pueden utilizar para asegurar
la transferencia de datos sobre HTTP (HTTP + SSL y S-HTTP).

Capítulo 6. Relación entre Web y XML: este capítulo trata los conceptos básicos de XML y de
algunas de sus aplicaciones más importantes a la World Wide Web (XHTML y SOAP).

Capítulo 7. Gestión de recursos remotos: presenta dos soluciones para proporcionar la gestión
de recursos remotos, FrontPage y WebDAV. Se hará hincapié en WebDAV, ya que es un
estándar del W3C e incluso Microsoft le está dando su apoyo.

Capítulo 8. Bases de datos y búsqueda en la Web: proporciona una visión general de algunos
de los sistemas gestores de bases de datos más utilizados. También se presentan algunas de
las tecnologías que permiten a una aplicación Web conectarse a BBDDs. Además se incluye
una sección donde se describen los aspectos teóricos de un buscador, una de las aplicaciones
Web que hace un uso más intensivo de los sistemas de bases de datos.
 iii

Capítulo 9. Registro de actividad, log o bitácora: introduce los métodos más utilizados para el
registro de actividad en un servidor Web (archivos de log, cookies, etc.). Además se
comentan de manera genérica varias herramientas relacionadas (analizadores y rotadores
de log).

Aplicación práctica 1: Configuración de un servidor Web Apache

En esta segunda parte se documenta el trabajo práctico necesario para instalar y configurar un
servidor Web Apache con sus extensiones más habituales1 sobre una plataforma Linux/Unix.

La organización en capítulos es la siguiente:

Capítulo 10. Instalando Apache para Linux/Unix: presenta los pasos a seguir para efectuar la
instalación básica de Apache.

Capítulo 11. Configuración básica del servidor: se muestran cuales son los ficheros, directivas
y módulos utilizados en una configuración básica de Apache. Además se comentan aspectos
de seguridad relacionados y algunas herramientas típicas de chequeo de la configuración.

Capítulo 12. Servidores virtuales: explica como simular más de un equipo servidor cuando en
realidad se dispone de una sola máquina con Apache.

Capítulo 13. Configurando SSI y CGI: SSI y CGI son las dos tecnologías de generación de
contenido dinámico más antiguas, ambas se incluyen en las distribuciones de Apache. En
este capítulo se discute como se instalan y configuran adecuadamente.

Capítulo 14. Servlets y Jsp con Tomcat. Integración con Apache: Tomcat es un contenedor
Servlet muy extendido en el mercado, su instalación, configuración y métodos de
integración con Apache son el objetivo de este capítulo.

Capítulo 15. Configurando PHP: donde se explica como instalar y configurar PHP, un conocido
lenguaje embebido en HTML, sobre un servidor Web Apache.

Capítulo 16. Autenticación, autorización y control de acceso: está dedicado a como proteger
partes de un sitio Web, abordando los métodos de autenticación definidos en la
especificación HTTP (Basic y Digest), su posible uso combinado con el control de acceso
basado en IPs o nombres de equipos, y algunas técnicas relacionadas.

Capítulo 17. Habilitando la gestión remota de recursos con WebDAV: o como habilitar las
capacidades de gestión de recursos remotos que proporciona el módulo de Apache mod_dav.
1 Remarcar que se instalan las extensiones más habituales, esto quiere decir, que son todas las que están pero no están

todas las que son. Más concretamente, todas las características instaladas en Apache son comentadas como conceptos
en la parte teórica, pero no todos estos conceptos teóricos han sido instalados en Apache.
iv

Capítulo 18. Configurar conexiones seguras en Apache sobre SSL: se discute como utilizar el
módulo de Apache mod_ssl para conseguir un servidor Web capaz de recibir peticiones y
transferir datos de manera “segura”2 sobre el protocolo SSL.

Capítulo 19. Personalizar el registro y recopilar estadísticas: existen varios métodos que un
servidor Web Apache puede utilizar para registrar (log) sus operaciones. En este capítulo se
explica como configurar adecuadamente el servicio de log y como personalizarlo según las
necesidades particulares.

Capítulo 20. Otros módulos y tecnologías relacionadas: presenta algunas otras tecnologías
relacionadas con Apache (proxy-caché, redundancia, reescritura, etc.), que aún siendo
importantes no han tenido cabida en los capítulos anteriores.

Aplicación práctica 2: Desplegando soluciones reales basadas en Web

En esta parte se supone un caso práctico (el servidor Web de una Escuela de Informática) donde
el lector es el administrador Web. Sobre este ejemplo, y en lenguaje coloquial, se describe
una posible evolución temporal. En cada capítulo se plantean nuevos problemas a los que el
administrador deberá responder:

1. Analizando las nuevas necesidades.

2. Instalando los programas necesarios.

3. Configurando Apache para su funcionamiento adecuado.

Los conocimientos teóricos sobre instalación y configuración comentados en las dos primeras
partes serán fundamentales en la resolución de este caso práctico.

Los capítulos incluidos son:

Capítulo 21. Primeros pasos: narra como el administrador se encuentra ante un equipo sin
servidor Web. Se conseguirá instalar un Apache, publicar la primera página y
posteriormente mejorar el sistema con servidores virtuales.

Capítulo 22. Zona de download de mantenimiento automático: presenta el problema que le

supone al encargado de los contenidos del sitio Web mantener actualizada la información
sobre los recursos disponibles en una pequeña área de descarga. Se plantean dos posibles
soluciones para que se actualice automáticamente.

Capítulo 23. Negociación de contenido para personalizar el idioma: la Web de la Escuela de

Informática tiene visitantes de todas las partes del mundo. ¿Cómo se puede configurarse el
sitio para que presente las páginas y los errores en el idioma adecuado?.
2 “Segura”, entre comillas, porque nada está completamente seguro en la red. En algunos capítulos de esta memoria,

se abusa del término seguridad, el lector debe entender que se refiere a seguridad relativa.
 v

Capítulo 24. Linkómetro. Ejecución de scripts CGI de usuario: un usuario necesita ejecutar
sus propios scripts CGI, ¿cómo hacerlo de forma segura?, vea este capítulo.

Capítulo 25. Macromedia Dreamweaver y WebDav. Gestión remota de sitios Web: donde el
administrador se enfrenta a la tarea de preparar un repositorio WebDAV sobre el que puedan
trabajar varios usuarios y que esté disponible mediante acceso restringido.

Capítulo 26. UDMSearch. Un buscador Web: si el espacio de páginas crece mucho, se puede
utilizar alguna herramienta que permita indexar y hacer búsquedas. En este capítulo se
comenta una de ellas.

Capítulo 27. Jive. Un sistema de foros basado en Servlets y JSP: hay muchos métodos de
crear foros en Internet, las clásicas News, listas de correo electrónico, etc, pero en los
últimos tiempos ha surgido algo más, los sistemas de foros basados en Web.

Capítulo 28. PhpMyAdmin. Gestión Web de bases de datos MySQL: el Webmaster también
tiene sus necesidades, por ejemplo, en este capítulo se ilustra como gestionar un SGBD
MySQL desde Web de manera “segura”.

Conclusión y trabajos futuros

Una parte, breve pero importante, donde se expone la conclusión final y algunas posibles líneas de
trabajo futuras relacionadas con el proyecto realizado.

Apéndices

Esta parte contiene explicaciones o listados un poco más en profundidad de ciertos conceptos que
se utilizan a lo largo de la memoria. Se opta por incluirlos como apéndices porque no tienen la
suficiente entidad y/o no están lo suficientemente relacionados con el tema del proyecto como para
ser objeto de un capítulo propio.

Los apéndices son:

Apéndice A. El lenguaje HTML: proporciona algunos conceptos sobre el lenguaje de creación

de documentos de hipertexto HTML. Esta tecnología está relacionada con muchos de los
temas tratados en el proyecto (la mayoría de las interfaces Web para programas CGI,
Servlets, ASP, etc, usan HTML), por eso se ha decidio incluir este apéndice.

Apéndice B. Dynamic Shared Objects en Apache: en muchos sitios de esta memoria aparece
el concepto DSO. Aunque en el capítulo 10 se hace una breve descripción del mismo, se
ha decidido incluir como apéndice una adaptación de la traducción hecha por el proyecto
ApacheES [21] del documento Soporte de Objetos Compartidos Dinámicos (Dynamic
Shared Object - DSO), cuyo original en inglés se distribuye con la documentación de
Apache.
vi

Apéndice C. Expresiones regulares: proporciona algunos apuntes sobre expresiones regulares,

una herramienta muy utilizada en algunos módulos de Apache.

Apéndice D. Configuración por defecto del servidor Apache: más de la mitad de la memoria
se ocupa de explicar temas de configuración de Apache, y generalmente se presentan trozos
de código. Incluir un archivo de configuración completo ayuda a ubicar cada trozo en su
sitio. Además está lleno de buenos comentarios (en inglés).

Líneas de lectura

Aunque para obtener una mejor visión global del tema tratado en este proyecto lo más
recomendable es leer la memoria completa y en orden, también pueden consultarse los capítulos
que se consideren más interesantes de forma independiente. Además existen algunas líneas de
lectura bastante claras, que relacionan capítulos, destacar:

Capítulos 1, 2: conceptos teóricos básicos.

Capítulos 10, 11, 20: instalación y configuración básica de un servidor Web Apache, visión
general de otras tecnologías relacionadas.

Capítulos 5, 16, 18, 28: conceptos teóricos sobre las tecnologías que aportan seguridad a las
transferencias de datos sobre Web. Métodos de instalación, configuración y ejemplo.

Capítulos 6, 7, 17, 25: conceptos teóricos sobre las tecnologías basadas en XML relacionadas
con la Web, gestión de recursos remotos con WebDAV. Instalación, configuración y ejemplo.

Capítulos 8, 26: teoría básica y métodos de instalación de las tecnologías de acceso a bases de
datos más usadas en Internet. Teoría y ejemplo de un buscador, uno de los servicios Web
que utilizan más ampliamente las BBDDs.

Capítulos 9, 19: teoría y métodos de instalación de las características de registro de información

(log) en un servidor Web Apache. Utilización de herramientas relacionadas para rotación y
análisis.

Capítulos 12, 21: teoría básica, métodos de instalación y un ejemplo real del uso de servidores
virtuales en Apache.

Capítulos 3, 4, 13, 14, 15, 22, 23, 24, 27: Conceptos teóricos sobre las tecnologías que permiten
programar de manera externa o mediante código embebido sobre la base de un servidor Web.
Métodos de instalación básica de un Apache con soporte a estas tecnologías y ejemplos de
utilización.
 vii

Localización de contenidos

Con la descripción de la organización de la memoria y las líneas de lectura propuestas en las

secciones anteriores, el lector puede hacerse una idea general del contenido de esta memoria. Pero
si lo que se desea es consultar algún aspecto en particular recomendamos utilizar alguno de los
índices (general, figuras, tablas, listados, materias o contenidos de capítulos).

CD-ROM

A esta memoria le acompaña un CD-ROM donde se ha incluido documentación (directorio

/docs) y software (directorio /software). Para una lista completa puede consultarse el fichero
README.txt dentro del directorio raíz del propio CD.

A modo de resumen, comentar que entre el software pueden encontrarse varios servidores Web,
módulos para Apache, drivers de bases de datos, etc, y dentro de la documentación aparece el
original de esta memoria junto con copias de algunas de las especificaciones más importantes a
las que se hace referencia en este proyecto (HTTP, WebDAV, etc.).

Agradecimientos

Siempre hay personas a las que agradecer su colaboración, no me gustaría dejarme a nadie, pero
si es así espero que me perdone:

Al director y codirector de este proyecto, David Cabrero Souto y Pedro Cuesta Morales, por
prestarme algo de su tiempo en el difícil mes de agosto.

A aquellos que me ayudaron a descubrir errores (ortografía, presentación, etc.).

A esos otros que una vez leída esta memoria encuentren errores pero sepan disculparme.

A los que me proporcionaron libros para paliar los problemas provocados por una
“biblioteca cerrada por obras hasta el 17 de septiembre del 2001”.

A los profesores que me introdujeron al mundo de la edición de textos con LATEX.

Y por supuesto, a todo esa “pandilla” de amigos que me apoyó en todo momento. Ellos
saben quienes son.

Por último quiero recordar a todo el grupo humano que forma la Escuela Superior de
Ingeniería Informática de Ourense (bedeles, encargados de cafetería, etc.).

A todos, gracias.
viii
Índice General

I Conceptos teóricos:
El Web, servidores y tecnologías asociadas 1

1 Panorámica actual 3

1.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Servidores Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Servidores de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Servicios añadidos de los servidores de aplicaciones . . . . . . . . . . . 7

1.3.2 Tecnologías para implementar servidores de aplicaciones . . . . . . . . . 8

1.4 Mediciones de mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Algunos ejemplos de servidores . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5.1 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5.2 BEA Weblogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.5.3 Enhydra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.5.4 Jigsaw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.5.5 Macromedia-Allaire ColdFusion . . . . . . . . . . . . . . . . . . . . . . 15

1.5.6 Microsoft IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.5.7 NCSA HTTPd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.5.8 Netscape-Sun iPlanet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.5.9 Zeus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.5.10 Tabla comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.6 Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

ix
x ÍNDICE GENERAL

2 El protocolo HTTP 19

2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1.2 Propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2 Comunicación HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.1 Formato de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.2 Peticiones (Request) HTTP, métodos de petición . . . . . . . . . . . . . 22

2.2.3 Respuestas (Response) HTTP, códigos de estado . . . . . . . . . . . . . 24

2.2.4 Líneas de encabezado HTTP . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.5 Tipos MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.6 Esquema de una comunicación . . . . . . . . . . . . . . . . . . . . . . . 29

2.3 Características avanzadas del protocolo . . . . . . . . . . . . . . . . . . . . . . 30

2.3.1 Negociación de contenido . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.2 Conexiones persistentes (Keep-Alive) . . . . . . . . . . . . . . . . . . . 31

2.3.3 Servidores virtuales (Virtual hosts) . . . . . . . . . . . . . . . . . . . . . 31

2.3.4 Autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.5 Proxy-caché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4 Mejoras del servicio ofrecido a través de HTTP . . . . . . . . . . . . . . . . . . 33

3 Ejecución de programas externos 35

3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 La especificación CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.2 Datos de entrada al programa CGI . . . . . . . . . . . . . . . . . . . . . 37

3.2.3 Proceso de los datos de entrada . . . . . . . . . . . . . . . . . . . . . . 39

3.2.4 Datos de salida del script CGI . . . . . . . . . . . . . . . . . . . . . . . 41

3.2.5 Un ejemplo de script muy simple . . . . . . . . . . . . . . . . . . . . . 42

3.3 Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.2 Esquema de ejecución de un Servlet . . . . . . . . . . . . . . . . . . . . 44

3.3.3 Resumen del API Java Servlet . . . . . . . . . . . . . . . . . . . . . . . 45

ÍNDICE GENERAL xi

3.3.4 Esquema general de un Servlet . . . . . . . . . . . . . . . . . . . . . . . 45

3.3.5 Un ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 Otras opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4 Código embebido en HTML 51

4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2 SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2.2 XSSI de Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.2.3 Hotwired XSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2.4 JSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2.5 Un ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3 JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3.2 El lenguaje JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3.3 Un ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.4 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.4.2 El lenguaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.4.3 Potencia de PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.4.4 Un ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.5 ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.5.2 Componentes ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.5.3 Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.5.4 Un ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.6 Otras posibilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.7 Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
xii ÍNDICE GENERAL

5 HTTP seguro 77

5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.2 HTTP + SSL = HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2.1 Introducción al protocolo SSL . . . . . . . . . . . . . . . . . . . . . . . 78

5.2.2 Características de SSL v3 . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.2.3 Cuestiones de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.2.4 Pasos del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.2.5 Implementaciones de SSL . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.2.6 HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.3 S-HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.3.2 El protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.3.3 Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6 Relación entre Web y XML 87

6.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.2 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.2.2 Características de XML . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.2.3 Definición de la estructura de un documento XML . . . . . . . . . . . . 89

6.2.4 La sintaxis de XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.2.5 Otras especificaciones y tecnologías desarrolladas en torno a XML . . . . 92

6.3 XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.3.2 Principales diferencias entre XHTML y HTML 4.X . . . . . . . . . . . . 94

6.3.3 Un ejemplo sencillo de XHTML . . . . . . . . . . . . . . . . . . . . . . 94

6.4 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4.2 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.4.3 Estructura de funcionamiento SOAP sobre HTTP . . . . . . . . . . . . . 97

6.5 Otras aplicaciones relacionados con XML y la Web . . . . . . . . . . . . . . . . 99

ÍNDICE GENERAL xiii

7 Gestión de recursos remotos 101

7.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.2 FrontPage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.3 WebDav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.3.2 Posibles usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.3.3 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.3.4 Aplicaciones que soportan WebDAV . . . . . . . . . . . . . . . . . . . . 104

8 Bases de datos y búsqueda en la Web 107

8.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

8.2 Sistemas gestores de bases de datos . . . . . . . . . . . . . . . . . . . . . . . . 108

8.2.1 MySql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

8.2.2 mSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

8.2.3 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

8.2.4 Soluciones comerciales . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

8.3 Acceso a datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

8.3.1 Interfaces de acceso a datos . . . . . . . . . . . . . . . . . . . . . . . . 113

8.3.2 Ejemplos de acceso a datos con distintas tecnologías Web . . . . . . . . 115

8.4 Búsqueda en la Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8.4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8.4.2 Funcionamiento de un buscador . . . . . . . . . . . . . . . . . . . . . . 121

8.4.3 Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

8.4.4 Indexador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8.4.5 Motor de búsqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

8.4.6 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

9 Registro de actividad, log o bitácora 125

9.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

9.2 Posibilidades para almacenar información de registro . . . . . . . . . . . . . . . 126

9.2.1 Ficheros de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

xiv ÍNDICE GENERAL

9.2.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

9.2.3 Otras alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

9.3 Utilidades relacionadas con los datos de registro . . . . . . . . . . . . . . . . . . 128

9.3.1 Análisis de Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

9.3.2 Rotación del log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

II Aplicación práctica 1:
Configuración de un servidor Web Apache 131

10 Instalando Apache para Linux/Unix 133

10.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

10.2 Requisitos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

10.3 Conseguir una copia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

10.4 Instalación desde código fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

10.4.1 Configurando la instalación . . . . . . . . . . . . . . . . . . . . . . . . 136

10.4.2 Compilar y acabar la instalación . . . . . . . . . . . . . . . . . . . . . . 139

10.4.3 Compilando nuevos módulos con apxs . . . . . . . . . . . . . . . . . . . 140

10.5 Instalación desde código precompilado . . . . . . . . . . . . . . . . . . . . . . . 140

10.5.1 Distribución binaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

10.5.2 Gestores de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

10.6 Arranque y parada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

10.6.1 Arranque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

10.6.2 Parada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

10.6.3 Rearranque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

10.6.4 Volver a leer la configuración . . . . . . . . . . . . . . . . . . . . . . . 145

10.6.5 El ejecutable httpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

10.6.6 El script apachectl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

11 Configuración básica del servidor 149

11.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

11.2 Ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

11.3 Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

ÍNDICE GENERAL xv

11.4 Directivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

11.4.1 Definición de una directiva . . . . . . . . . . . . . . . . . . . . . . . . . 152

11.4.2 Una posible clasificación de las directivas . . . . . . . . . . . . . . . . . 155

11.5 Definición del entorno del servidor principal . . . . . . . . . . . . . . . . . . . . 155

11.5.1 Identificación del servidor . . . . . . . . . . . . . . . . . . . . . . . . . 155

11.5.2 Localización de ficheros o módulos . . . . . . . . . . . . . . . . . . . . 158

11.5.3 Creación de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

11.5.4 Configuración de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

11.6 Indexación de directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

11.6.1 AddIcon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

11.6.2 AddIconByEncoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

11.6.3 AddIconByType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

11.6.4 DefaultIcon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

11.6.5 DirectoryIndex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

11.6.6 HeaderName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

11.6.7 IndexIgnore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

11.6.8 IndexOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

11.6.9 ReadmeName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

11.7 Directivas contenedoras y alias . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

11.7.1 Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

11.7.2 <Directory> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

11.7.3 <Files> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

11.7.4 <Limit> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

11.7.5 <Location> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

11.7.6 ScriptAlias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

11.7.7 <VirtualHost> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

11.8 Tipos MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

11.8.1 AddCharset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

11.8.2 AddEncoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

11.8.3 AddLanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

xvi ÍNDICE GENERAL

11.8.4 AddType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

11.8.5 DefaultType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
11.8.6 LanguagePriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
11.8.7 MIMEMagicFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
11.9 Utilidades de log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
11.9.1 CustomLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
11.9.2 LogFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
11.9.3 LogLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
11.9.4 TransferLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
11.10Control de secciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
11.10.1 Allow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
11.10.2 AllowOverride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
11.10.3 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
11.10.4 Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
11.11Configuración de hosts virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . 205
11.11.1 NameVirtualHost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
11.11.2 ServerAlias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
11.12Otras directivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
11.12.1 BrowserMatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
11.12.2 UserDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
11.13Consideraciones de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
11.13.1 Ficheros srm.conf y access.conf . . . . . . . . . . . . . . . . . . . . . . 210
11.13.2 Permisos en ficheros de Apache . . . . . . . . . . . . . . . . . . . . . . 211
11.13.3 Directiva UserDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
11.13.4 Accesos a páginas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
11.13.5 Sobreescritura de configuración . . . . . . . . . . . . . . . . . . . . . . 212
11.13.6 Identidad del servidor. User y Group . . . . . . . . . . . . . . . . . . . . 213
11.13.7 Problemas de Apache relacionados con DNS . . . . . . . . . . . . . . . 213
11.13.8 Option Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
11.14Comprobaciones de la configuración del servidor . . . . . . . . . . . . . . . . . 213
11.14.1 mod_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
11.14.2 mod_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
ÍNDICE GENERAL xvii

12 Servidores virtuales 217

12.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

12.2 Host virtuales basados en IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

12.2.1 Varios demonios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

12.2.2 Un solo demonio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

12.3 Host virtuales basados en nombre . . . . . . . . . . . . . . . . . . . . . . . . . 219

12.3.1 Problemas con navegadores antiguos . . . . . . . . . . . . . . . . . . . . 220

12.4 Host virtuales dinámicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

12.5 Consideraciones finales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

12.5.1 El servidor virtual por defecto . . . . . . . . . . . . . . . . . . . . . . . 222

12.5.2 Depurando la configuración . . . . . . . . . . . . . . . . . . . . . . . . 223

13 Configurando SSI y CGI 225

13.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

13.2 SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

13.2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

13.2.2 Instalar el soporte SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

13.2.3 Configurar ejecución SSI . . . . . . . . . . . . . . . . . . . . . . . . . . 227

13.3 CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

13.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

13.3.2 Usando suEXEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

13.3.3 Instalar el soporte a CGI . . . . . . . . . . . . . . . . . . . . . . . . . . 230

13.3.4 Posibilidades de configuración de scripts CGI . . . . . . . . . . . . . . . 232

13.3.5 Errores habituales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

13.3.6 Consideraciones de seguridad . . . . . . . . . . . . . . . . . . . . . . . 236

14 Servlets y Jsp con Tomcat. Integración con Apache 237

14.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

14.2 Pasos previos: instalar soporte Java . . . . . . . . . . . . . . . . . . . . . . . . . 238

14.2.1 Instalar JSDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

14.2.2 Probar el JSDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

xviii ÍNDICE GENERAL

14.3 Tomcat como contenedor Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . 240

14.3.1 Instalar Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

14.3.2 Ficheros de configuración . . . . . . . . . . . . . . . . . . . . . . . . . 241

14.3.3 Probar Tomcat como contenedor Servlet independiente . . . . . . . . . . 241

14.3.4 Iniciar con el arranque del sistema . . . . . . . . . . . . . . . . . . . . . 242

14.4 Integrando Apache y Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

14.4.1 Obtener adaptador para Apache . . . . . . . . . . . . . . . . . . . . . . 243

14.4.2 Habilitar auto-configuración de Tomcat para Apache . . . . . . . . . . . 244

14.4.3 Probar Tomcat como contenedor Servlet de Apache . . . . . . . . . . . . 245

15 Configurando PHP 247

15.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

15.2 Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

15.2.1 Instalación usando DSO . . . . . . . . . . . . . . . . . . . . . . . . . . 248

15.3 Configurar Apache para manejar PHP . . . . . . . . . . . . . . . . . . . . . . . 250

15.3.1 php.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

15.3.2 httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

15.4 Probar funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

16 Autenticación, autorización y control de acceso 253

16.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

16.2 Autenticación/autorización Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 254

16.2.1 Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

16.2.2 Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

16.2.3 Posibles problemas y soluciones . . . . . . . . . . . . . . . . . . . . . . 256

16.3 Autenticación/autorización Digest . . . . . . . . . . . . . . . . . . . . . . . . . 258

16.4 Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

16.5 Aspectos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

ÍNDICE GENERAL xix

17 Habilitando la gestión remota de recursos con WebDAV 261

17.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

17.2 Obtener el software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

17.3 Instalando como DSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

17.4 Configurando Apache para manejar mod_dav . . . . . . . . . . . . . . . . . . . 263

17.4.1 Habilitando DAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

17.4.2 Base de datos de bloqueos . . . . . . . . . . . . . . . . . . . . . . . . . 263

17.4.3 Estableciendo temporizadores . . . . . . . . . . . . . . . . . . . . . . . 264

17.4.4 Consideraciones de seguridad . . . . . . . . . . . . . . . . . . . . . . . 264

17.5 Probar configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

18 Configurar conexiones seguras en Apache sobre SSL 267

18.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

18.2 Apache + mod_ssl + OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

18.3 Prerrequisito: OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

18.4 Instalación de Apache + mod_ssl . . . . . . . . . . . . . . . . . . . . . . . . . . 270

18.4.1 Obtener paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

18.4.2 Aplicar parches y configurar instalación de Apache . . . . . . . . . . . . 271

18.4.3 Instalar Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

18.5 Revisando la configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

18.6 Probando una conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

18.6.1 Arranque del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

18.6.2 Los clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

19 Personalizar el registro y recopilar estadísticas 279

19.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

19.2 Configuración estándar para ficheros de log Apache . . . . . . . . . . . . . . . . 280

19.3 Personalizando los métodos de registro de información . . . . . . . . . . . . . . 280

19.3.1 Variables de formato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

19.3.2 Logging a varios ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . 282

19.3.3 Logging condicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

xx ÍNDICE GENERAL

19.3.4 Logging con servidores virtuales . . . . . . . . . . . . . . . . . . . . . . 282

19.3.5 Logging mediante canalizado. Un ejemplo: Cronolog . . . . . . . . . . . 283

19.4 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

19.5 Recopilación de estadísticas. Un ejemplo: Analog . . . . . . . . . . . . . . . . . 286

19.5.1 Instalando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

19.5.2 Configurando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

19.5.3 Ejecutando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

20 Otros módulos y tecnologías relacionadas 293

20.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

20.2 Balanceo de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

20.3 Control de ancho de banda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

20.4 Detección de intrusos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

20.5 Integración con Corba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

20.6 Proxy / caché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

20.7 Redundancia y tolerancia a fallos . . . . . . . . . . . . . . . . . . . . . . . . . . 296

20.8 Reescritura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

20.9 Soporte a pago electrónico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

20.10Interfaces de administración gráfica . . . . . . . . . . . . . . . . . . . . . . . . 297

20.11Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

III Aplicación práctica 2:

Desplegando soluciones reales basadas en Web 299

21 Primeros pasos 303

21.1 Definición del ejemplo: una Escuela de Informática . . . . . . . . . . . . . . . . 303

21.2 Instalar y arrancar un servidor actualizado . . . . . . . . . . . . . . . . . . . . . 304

21.3 Publicar la primera Web de la Escuela . . . . . . . . . . . . . . . . . . . . . . . 304

21.3.1 Hosts Virtuales por departamento . . . . . . . . . . . . . . . . . . . . . 305

21.3.2 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

21.3.3 Definiendo los nuevos servidores virtuales . . . . . . . . . . . . . . . . . 306

21.3.4 Chequeando la configuración . . . . . . . . . . . . . . . . . . . . . . . . 308

ÍNDICE GENERAL xxi

22 Zona de download de mantenimiento automático 311

22.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
22.2 Configuración básica del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . 312
22.2.1 FancyIndexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
22.2.2 SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
22.3 El resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

23 Negociación de contenido para personalizar el idioma 317

23.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
23.2 Configurando la negociación de contenido . . . . . . . . . . . . . . . . . . . . . 318
23.3 Personalizar los mensajes de error . . . . . . . . . . . . . . . . . . . . . . . . . 318

24 Linkómetro. Ejecución de scripts CGI de usuario 323

24.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
24.2 Configuración básica del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . 323
24.3 Configurar un script de usuario de ejemplo. “Linkómetro” . . . . . . . . . . . . 325
24.4 El resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

25 Dreamweaver y WebDav. Gestión remota de sitios Web 329

25.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
25.2 Configuración del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
25.3 El resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

26 UDMSearch. Un buscador Web 333

26.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
26.2 El buscador UDMSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
26.2.1 Características del buscador UDMSearch . . . . . . . . . . . . . . . . . 334
26.3 Instalación básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
26.3.1 Listas de parada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
26.3.2 Extracción de raíces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
26.4 Configurar el robot indexador de páginas . . . . . . . . . . . . . . . . . . . . . . 336
26.5 Ejecutar el robot indexador de páginas . . . . . . . . . . . . . . . . . . . . . . . 338
26.6 Configurar el motor de búsqueda y la interface Web . . . . . . . . . . . . . . . . 339
26.7 Probar una búsqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
xxii ÍNDICE GENERAL

27 Jive. Un sistema de foros basado en Servlets y JSP 343

27.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

27.2 Jive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

27.3 Instalar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

27.4 Configurar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

27.4.1 Configurar acceso a la base de datos . . . . . . . . . . . . . . . . . . . . 345

27.4.2 Configuración básica de la aplicación en el contenedor Servlet . . . . . . 345

27.4.3 Terminar la configuración desde el entorno Web . . . . . . . . . . . . . . 347

27.5 Probar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

28 PhpMyAdmin. Gestión Web de bases de datos MySQL 349

28.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

28.2 EL programa phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

28.2.1 Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

28.2.2 Reconfigurar Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

28.2.3 Probar el resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

28.3 Añadiendo seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

28.3.1 Autenticación básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

28.3.2 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

IV Conclusión y trabajos futuros 355

V Apéndices 359

A El lenguaje HTML 361

A.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

A.2 Algunas etiquetas comunes en HTML . . . . . . . . . . . . . . . . . . . . . . . 362

A.3 Formularios HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

A.3.1 Campos del formulario . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

A.3.2 Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

ÍNDICE GENERAL xxiii

B Dynamic Shared Objects en Apache 367

B.1 Algo de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

B.1.1 Carga automática, bibliotecas compartidas . . . . . . . . . . . . . . . . . 368

B.1.2 Carga manual, objetos compartidos . . . . . . . . . . . . . . . . . . . . 368

B.2 Utilización práctica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

B.3 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

B.4 Plataformas soportadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

B.5 Ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

C Expresiones regulares 373

C.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

C.2 Nociones básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

D Configuración por defecto del servidor Apache 377

Bibliografía 407
xxiv ÍNDICE GENERAL
Índice de Tablas

1.1 Servidores Web más usados en julio de 2001, según Netcraft. . . . . . . . . . . . 10

1.2 Breve tabla comparativa de servidores Web del mercado. . . . . . . . . . . . . . 18

2.1 Métodos HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2 Algunos códigos típicos de estado HTTP . . . . . . . . . . . . . . . . . . . . . . 25

2.3 Encabezados HTTP generales . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.4 Encabezados HTTP de solicitud . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5 Encabezados HTTP de respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6 Encabezados HTTP de entidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1 Variables de entorno CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Variables específicas de SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.2 Condiciones de test SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3 Objetos implícitos JSP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.4 Objetos implícitos ASP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.1 Servidores con soporte WebDAV. . . . . . . . . . . . . . . . . . . . . . . . . . . 105

7.2 Herramientas de creación de documentos con soporte WebDAV. . . . . . . . . . 105

7.3 Herramientas de gestión de ficheros con soporte WebDAV. . . . . . . . . . . . . 105

15.1 Directivas de PHP4 dentro de la configuración de Apache. . . . . . . . . . . . . 251

19.1 Variables de formato para log. . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

19.2 Algunas directivas de configuración de Analog. . . . . . . . . . . . . . . . . . . 288

26.1 Algunas directivas de configuración de UDMSearch. . . . . . . . . . . . . . . . 337

xxv
xxvi ÍNDICE DE TABLAS

A.1 Algunas categorías importantes de etiquetas HTML. . . . . . . . . . . . . . . . . 362

C.1 Patrones de repetición en expresiones regulares. . . . . . . . . . . . . . . . . . . 374

C.2 Clases predefinidas en expresiones regulares. . . . . . . . . . . . . . . . . . . . 376

Índice de Figuras

1.1 Arquitectura de funcionamiento de un servidor Web. . . . . . . . . . . . . . . . 5

1.2 Arquitectura de funcionamiento de un servidor de aplicaciones. . . . . . . . . . . 7

1.3 Evolución de mercado de servidores Web. Julio de 2001, Netcraft. . . . . . . . . 10

1.4 Cuota de mercado en España para servidores Web. Julio de 2001, Security Space. 11

3.1 Arquitectura de la interface CGI. . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Esquema de ejecución Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1 Esquema general para un lenguaje de código embebido en HTML. . . . . . . . . 52

5.1 Situación del protocolo SSL en la torre de protocolos. . . . . . . . . . . . . . . . 81

6.1 XML y los lenguajes de etiquetado . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.2 Visualización de un ejemplo sencillo en XHTML. . . . . . . . . . . . . . . . . . 95

6.3 Esquema de invocación a un método con SOAP sobre HTTP. . . . . . . . . . . . 97

7.1 Ejemplo de colaboración usando WebDAV. . . . . . . . . . . . . . . . . . . . . 103

8.1 Arquitectura genérica de interfaces de acceso a datos. . . . . . . . . . . . . . . . 113

8.2 Arquitectura de un buscador genérico. . . . . . . . . . . . . . . . . . . . . . . . 121

10.1 Página de descarga de Apache. . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

11.1 Información proporcionada por Apache server-status. . . . . . . . . . . . . . . . 214

11.2 Información proporcionada por Apache server-info. . . . . . . . . . . . . . . . . 215

13.1 Error típico provocado por un problema en un script CGI. . . . . . . . . . . . . . 234

13.2 Error típico provocado por un problema de permisos en un script CGI. . . . . . . 235

xxvii
xxviii ÍNDICE DE FIGURAS

14.1 Página de descarga de J2SDK. . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

14.2 Página de descarga de Tomcat. . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

14.3 Tomcat funcionando. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

15.1 Página de descarga de PHP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

15.2 Salida de phpinfo(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

16.1 Diálogo de petición de login/password en un navegador Opera. . . . . . . . . . . 255

17.1 Página de descarga de mod_dav . . . . . . . . . . . . . . . . . . . . . . . . . . 262

17.2 Un cliente WebDAV para Linux: WebDAV Explorer. . . . . . . . . . . . . . . . 266

18.1 Arquitectura del módulo mod_ssl. . . . . . . . . . . . . . . . . . . . . . . . . . 268

18.2 Página de descarga de OpenSSL. . . . . . . . . . . . . . . . . . . . . . . . . . . 269

18.3 Página de descarga de modSSL. . . . . . . . . . . . . . . . . . . . . . . . . . . 270

18.4 Estableciendo una sesión HTTPS. . . . . . . . . . . . . . . . . . . . . . . . . . 276

19.1 Salida generada por Analog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

21.1 Apariencia de una primera página Web en HTML. . . . . . . . . . . . . . . . . . 305

21.2 Host virtual del departamento de matemáticas. . . . . . . . . . . . . . . . . . . . 307

22.1 Apariencia de una página Web de download basada en FancyIndexes. . . . . . . 315

22.2 Apariencia de una página Web de download basada en SSI. . . . . . . . . . . . . 316

23.1 Configurando nuestro idioma de preferencia en Opera 5 para Linux. . . . . . . . 319

23.2 Un error personalizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

24.1 Apariencia de una página Web de marcadores generada con el Linkómetro. . . . . 325

24.2 Apariencia de la interface del Linkómetro. . . . . . . . . . . . . . . . . . . . . . 327

25.1 Utilizando Dreamweaver como cliente WebDAV. . . . . . . . . . . . . . . . . . 332

26.1 Resultado de una búsqueda con el motor de búsqueda de UDMSearch. . . . . . . 341

27.1 Configuración basada en Web de Jive. . . . . . . . . . . . . . . . . . . . . . . . 347

27.2 Administración de Jive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

ÍNDICE DE FIGURAS xxix

27.3 Aspecto de un skin de Jive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

28.1 phpMyAdmin en funcionamiento. . . . . . . . . . . . . . . . . . . . . . . . . . 351

A.1 Un formulario sencillo en HTML. . . . . . . . . . . . . . . . . . . . . . . . . . 365

xxx ÍNDICE DE FIGURAS
Índice de Listados

3.1 Un script de prueba de CGI. test-cgi. . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 Estructura de un Servlet básico. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3 Recuperar y presentar los datos de un formulario con un Servlet. Formulario.java. 47

3.4 El formulario de entrada: formulario.htm. . . . . . . . . . . . . . . . . . . . . . 48

4.1 JSP para acceder a los datos de un formulario. formulario.jsp. . . . . . . . . . . 64

4.2 PHP para acceder a los datos de un formulario. formulario.php. . . . . . . . . . . 71

4.3 Asp para acceder a los datos de un formulario. formulario.asp. . . . . . . . . . . 75

6.1 Un documento XML de ejemplo. . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.2 Código de una página sencilla en XHTML. . . . . . . . . . . . . . . . . . . . . 95

8.1 Acceso a bases de datos MySQL desde un script cgi en Perl. . . . . . . . . . . . 116

8.2 Acceso a bases de datos MySQL desde una página ASP. . . . . . . . . . . . . . 118

8.3 Acceso a bases de datos MySQL desde una página JSP. . . . . . . . . . . . . . . 119

8.4 Acceso a bases de datos MySQL desde una página PHP. . . . . . . . . . . . . . 120

8.5 Restringir el acceso de robots a un sitio Web. robots.txt. . . . . . . . . . . . . . . 122

10.1 Opciones de httpd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

10.2 Opciones de apachectl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

11.1 Directiva ServerAdmin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

11.2 Directiva ServerName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

11.3 Directiva ServerSignature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

11.4 Directiva AccessFileName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

11.5 Directiva AddModule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

11.6 Directiva ClearModuleList. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

11.7 Directiva DocumentRoot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

11.8 Directiva <IfModule>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

xxxi
xxxii ÍNDICE DE LISTADOS

11.9 Directiva LoadModule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

11.10Directiva PidFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

11.11Directiva ScoreBoardFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

11.12Directiva ServerRoot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

11.13Directiva Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

11.14Directiva MaxClients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

11.15Directiva MaxRequestsPerChild. . . . . . . . . . . . . . . . . . . . . . . . . . . 166

11.16Directiva MaxSpareServers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

11.17Directiva MinSpareServers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

11.18Directiva ServerType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

11.19Directiva StartServers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

11.20Directiva User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

11.21Directiva KeepAlive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

11.22Directiva KeepAliveTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

11.23Directiva Listen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

11.24Directiva MaxKeepAliveRequests. . . . . . . . . . . . . . . . . . . . . . . . . . 172

11.25Directiva Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

11.26Directiva TimeOut. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

11.27Directiva UseCanonicalName. . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

11.28Directiva AddIcon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

11.29Directiva AddIconByEncoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

11.30Directiva AddIconByType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

11.31Directiva DefaultIcon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

11.32Directiva DirectoryIndex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

11.33Directiva HeaderName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

11.34Directiva IndexIgnore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

11.35Directiva IndexOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

11.36Directiva ReadmeName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

11.37Directiva Alias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

11.38Directiva <Directory>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

ÍNDICE DE LISTADOS xxxiii

11.39Directiva <Files>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

11.40Directiva <Limit>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

11.41Directiva <Location>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

11.42Directiva ScriptAlias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

11.43Directiva <VirtualHost>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

11.44Directiva AddCharset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

11.45Directiva AddEncoding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

11.46Directiva AddLanguage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

11.47Directiva AddType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

11.48Directiva DefaultType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

11.49Directiva LanguagePriority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

11.50Directiva MIMEMagicFile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

11.51Directiva CustomLog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

11.52Directiva ErrorLog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

11.53Directiva HostNameLookups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

11.54Directiva LogFormat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

11.55Directiva LogLevel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

11.56Directiva TransferLog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

11.57Directiva Allow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

11.58Directiva AllowOverride. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

11.59Directiva Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

11.60Directiva Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

11.61Directiva BindAddress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

11.62Directiva NameVirtualHost. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

11.63Directiva ServerAlias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

11.64Directiva BrowserMatch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

11.65Directiva UserDir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

14.1 El programa Hola Mundo escrito en Java. . . . . . . . . . . . . . . . . . . . . . 240

15.1 phpinfo(). Una página PHP muy simple. . . . . . . . . . . . . . . . . . . . . . . 252

16.1 Perl para tareas de autenticación. . . . . . . . . . . . . . . . . . . . . . . . . . . 258

18.1 Configurando mod_ssl. Resultado de ./configure . . . . . . . . . . . . . . . . . . 272

18.2 Configuración de un host virtual para manejar SSL. . . . . . . . . . . . . . . . . 275

19.1 Crear una cookie con JavaScript. . . . . . . . . . . . . . . . . . . . . . . . . . . 286

19.2 Ejemplo de configuración de Analog con 3 ficheros. SearchQuery.cfg. . . . . . . 288

19.3 Ejemplo de configuración de Analog con 3 ficheros. analoggeneral.cfg. . . . . . 290

19.4 Ejemplo de configuración de Analog con 3 ficheros. analog.cfg. . . . . . . . . . 290

21.1 Una primera página Web en HTML. . . . . . . . . . . . . . . . . . . . . . . . . 305

21.2 Servidor virtual por defecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

21.3 Un servidor virtual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

22.1 Configuración de una página de download con FancyIndexing. . . . . . . . . . . 312

22.2 Configuración de una página de download. Fichero HEADER. . . . . . . . . . . 313

22.3 Configuración de una página de download. Fichero README. . . . . . . . . . . 313

22.4 Configuración de una página de download con SSI. . . . . . . . . . . . . . . . . 314

22.5 Página de download con SSI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

23.1 Negociación de contenido SSI. head.shtml.gl. . . . . . . . . . . . . . . . . . . . 320

23.2 Negociación de contenido SSI. foot.shtml.gl. . . . . . . . . . . . . . . . . . . . . 321

23.3 Negociación de contenido SSI. 404.shtml.gl. . . . . . . . . . . . . . . . . . . . . 321

24.1 Configuración básica para ejecución de CGIs. . . . . . . . . . . . . . . . . . . . 324

24.2 Configuración para ejecución de CGIs en directorios de usuario. . . . . . . . . . 325

25.1 Habilitar WebDAV para construir colaborativamente un servidor virtual. . . . . . 330

25.2 Habilitar control de acceso a un directorio con acceso WebDAV. . . . . . . . . . 331

26.1 Formato de un fichero con listas de parada para UDMSearch. . . . . . . . . . . . 336

26.2 Configuración del indexador de UDMSearch. indexer.conf. . . . . . . . . . . . . 338

26.3 Configuración del indexador de UDMSearch. httpd.conf. . . . . . . . . . . . . . 340

27.1 Configuración de Jive. server.xml. . . . . . . . . . . . . . . . . . . . . . . . . . 346

27.2 Configuración de Jive. jive.properties. . . . . . . . . . . . . . . . . . . . . . . . 346

28.1 Configuración de httpd.conf para uso de phpMyAdmin. . . . . . . . . . . . . . . 351

28.2 Configuración 1 httpd.conf para uso de phpMyAdmin. . . . . . . . . . . . . . . 353

28.3 Configuración httpd.conf para uso de phpMyAdmin sobre SSL. . . . . . . . . . 354

A.1 Un formulario sencillo en HTML. . . . . . . . . . . . . . . . . . . . . . . . . . 365

D.1 Configuración por defecto del servidor . . . . . . . . . . . . . . . . . . . . . . . 405

 Parte I

Conceptos teóricos:
El Web, servidores y tecnologías
asociadas

1
Capítulo 1

Panorámica actual

Contenidos de este capítulo

1.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Servidores Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Servidores de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Servicios añadidos de los servidores de aplicaciones . . . . . . . . . . 7
1.3.2 Tecnologías para implementar servidores de aplicaciones . . . . . . . . 8
1.4 Mediciones de mercado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Algunos ejemplos de servidores . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.1 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.2 BEA Weblogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.3 Enhydra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.4 Jigsaw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.5 Macromedia-Allaire ColdFusion . . . . . . . . . . . . . . . . . . . . . 15
1.5.6 Microsoft IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5.7 NCSA HTTPd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.8 Netscape-Sun iPlanet . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.9 Zeus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5.10 Tabla comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6 Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.1 Introducción

La idea de la World Wide Web (en adelante Web) nació en 1989, cuando Tim Berners-Lee del
Laboratorio Europeo de Física de Partículas (conocido como CERN) propuso las bases teóricas
de un proyecto que permitiría difundir investigaciones e ideas a través de la red. En 1990

3
4 CAPÍTULO 1. PANORÁMICA ACTUAL

apareció la primera implementación, que ya soportaba conceptos habituales hoy en día (hipertexto,
hiperenlaces, etc.). Desde ese momento la Web ha crecido mucho, su éxito se debe entre
otras cosas a la facilidad que ofrece para navegar por la información sin necesidad de aprender
comandos complicados, únicamente se necesita conocer el manejo de un entorno de ventanas y
del ratón.

La Web trabaja siguiendo un modelo cliente/servidor y utiliza el protocolo HTTP (HyperText

Transfer Protocol) para la comunicación entre los equipos. El lenguaje estándar en el que se
codifican los contenidos hipertexto (páginas) es HTML (Hypertext Markup Language). Este
lenguaje incluye la capacidad de crear hiperenlaces mediante URLs (Uniform Resource Locators),
que pueden representar cualquier archivo o recurso en la red.

Basándose en los principios básicos definidos por Berners-Lee, se han desarrollado multitud de
servicios. La mayor evolución ha tenido lugar en el lado del servidor. A lo largo de este proyecto
se hará una presentación de distintas tecnologías asociadas a los servidores Web.

Servidores Web y de aplicaciones

Los servidores Web son la base en la que se apoya el funcionamiento de la World Wide Web. Pero
de un tiempo a esta parte también se escucha mucho el término servidores de aplicaciones. Existe
mucha confusión sobre el significado exacto de estas denominaciones, mucha gente piensa que
son lo mismo, mientras otros grupos defienden que son completamente diferentes.

Para aclarar un poco las ideas hagamos un poco de historia. Cuando se crearon los primeros
servidores de páginas Web (Web servers), su única misión era recuperar una página Web estática
de su disco duro y enviársela al cliente (navegador). Para cualquier otro tipo de información que
debiera generarse de manera dinámica (respuestas a búsquedas, etc.) el servidor tenía que ceder el
control a algún tipo de código externo mediante CGI.

Con el paso del tiempo el uso de servidores Web se generalizó y se hizo necesario incrementar
los servicios ofrecidos. El primer paso fue mejorar la eficiencia en el proceso de construcción de
información dinámica, y desde ahí han surgido multitud de tecnologías1 . Finalmente la evolución
ha llevado a crear un nuevo término: servidor de aplicaciones (Application server). Hay bastantes
intereses (y estrategias de marketing) que intentan hacer creer que esto es algo completamente
nuevo y que no tiene nada que ver con todo lo demás. En realidad, a un nivel básico, casi todos los
servidores Web actuales son también servidores de aplicaciones, ya que incluyen alguna tecnología
(CGI, PHP, JSP, etc.) que permite crear aplicaciones que generan contenido dinámico.

En las siguientes secciones se dará una visión general de los productos actuales y las tendencias
del mercado.

1 Una buena parte de ellas se abordan en este proyecto.

1.2. SERVIDORES WEB 5

1.2 Servidores Web

Un servidor Web es, esencialmente un programa que escucha en un puerto a la espera de

conexiones. Cuando se detecta una, el servidor espera a recibir una petición en formato adecuado
desde la aplicación cliente (navegador, gestor de download, indexador de páginas, telnet, etc.). El
recurso pedido hace referencia a un archivo en el disco duro2 que el servidor es capaz de recuperar
y enviar al cliente. Tanto la petición como la respuesta se encapsulan siguiendo el protocolo HTTP.
La arquitectura (figura 1.1) se basa en el modelo cliente-servidor y cada parte está típicamente en
una máquina distinta de la red, aunque no hay ningún problema si residen en la misma máquina.

Figura 1.1: Arquitectura de funcionamiento de un servidor Web.

Hoy en día existen multitud de productos que funcionan como servidores Web3 . Se presenta a
continuación un breve listado con algunos de los más conocidos. Un listado más completo puede
encontrarse en el sitio http://www.serverwatch.com/webservers.html [114]:

Apache

iPlanet Web Server

Jigsaw

Microsoft IIS

Microsoft PWS

NCSA HTTPd
2 Los servidores Web más básicos sólo son capaces de recuperar archivos de disco duro.
3 Sus desarrolladores le dan este nombre, aunque en un sentido amplio, todos proveen algún soporte para ejecutar
aplicaciones y podrían ser “servidores de aplicaciones”.
6 CAPÍTULO 1. PANORÁMICA ACTUAL

Sambar Server

SimpleServer:WWW

Stronghold

1.3 Servidores de aplicaciones

Un servidor de aplicaciones no es más que un cambio de nombre, para algunos servidores Web
de nueva generación que proporcionan la lógica de negocio sobre la que construir aplicaciones.
Suelen asociarse con servidores de alto rendimiento pensados para dar servicio a sitios Web
(Web sites) con grandes necesidades: afluencia de visitas, movimiento de datos, atención de
transacciones hacia bases de datos, etc. Generalmente los fabricantes del sector tienen a
disposición del público un servidor Web básico y otro con multitud de extensiones fuertemente
integradas al que llaman servidor de aplicaciones.
Puede encontrarse un buen listado de servidores de aplicaciones4 en el sitio Web http://www.
serverwatch.com/appservers.html [114]. A modo de ejemplo se muestra un listado con los
productos de algunas empresas bien conocidas:

BEA Weblogic Server

Borland AppServer

Allaire ColdFusion

Lotus Domino

Netscape application server

Oracle application server

Sybase Enterprise Server

IBM WebSphere

Un servidor de aplicaciones clásico (figura 1.2) se apoya en un modelo cliente/servidor de tres

capas:

1. Presentación: una interfaz, generalmente gráfica que reside en los clientes. El ejemplo típico
es un navegador.

2. Lógica de negocio: donde reside el servidor de aplicaciones y el conjunto de programas a

los que da soporte.

3. Almacenamiento: generalmente una base de datos.

4 Denominados así por el fabricante. Recuerde que casi cualquier servidor Web de hoy en día puede ser un servidor

de aplicaciones.
1.3. SERVIDORES DE APLICACIONES 7

Figura 1.2: Arquitectura de funcionamiento de un servidor de aplicaciones.

1.3.1 Servicios añadidos de los servidores de aplicaciones

¿Cuáles son los servicios, que añadidos a un servidor Web, lo convierten en servidor de
aplicaciones?. En general se puede afirmar que cuantos más puntos de la siguiente lista
implemente un servidor, más “de aplicaciones” será.

Generación de HTML: debe incorporar generación dinámica de contenido (HTML, XHTML,

XML, etc.), para enviar al cliente.

Trabajo con bases de datos: existirán objetos que faciliten el acceso a bases de datos,
ocupándose de gestionar las conexiones y proporcionando un acceso uniforme. Otros
objetos se encargarán de la gestión de transacciones englobando diversas sentencias y
ocupándose de los commit o rollback.

Funcionamiento multiproceso o multihilo: el servidor es el responsable de tener funcionando

un número de hilos o procesos que atiendan a distintas peticiones.

Sesiones: HTTP es un protocolo sin estados. Un servidor de aplicaciones provee de persistencia

8 CAPÍTULO 1. PANORÁMICA ACTUAL

a los datos del usuario mediante objetos de sesión (session). Elimina la necesidad de incluir
código en las aplicaciones para diferenciar las peticiones de distintos usuarios.

Lógica de negocio: la lógica de negocio propia de cada aplicación debe poder ser encapsulada en
componentes. A cada uno de ellos se le podrán asignar mecanismos propios de seguridad,
gestión de transacciones, ...

Seguridad: debe poseer características de seguridad que den soporte a aplicaciones seguras. Los
clientes deben autentificarse contra al servidor, y este es el responsable de darles acceso a
sus diferentes componentes, como puede ser una base de datos. La mayoría de servidores
disponen de un mecanismo para incorporar nuevos usuarios y grupos. El control de a que
partes del servidor puede acceder un usuario puede ser controlado por diversos métodos, por
ejemplo en un directorio LDAP (Lightweight Directory Access Protocol).

Balanceo de carga: trabajando sobre un cluster5 de servidores, puede enviar la peticiones a

diferentes equipos en función de la carga y la disponibilidad. Este balanceo es la base
para implementar sistemas tolerantes a fallos o herramientas para la monitorización
centralizada de todos los equipos del cluster.

1.3.2 Tecnologías para implementar servidores de aplicaciones

J2EE

La estrategia comercial de Sun con respecto a Java y a su nueva plataforma J2EE (Java 2
Enterprise Edition) [54] está teniendo mucho éxito en este sector. De hecho, a veces se utiliza
el término: servidores de aplicaciones Java para referirse a aquellos servidores de aplicaciones
que implementan adecuadamente las soluciones propuestas por J2EE..

J2EE es una especificación que propone un estándar para servidores de aplicaciones. Define
diferentes tecnologías e indica como deben trabajar juntas. Todos los servidores de aplicaciones
que quieran ser etiquetados como servidores de aplicaciones J2EE deben pasar un test de
compatibilidad, que garantiza la correcta implementación de las tecnologías Java.

Muchos grandes fabricantes (IBM, Sun Microsystems, Hewlett-Packard, Oracle, Sybase, etc.) y
empresas de nueva tecnología (BEA, etc.) se han subido a este tren. La razón más importante para
ello es que la infraestructura de Java parece ideal para obtener los servicios añadidos que se han
comentado en la sección anterior.

Pero las soluciones basadas en Java también tienen su parte negativa: la gran cantidad de recursos
(CPU y memoria) que consumen las aplicaciones, la lentitud de ejecución debido a la necesidad
de una máquina virtual que interprete el código de bytes, etc.
5 De manera sencilla se puede decir que un cluster es un conjunto de servidores que aparecen ante el usuario como

si fuesen uno solo.

1.4. MEDICIONES DE MERCADO 9

No-J2EE

Hoy en día prácticamente todos lo nuevo que aparece se basa en J2EE. Pero “había vida” antes
de J2EE, y alguna gente ya había invertido (tiempo y/o dinero) en desarrollar sus servidores de
aplicaciones. Estas soluciones generalmente están basadas en lenguajes propios de script, y tienen
la ventaja de que su aprendizaje es muy rápido.

Dos son los ejemplos más claros, por un lado PHP y por otro Coldfusion de Allaire-Macromedia.

PHP (PHP, Hypertext Preprocessor) [88] es un lenguaje potente que permite crear de
manera fácil aplicaciones Web. Es código abierto, aunque la empresa Zend Technologies
ofrece productos complementarios.

Allaire-Macromedia Coldfusion [28] es un programa comercial basado en el lenguaje de

script CFML (Coldfusion Markup Language). Hasta la versión 4 era independiente de J2EE,
pero el mercado manda, y la nueva versión ya integra la tecnología de lenguaje script de
ColdFusion, con un contenedor Servlet propio (JRun).

Microsoft

Como casi siempre, Microsoft va por libre. Si se opta por su servidor de aplicaciones, se está
obligado a utilizar la plataforma Microsoft completa.

Las primeras soluciones que ofreció esta empresa se basaban en el servidor Web IIS (Internet
Information Server), el lenguaje de script ASP (Active Server Pages) y la tecnología de objetos
distribuidos COM (Component Object Model). La nueva apuesta se llama .NET e incluye
ASP+, C#, mientras deja de lado las anteriores inversiones de Microsoft en Java (y programas
relacionados como Microsoft Visual J++).
Todas estas soluciones siguen la política habitual de Microsoft que tiende a apoyarse en las
entrañas de Windows y obviar estándares abiertos, pero hay alguna excepción, por ejemplo en
la plataforma .NET se incluye soporte a SOAP.

1.4 Mediciones de mercado

No es fácil saber cuantos servidores hay en Internet o cual es su cuota de mercado relativa, pero es
más difícil todavía obtener un listado de todos los servidores Web distintos que existen. Diversos
factores apoyan estas afirmaciones, entre ellos:

La gran cantidad de equipos conectados a Internet.

El echo de que cualquier equipo que responda a peticiones HTTP puede ser considerado
un servidor Web. Por ejemplo hay impresoras, programas antivirus, etc. que permiten su
configuración a través de la red, por medio de una solución propietaria basada en HTTP.
10 CAPÍTULO 1. PANORÁMICA ACTUAL

La posibilidad de cambiar la firma (información que identifica al servidor ante el cliente)

por motivos de seguridad.

...

Afortunadamente existen empresas consultoras especializadas en el tema. Muchas de ellas

presumen de ser independientes de los fabricantes y de no proporcionar opiniones sesgadas.
Quizá sea Netcraft [81] una de las que gozan de mejor prensa. Netcraft viene haciendo encuestas
desde 1995 y actualiza los valores mensualmente, lo que le permite analizar las tendencias. Los
resultados obtenidos están disponible al público en su sitio Web http://www.netcraft.com.

A continuación se presentan algunos de los datos que Netcraft ha publicado referidos al mes de
julio de 2001. Por un lado, un listado (tabla 1.1) de los servidores Web más usados6 , y por otro un
gráfico (figura 1.3) que recoge la evolución en cuota de mercado.

Servidor Cuota de mercado

Apache 58.73%
Microsoft-IIS 25.87%
iPlanet (Netscape-Enterprise) 4.20%
Zeus 2.54%
thttpd 1.61%
Rapidsite 1.33%
... ...

Tabla 1.1: Servidores Web más usados en julio de 2001, según Netcraft.

Figura 1.3: Evolución de mercado de servidores Web. Julio de 2001, Netcraft.

6 EL listado es inmenso, sólo se presentan aquí las primeras líneas.

1.5. ALGUNOS EJEMPLOS DE SERVIDORES 11

Otra empresa que realiza estudios de mercado, Security Space [112], es bien conocida y goza de
cierto prestigio. Básicamente ofrece los mismos servicios que Netcraft, esto permite comparar, y
el hecho es que ambas obtienen resultados bastante semejantes.

A continuación se muestra una medición que Netcraft no proporciona pero Security Space sí,
se trata de la cuota de mercado entre servidores españoles (figura 1.4) en julio del 2001. Para
información actualizada puede visitarse el sitio http://www.securityspace.com/.

Figura 1.4: Cuota de mercado en España para servidores Web. Julio de 2001, Security Space.

1.5 Algunos ejemplos de servidores

En las siguientes secciones se hará una breve descripción comparativa de las características de
algunos servidores. Se analizan no sólo los que poseen una mayor cuota absoluta de mercado,
también se tienen en cuenta aquellos que han avanzado mucho en cortos espacios de tiempo o
algunos que simplemente se considera necesario mencionar:

Apache

BEA Weblogic

Enhydra

Jigsaw

Macromedia-Allaire ColdFusion

Microsoft IIS

NCSA HTTPd
12 CAPÍTULO 1. PANORÁMICA ACTUAL

Netscape-Sun iPlanet

Zeus

1.5.1 Apache

Apache [14] es indiscutiblemente el servidor Web más extendido en el mercado. Nacido como un
conjunto de parches al servidor NCSA HTTPd, actualmente se distribuye para explotación en sus
versiones 1.3.X. Estas proporcionan multitud de características:

Respeto a los estándares (HTTP/1.1, etc.)

Multiplataforma. Aunque Apache tradicionalmente se utiliza en el mundo Unix/Linux, ha

sido portado a otros sistemas como Windows, AS/400 y OS/2.

Escalabilidad, mediante técnicas como el virtual hosting.

Soporte a lenguajes de programación en el lado servidor (PHP, JSP, Perl, etc.)

Seguridad mediante SSL, control de acceso y autentificación.

Precio, confiabilidad, rendimiento, construcción modular, ...

En el lado negativo, se puede señalar la relativa dificultad de configuración basada en ficheros de

texto7 si se compara con las facilidades que aportan otros servidores (incluso gratuitos, como el
mismo Jigsaw).

Actualmente se encuentra en desarrollo la nueva versión, Apache 2.0, que introduce una serie de
cambios estructurales en el código fuente, entre ellos:

Mejoras en portabilidad mediante el uso de una capa de abstracción llamada MPMs

(Multiple-Processing Modules). Esta capa se encarga de aislar el código multiproceso8 de
la plataforma subyacente.

Soporte más potente a módulos añadidos mediante una nueva API, llamada APR (Apache
Portable Run-Time), que acompañará a las distribuciones de Apache y permitirá a los
programadores de módulos externos trabajar con ella aislándose de las características
dependientes de la plataforma (como por ejemplo la creación de procesos).

Mejora de rendimiento en todas las plataformas.

7 Aunque hay alguna solución gráfica, como comanche http://www.covalent.net/projects/comanche/ [30]
8 Apache trata cada nueva petición como un proceso en Unix y como un hilo en Windows.
1.5. ALGUNOS EJEMPLOS DE SERVIDORES 13

Aunque la nueva versión de Apache no va a suponer un cambio radical en la forma de instalar,

configurar o administrar, si va a traer algún problema, por ejemplo, deberá pasar un tiempo antes
de que todos los módulos de terceras partes sean portados y funcionen adecuadamente con las
nuevas características de Apache 2.

Puede encontrar más información sobre Apache y tecnologías relacionadas en el sitio Web del
Apache Software Foundation [20] http://www.apache.org.

1.5.2 BEA Weblogic

BEA [24] es una empresa independiente que se ha lanzado al mundo de los servidores de
aplicaciones con un producto llamado Weblogic. Su ascenso ha sido muy rápido, consiguiendo
una importante implantación en el mercado debido, entre otros, a los siguientes aspectos:

Weblogic ofrece el mejor soporte Java del mercado (JSP, Java Messaging Services,
Enterprise JavaBeans, drivers nativos de BBDDs,etc.).

Puede colaborar con los servidores Web más utilizados (Apache, IIS, iPlanet, etc.).

Implementación cuidada y eficiente de características avanzadas. Balanceo de cargas,

recuperación, tolerancia a fallos, escalabilidad mediante clustering, etc, todas ellas son
tecnologías muy importantes en sitios de comercio electrónico y Weblogic las enfoca
especialmente bien. Otros servidores del mercado (ColdFusion, iPlanet, IIS, etc.) también
ofrecen estos servicios aunque no tan bien implementados.

Soporte a tecnología COM+ de Microsoft. Weblogic es uno de los primeros servidores de

aplicaciones que ofrece este soporte, aunque para ello simplemente enmascara los objetos
COM+ a través de CORBA, lo que hace que el manejo de esta tecnología todavía no sea
todo lo cómodo que sería deseable.

La principal desventaja es su precio (desde 2.000.000 pts. aproximadamente), que lo hacen

inalcanzable para muchos bolsillos. Existen distribuciones de Weblogic para Windows NT, Linux
y diversos Unix. Puede encontrar más información sobre los productos de BEA en su página Web
http://www.beasys.com/.

1.5.3 Enhydra

Enhydra [38] [63] es un servidor de aplicaciones Open-Source que permite el despliegue de

productos basados en Java/XML y define un marco de trabajo para el desarrollo de los mismos.
La arquitectura de Enhydra se basa en distintos componentes:

Enhydra Application Framework: un entorno basado en Servlets que provee servicios

comunes:
14 CAPÍTULO 1. PANORÁMICA ACTUAL

– Session manager: manejo de sesiones sobre Web.

– Presentation manager: controla como se presenta en la Web una aplicación Enhydra.
– Database manager: provee servicios relacionados con las bases de datos, como el
“pooling” de conexiones.
– Administration manager: una herramienta gráfica que permite el control de Enhydra.

Enhydra Multiserver: un entorno de ejecución basado en Servlets que permite la gestión,

monitorización y depuración de errores.

Enhydra XMLC: una herramienta que genera plantillas de objetos Java a partir de
documentos HTML o XML. Estos objetos podrán ser luego modificados desde la aplicación
generando documentos dinámicos.

Enhydra JDDI: una tecnología que permite la inclusión de Java en páginas HTML. Es una
aproximación estructurada muy parecida a los JSP.

Enhydra DODS: una herramienta gráfica que permite hacer correspondencias entre objetos
y bases de datos relacionales (Informix, SQL server, Oracle, PostgreSQL, Sybase).

Existen versiones para Windows, Linux/Unix y no supone ningún coste ya que es código abierto.
Para obtener información más reciente sobre el producto, puede visitar los sitios Web de Enhydra
http://www.enhydra.org o de la empresa consultora Lutris Technologies, que patrocina el
proyecto, http://www.lutris.com.

1.5.4 Jigsaw

Jigsaw 2.X [58], es un desarrollo del World Wide Web Consortium (W3C). No es un servidor
para explotación empresarial (por ejemplo, no soporta hosts virtuales), sino una implementación
que demuestra nuevas tecnologías (por ejemplo Jigsaw es uno de los pocos servidores que
implementan totalmente el protocolo HTTP/1.1).

Entre las características más destacadas:

Robustez: el desarrollo ha llegado a ser más robusto que la mayoría de los servidores Web
del mercado.

Escalabilidad: sigue un enfoque orientado a objetos, en este sentido, la funcionalidad del

servidor puede ser extendida con nuevos objetos9 .

Soporte integrado a Servlets y JSP.

Soporte WebDAV.

Proporciona una interface muy cómoda de configuración gráfica basada en Java.

9 Esta no es algo nuevo, aunque si una buena idea. Los módulos de Apache siguen la misma idea.
1.5. ALGUNOS EJEMPLOS DE SERVIDORES 15

Este software está completamente escrito en Java y disponible en multitud de plataformas. Es

completamente gratuito y puede ser descargado en http://www.w3.org/Jigsaw.

1.5.5 Macromedia-Allaire ColdFusion

Allaire ColdFusion [28] es un servidor de aplicaciones bastante extendido. Proporciona dos

herramientas básicas, por un lado ColdFusion Server para el despliegue de la aplicaciones y por
otro ColdFusion Studio para el desarrollo de las mismas.

Las versiones anteriores a ColdFusion 4.0 no apostaban claramente por la plataforma J2EE, si no
que preferían apoyarse en tecnologías propietarias como el lenguaje CFML (ColdFusion Markup
Language) que puede ser embebido en páginas HTML.

Los principales atractivos de ColdFusion son dos:

Integración de tecnologías: ColdFusion ofrece soporte integrado a distintas tecnologías, por

ejemplo: acceso a datos (ODBC, OLE DB, drivers nativos Oracle y Sybase, etc.), protocolos
(SMTP, POP3, LDAP, etc.), plataformas de objetos distribuidas (CORBA, COM).

Soporte directo de aplicaciones de comercio electrónico (CiberCash, Open Market, etc.)

En las últimas fechas ha aparecido la versión 5.0, fruto del cambio de orientación que se le ha dado
al producto tras la fusión de Allaire con Macromedia. Las principales novedades son el soporte
integrado a generación y manejo de datos en formato FLASH 10 y el intento de unirse a la corriente
de servidores compatibles con J2EE.

Actualmente existen versiones disponibles para Windows, Linux, Solaris y HP-UX, con precios
desde 260.000 pts. por servidor aproximadamente. Más información en la Web http://www.
macromedia.com/software/coldfusion/.

1.5.6 Microsoft IIS

Internet Information Server (IIS) [66] es el servidor Web (y FTP) estrella de Microsoft. La versión
4.0 está completamente integrada con el Windows NT Server 4.0 (hasta el punto de usar la misma
BBDDs del usuarios que maneja el sistema) y con todo un conjunto de tecnologías que se incluyen
en el Windows NT 4.0 Option Pack, entre ellas:

Microsoft Management console (MMC): permite la administración centralizada de todos los

componentes relacionados con el servidor.

Active Server Pages (ASP): lenguaje script que permite crear páginas HTML dinámicas.

Microsoft Data Access Components: diversos componentes para integrar la información

procedente de varias fuentes.
10 Un formato multimedia muy extendido propiedad de Macromedia.
16 CAPÍTULO 1. PANORÁMICA ACTUAL

Microsoft Transaction Server: provee un sistema de transacciones.

SMTP: implementación del protocolo de correo saliente.

...

En los nuevos Windows 2000, se incluye el IIS 5 que añade algunas mejoras como el soporte a
WebDAV (la base a los Web folders Microsoft), mayor velocidad de arranque y parada, etc.

IIS se ha hecho rápidamente con un importante sector del mercado (quizá por que se distribuye
como parte de los sistemas operativos Microsoft) y ha demostrado ser una solución muy cómoda
de instalar y configurar, capaz de funcionar a buen rendimiento.

Los principales problemas son la falta de una distribución para Unix (debido a que no sólo habría
que portar IIS, sino también el conjunto completo de tecnologías Microsoft con las que se integra),
los conocidos problemas de seguridad y su precio (desde 20.000 pts. aproximadamente11 ).

Para más información puede consultar la Web del fabricante http://www.microsoft.com/.

1.5.7 NCSA HTTPd

Aunque el desarrollo de NCSA HTTPd se detuvo en 1998, fue uno de los primeros servidores
Web de altas capacidades que se extendieron por Internet, y supuso la base para muchos productos
posteriores como Apache o Zeus.

NCSA HTTPd [79] tuvo un desarrollo muy dinámico y daba soporte inmediato a casi todas las
tecnologías relacionadas con la Web que iban apareciendo (HTTP/1.0, autentificación básica y
digest, CGI, etc.).

Es un servidor bastante confiable y eficiente, y podría utilizarse hoy en día12 , pero hay que tener
en cuenta que su desarrollo finalizó en 1998 y por tanto no da soporte a las nuevas tecnologías
como HTTP/1.1, SSL, ...

NCSA HTTPd es un producto gratuito cuya versión inicial trabajaba en entornos Unix/Linux,
aunque posteriormente fue portado al mundo Windows. Más información sobre este producto en
el sitio Web http://hoohoo.ncsa.uiuc.edu/.

1.5.8 Netscape-Sun iPlanet

iPlanet [50] es un servidor Web de altas prestaciones que ha surgido como fruto de la alianza entre
Netscape y Sun. Por un lado Netscape ha aportado su tecnología en servidores Web (derivada de
los Netscape Enterprise Web Servers) y Sun las implementaciones más actuales de su plataforma
J2EE (Servlets, JSP, una JVM nativa, JavaScript). Precisamente una de las mayores ventajas y a la
11 Es uno de los servidores comerciales más económicos, aunque para instalarlo también se necesita comprar todo el
resto de soluciones de Microsoft y esto aumenta el precio considerablemente.
12 De hecho según Netcraft aún existe una base importante de servidores usándolo (figura 1.3).
1.5. ALGUNOS EJEMPLOS DE SERVIDORES 17

vez desventajas de este producto es su soporte extremadamente actualizado de la plataforma J2EE.

En el lado positivo, iPlanet implementa todo lo último en Java, y en el lado negativo, el producto
está expuesto a los errores típicos de las primeras implementaciones.
Aparte del amplio soporte Java, iPlanet añade características avanzadas para manejo de datos,
por ejemplo “pooling” de conexiones, soporte a BLOBs (Binary Large Object), drivers nativos
para múltiples bases de datos (Oracle, Informix, DB2 y Sybase), o soporte LDAP (mediante el
producto iPlanet Directory Server). También soporta aplicaciones distribuidas mediante CORBA
y IIOP, junto con otra serie de características como balanceo de carga, rotación dinámica de logs,
...
Una vez instalado el producto, la configuración puede realizarse de una manera agradable
mediante una interface basada en Web y Java.
El servidor está disponible en diversas plataformas Windows y Unix, y pueden obtenerse licencias
desde 300.000 pts. por servidor aproximadamente. Más información en el sitio Web http:
//www.iplanet.com/.

1.5.9 Zeus

El servidor Zeus [133] es un servidor comercial, ofrecido por una compañía independiente
(Zeus Technology). Las primeras versiones estaban diseñadas para ofrecer una gran velocidad
de respuesta incluso ante grandes demandas de trabajo. En muchos aspectos mantenía la
compatibilidad con el servidor NCSA HTTPd, por ejemplo en la administración (soporta archivos
.htacess, etc.).
Las versiones posteriores siguen manejando eficientemente grandes volúmenes de trabajo, y
además añaden soporte a características avanzadas como clustering, escalabilidad en alojamiento
masivo de hosts virtuales, etc.
En el lado negativo, encontramos dos problemas: el precio (340.000 pts. aproximadamente), y su
disponibilidad sólo para plataformas Linux/Unix. Para más información puede dirigirse al sitio
Web de Zeus Technology http://www.zeustechnology.com/.

1.5.10 Tabla comparativa

A modo de resumen se incluye una pequeña comparativa (tabla 1.2) de disponibilidad y precio para
los servidores presentados en esta sección. Para un análisis en profundidad de otras características
(soporte de tecnologías, etc.) puede consultarse alguno de los sitios Web de la siguiente lista:

Server Compare: [113] http://webcompare.internet.com/.

Server Watch: [114] http://serverwatch.internet.com/.

Network World Inc: [82] http://www.nwfusion.com/.

18 CAPÍTULO 1. PANORÁMICA ACTUAL

Servidor Disponibilidad Precio

Apache Unix/Linux, Windows 95/98/NT/2000 Libre.
Bea Weblogic Windows NT, Sun Solaris, HP-UX, IBM AIX, Comercial,
Linux, OS/400, Compaq Tru64 Unix, SGI desde 2.000.000 pts.
IRIX y Siemens Reliant Unix aproximadamente.
Enhydra Windows NT/2000, Unix/Linux Libre.
Jigsaw Unix/Linux, Windows 95/98/Millenium y Libre.
NT/2000
Coldfusion Windows 95/98/NT/2000, Linux, Solaris y Comercial, desde
HP-UX 260.000 pts.
aproximadamente.
IIS Windows NT/2000 Comercial, desde
20.000 pts.
aproximadamente.
NCSA HTTPd Unix/Linux, Windows 3.x,NT Libre.
iPlanet HPUX, Solaris, IBM AIX, Compaq Tru64 Comercial, desde
Unix, SGI IRIX, Windows NT/2000 300.000pts
aproximadamente.
Zeus Unix/Linux Comercial, desde
340.000 pts.
aproximadamente.

Tabla 1.2: Breve tabla comparativa de servidores Web del mercado.

1.6 Conclusión

La competencia es feroz en el campo de los servidores Web y de aplicaciones. Muchas son las
similitudes y algunas las diferencias entre los distintos productos. Elegir no siempre es fácil,
se deben tener en cuenta cuestiones como precio, soporte técnico, implantación en el mercado,
soporte a características específicas, escalabilidad, extensibilidad, rapidez en paso a explotación,
etc.

Para la mayor parte de los casos Apache puede ser una buena elección: tiene un buen precio,
soporta prácticamente todas las características imaginables, es fácilmente extensible mediante
módulos, está muy implantado en el mercado, etc. Pero el tema es complejo y una empresa quizá
esté más interesada en aspectos como el soporte técnico o la rapidez de desarrollo de aplicaciones
y paso a explotación.
Capítulo 2

El protocolo HTTP

Contenidos de este capítulo

2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Comunicación HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1 Formato de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.2 Peticiones (Request) HTTP, métodos de petición . . . . . . . . . . . . 22
2.2.3 Respuestas (Response) HTTP, códigos de estado . . . . . . . . . . . . 24
2.2.4 Líneas de encabezado HTTP . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.5 Tipos MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.6 Esquema de una comunicación . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Características avanzadas del protocolo . . . . . . . . . . . . . . . . . . . . 30
2.3.1 Negociación de contenido . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.2 Conexiones persistentes (Keep-Alive) . . . . . . . . . . . . . . . . . . 31
2.3.3 Servidores virtuales (Virtual hosts) . . . . . . . . . . . . . . . . . . . . 31
2.3.4 Autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.5 Proxy-caché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 Mejoras del servicio ofrecido a través de HTTP . . . . . . . . . . . . . . . . 33

2.1 Introducción

HTTP (Hypertext Transfer Protocol o en español Protocolo de Transferencia de Hipertexto) es,

dicho de forma sencilla, el lenguaje de comunicación que se utiliza en la Web para que los
clientes y los servidores puedan entenderse entre sí. De manera un poco más formal, HTTP es un
protocolo a nivel de aplicación que se utiliza en sistemas de información hipermedia, colaborativos

19
20 CAPÍTULO 2. EL PROTOCOLO HTTP

y distribuidos. Sobre HTTP suelen distribuirse documentos con formato HTML, aunque es un
protocolo independiente y lo suficientemente genérico como para ser utilizado en tareas más allá
de la simple distribución de hipertexto1 , por medio de extensiones en sus cabeceras (headers),
métodos de petición (request methods) y códigos de error.

En las siguientes secciones se hace un breve repaso sobre este protocolo. Información adicional
tanto de HTTP como de cualquier especificación relacionada con el Web, puede encontrarse en el
sitio del Consorcio Web [127].

2.1.1 Historia

El protocolo HTTP ya ha pasado por varias etapas:

HTTP/0.9: primera versión. Definía un protocolo sencillo a nivel de aplicación para

distribución de datos a través de redes.

HTTP/1.0, definido en el RFC2 1945 [97]. La mejora más destacada fue el uso de cabeceras
(headers) con metainformación de los datos que se transmiten. HTTP/1.0 no constituyó
un estándar, simplemente fue considerado como RFC informativo, de todas maneras se
implementó en una gran cantidad de servidores Web. Los problemas de HTTP/1.0 dieron
lugar a la aparición de nuevos RFCs que intentaban solucionarlos:

– HTTP State Management Mechanism, propuesto en el RFC 2109 [98]: especifica la

forma de mantener sesiones por medio de cookies. Propone dos nuevas cabeceras
(Cookie y Set-Cookie) y define el método para utilizarlas.
– Use and Interpretation of HTTP Version Numbers, RFC 2145 [104]: aclara las
confusiones sobre la interpretación de los números de versión del protocolo HTTP
debidas a la ambigüedad de la especificación HTTP/1.0.
– HTTP Authentication: Basic and Digest Access Authentication, propuesto en el RFC
2617 [108]: propone un nuevo método de autentificación basado en compendios
(hash), llamado Digest Access Authentication, que mejora la seguridad del método
Basic Access Authentication definido en HTTP/1.0.

HTTP/1.1, fue definido en el RFC 2616 [107], integra en una sola especificación al
anterior HTTP/1.0 con los añadidos definidos en los RFCs 2109, 2145 y 2617 (indicados
anteriormente), además de otras mejoras. Las características más importantes de esta nueva
versión del protocolo son:

– Integración de conexiones persistentes (Keep-Alive) en el protocolo.

– Búsqueda de incremento en el desempeño. Definición de uso de proxies HTTP.
1 Como
por ejemplo SOAP, un sistema de objetos distribuidos.
2 Request
For Comments, o en español, petición de comentarios. Son documentos que hacen propuestas de interés
público. Muchos de ellos terminan siendo estándares.
2.1. INTRODUCCIÓN 21

– Soporte a host virtuales basados en nombre. Para ello se obliga a que las peticiones
HTTP/1.1 incluyan un nuevo campo de encabezado llamado Host.
– Negociación de contenido. Clientes y servidores pueden, mediante intercambio de
cabeceras, negociar características comunes. Cuando el servidor ofrece la información
en diversas representaciones, el cliente puede seleccionar la que más le interesa. El
ejemplo típico es tener un servidor con la información en varios idiomas y un cliente
solicita el contenido según su idioma de preferencia.
– Nuevos métodos de petición (OPTIONS, TRACE, DELETE, PUT, CONNECT).

Actualmente HTTP/1.1 es una especificación estable que consigue el objetivo de ser un estándar
que soluciona las debilidades de versiones anteriores. El W3C ha dado por cerrada la actividad
de desarrollo de este protocolo, sin embargo se siguen realizando esfuerzos en temas relacionados
con HTTP. Ejemplos de nuevas líneas de investigación son Jigsaw (vea la sección 1.5.4 en la
página 14) y nuevos protocolos que ligan el HTTP con XML como SOAP (vea la sección 6.4 en la
página 96).

2.1.2 Propiedades

Destacar:

Localización universal: El protocolo usa referencias dadas por URI3 (Universal Resource
Identifier). Una URI es una manera de identificar de forma única recursos, este concepto
esta definido en el RFC 2396 [105].

Arquitectura Cliente-Servidor: HTTP se basa en el paradigma petición/respuesta que define la

arquitectura cliente/servidor. Generalmente se apoya en TCP/IP (protocolos de transporte
y red de Internet)4 quedando los servidores a la escucha de peticiones en un puerto (por
defecto el 80). Un cliente es un programa que establece conexiones con el propósito
de enviar peticiones. Un servidor es una aplicación que acepta conexiones y atiende las
peticiones de servicio enviando mensajes de respuesta a las mismas.

Sin estado: de una petición a la siguiente no se conserva ningún tipo de información, cada
conexión es independiente y en principio no hay una memoria de conexiones del cliente.
Pero sólo en principio ya que se pueden utilizar trucos como las cookies5 o programas
externos CGI6 para implementar el concepto de sesión.

Representación de datos: HTTP usa tipos MIME (Multipart Internet Mail Extension) que
proporcionan una representación de los datos extensible y permiten que la comunicación
entre clientes y servidores esté abierta a negociación.
3 Posiblemente el tipo de URI más conocido sea el URL (Uniform Resource Locator) que identifica una localización.

También hay otras tipos como el URN (Uniform Resource Name) que identifica un nombre.
4 Pero también puede funcionar sobre otros protocolos confiables a nivel de transporte.
5 Sólo en las últimas versiones del protocolo y si los clientes las aceptan.
6 Que almacenen información de sesión en un fichero o BBDD.
22 CAPÍTULO 2. EL PROTOCOLO HTTP

2.2 Comunicación HTTP

2.2.1 Formato de mensajes

Cada transacción HTTP es una comunicación distinta. En cada una de ellas se intercambian
mensajes. Según la especificación del protocolo, un mensaje es “la unidad básica de la
comunicación HTTP y consiste de una secuencia estructurada de octetos ordenados con formato
válido y transmitidos por la conexión.”

Hay dos tipos de mensajes, petición o solicitud (Request) y respuesta (Response), cada uno con su
estructura, pero a groso modo el formato de un mensaje genérico sería el siguiente:

Línea de comienzo: tipo de petición o tipo de respuesta.

Cero o más líneas de encabezado acabadas en CRLF.

Separador, que no es más que otro CRLF.

Cuerpo del mensaje.

2.2.2 Peticiones (Request) HTTP, métodos de petición

Una petición HTTP, en su formato más básico, tiene la siguiente sintaxis:

método URI versión

El método le indica al servidor que hacer con el URI, por último la versión simplemente indica
el número de versión del protocolo que el cliente entiende. Una petición habitual utiliza el método
GET para pedirle al servidor que devuelva el URI solicitado:

GET /index.html HTTP/1.0

De entre los tres parámetros el más importante es el método. HTTP/1.1 incorpora ocho métodos
(tabla 2.1), aunque sólo obliga a implementar GET y HEAD, siendo todos los demás opcionales.
En cualquier caso, los servidores que implementen alguno de los métodos adicionales, deben
atenerse a la especificación de los mismos. Existe también la posibilidad de implementar métodos
extendidos, a los que la especificación no pone ningún límite.

En HTTP/1.0 sólo se especificaban tres métodos, GET, POST y HEAD. Estos son, con diferencia,
los tres más extendidos y utilizados, por ello se comentan un poco más ampliamente.
2.2. COMUNICACIÓN HTTP 23

Método Significado
GET Devuelve el recurso identificado en la URL pedida.
HEAD Funciona como el GET, pero sin que el servidor devuelva
el cuerpo del mensaje. Es decir, sólo se devuelve la
información de cabecera.
POST Indica al servidor que se prepare para recibir información
del cliente. Suele usarse para enviar información desde
formularios.
PUT Envía el recurso identificado en la URL desde el cliente
hacia el servidor.
OPTIONS Pide información sobre las características de
comunicación proporcionadas por el servidor. Le permite
al cliente negociar los parámetros de comunicación.
TRACE Inicia un ciclo de mensajes de petición. Se usa para
depuración y permite al cliente ver lo que el servidor
recibe en el otro lado.
DELETE Solicita al servidor que borre el recurso identificado con
el URL.
CONNECT Este método se reserva para uso con proxys. Permitirá
que un proxy pueda dinámicamente convertirse en un
túnel. Por ejemplo para comunicaciones con SSL.

Tabla 2.1: Métodos HTTP

El método GET

Se usa para pedir un documento específico, por ejemplo, cuando se sigue un enlace de una página
Web, se está usando el método GET.

La semántica de GET cambia a un GET condicional si el mensaje de petición incluye ciertos

campos de encabezado condicionales (como por ejemplo If-Modified-Since). Un GET
condicional pide que la fuente identificada sea transferida sólo bajo las circunstancias indicadas en
el campo de encabezado condicional. Intenta reducir el uso de la red permitiendo que las entidades
que están en caché sean refrescadas sin requerir la transferencia innecesaria de datos que no han
cambiado.

La semántica de GET cambia a un GET parcial si la petición incluye un campo de encabezado

Range. Un GET parcial pide sólo la parte de documento que realmente necesita. Intenta reducir
el uso de la red permitiendo que las entidades que están parcialmente en caché sean completadas
sin tener que ser completamente retransmitidas.

El método HEAD

Es un método utilizado para preguntar información sobre un documento (metadatos), no para

obtener el propio documento. HEAD es mucho más rápido que GET, ya que se transfiere mucha
24 CAPÍTULO 2. EL PROTOCOLO HTTP

menos información. Es generalmente usada por clientes que usan caché para ver si el documento
ha cambiado desde la última vez que accedieron a él. Si no cambió, la copia local puede usarse
nuevamente; de otra forma, la versión actualizada debe recuperarse con GET.

Este método puede ser usado para testear la validez, accesibilidad y reciente modificación de
enlaces, sin tener que descargar los documentos en sí.

El método POST

Es usado para transferir datos del cliente al servidor. Los datos del cuerpo de la solicitud se
enviarán al URI especificado. Este URI será una referencia a un manipulador que procesará los
datos de alguna forma, típicamente será un programa CGI.

Las respuestas al método POST no serán guardadas en caché salvo que en la propia respuesta se
incluyan encabezados de control de caché adecuados.

2.2.3 Respuestas (Response) HTTP, códigos de estado

La sintaxis de una respuesta HTTP es, en su formato más básico una línea de estado y tiene una
sintaxis como la siguiente:

versión código-error texto-explicativo

Incluye la versión de protocolo, un código de éxito o error y el texto explicativo al código anterior.
Un ejemplo bastante común es:

HTTP/1.1 200 Ok

Los posibles códigos de estado se identifican con números de tres cifras y se clasifican en cinco
grupos:

1. Números del estilo 1XX que representan mensajes de tipo informativo.

2. Números del estilo 2XX que indican que se completó satisfactoriamente la solicitud del
cliente.

3. Números del estilo 3XX que indican que la solicitud fue redirigida.

4. Números del estilo 4XX que indican un error en la solicitud del cliente.

5. Números del estilo 5XX que indican un error en el lado del servidor.

Pueden consultarse algunos códigos habituales en la tabla (tabla 2.2).

2.2. COMUNICACIÓN HTTP 25

Código Significado
200 OK La solicitud del cliente fue satisfactoria y el servidor ha
devuelto la información solicitada.
204 No Content El cuerpo de la respuesta no tiene contenido. Esto puede
indicar, por ejemplo, un problema con un CGI que no
devuelve datos.
301 Moved Permanently El URI solicitado no está disponible en el servidor. Ha
sido movido a otra ubicación. Las solicitudes futuras
deberán hacerse a esa ubicación.
400 Bad Request Hay un error de sintaxis en la solicitud del cliente. Por
ejemplo mandar una solicitud indicando que el cliente
soporta HTTP/1.1 y no enviar el encabezado de Host.
404 Not Found Este es junto con el 200 OK, el código más habitual.
Indica que el documento solicitado no está disponible,
probablemente el URI haya sido mal escrito.
500 Internal Server Error Este mensaje indica que algo ha ido mal en el servidor,
casi siempre tiene que ver con problemas en programas
CGI.

Tabla 2.2: Algunos códigos típicos de estado HTTP

2.2.4 Líneas de encabezado HTTP

Dentro de un mensaje HTTP los encabezados son muy importantes. Definen en gran parte la
información que se intercambia entre clientes y servidores dándole flexibilidad al protocolo. Estas
líneas permiten que se envíe información descriptiva en la propia transacción, permitiendo cosas
como la autenticación o identificación de usuarios.
La sintaxis de una línea simple de encabezado es la siguiente:

Nombre-de-Encabezado: Valor

Los encabezados pueden clasificarse en grupos, para cada uno de ellos se incluye una tabla con
los más importantes7 :

Generales: manejan información que puede ser utilizada tanto por clientes como por servidores,
ya que se aplican a una sesión completa de comunicación (tabla 2.3).

De solicitud: los utiliza el cliente para enviar (en sus peticiones de servicio) información
adicional al servidor (tabla 2.4).

De respuesta: los utiliza el servidor para enviar información adicional al cliente (tabla 2.5).

De entidad: contienen información relacionada directamente con el recurso que se le va a

proporcionar al cliente (tabla 2.6).
7 La especificación de HTTP utiliza 50 páginas para describir los encabezados. Si necesita más información puede

consultarla on-line [107]

26 CAPÍTULO 2. EL PROTOCOLO HTTP

Encabezado Significado
Cache-Control Permite especificar distintas directivas para controlar la caché, tanto
del cliente como de servidores proxy.
Connection Especifica opciones de la conexión de red.
Date Envía una fecha en la representación estándar definida en el
protocolo.
Pragma Transporta información no HTTP a un receptor que sea capaz de
entenderla.
Trailer Indica que ciertas cabeceras HTTP pueden encontrarse en el final de
un mensaje con múltiples partes (multipart).
Upgrade Información sobre protocolos adicionales soportados por el cliente.
Via Añadidos al mensaje de proxys o gateways para indicar que pasó por
ellos.
Warning Información adicional sobre un estado o transformación de un
documento que podría no estar reflejado en el cuerpo del mismo. Por
ejemplo, transformaciones que se hacen en servidores caché.

Tabla 2.3: Encabezados HTTP generales

Encabezado Significado
Accept Listado de tipos
MIME que el cliente soporta. Hay otros encabezados relacionados
como Accept-Charset, Accept-Encoding, Accept-Language.
Authorization Indica las credenciales de acceso a un recurso que presenta el usuario.
Expect Indica que comportamiento del servidor necesita el cliente.
From Dirección de correo que controla el cliente (navegador).
Host Nombre o IP del host desde donde se conecta el cliente.
If-Match Un cliente que tiene recursos en cache puede verificar si están
actualizados incluyendo este encabezado. Hay otros encabezados
que también tienen que ver con la caché. If-Modified-Since,
If-None-Match, If-Range, If-Unmodified-Since.
Max-Forwards Cuantas veces la petición del cliente puede ser reenviada por proxys.
Proxy- Indica las credenciales de acceso a un proxy que presenta el usuario.
Authoritation
Range Indica que porción de recurso (rango de bytes) recuperar.
Referer Es el URI del recurso desde donde la petición se ha realizado
(generalmente por provenir de un enlace HTML).
TE Que codificaciones de transferencia está dispuesto a recibir el cliente.
User-Agent Información sobre el agente de usuario (generalmente navegador)
que origina la petición.

Tabla 2.4: Encabezados HTTP de solicitud

2.2. COMUNICACIÓN HTTP 27

Encabezado Significado
Accept-Ranges Indica las unidades en las que el servidor acepta peticiones de rangos.
Age Tiempo estimado por el servidor para cumplir la petición.
Etag Valor actual de la etiqueta de entidad solicitada.
Location Contiene un URI al que el cliente debe ser redireccionado.
Proxy- Indica el esquema de autentificación que acepta un servidor proxy.
Authenticate
Retry-After Cuanto tiempo se espera que el servicio no esté disponible.
Server Información del software servidor.
Vary Indica que un recurso tiene múltiples fuentes que pueden variar de
acuerdo a la lista de encabezados de petición.
WWW- Indica que el recurso solicitado necesita de credenciales de
Authenticate autorización.

Tabla 2.5: Encabezados HTTP de respuesta

Encabezado Significado
Allow Informa al cliente de los métodos válidos asociados con el recurso.
Content-Type Indica el tipo MIME de los contenidos. Hay otros encabezados muy
relacionados
como Content-Language, Content-Length, Content-Location,
Content-MD5, Content-Range o Content-Encoding.
Expires Indica la fecha y hora en la que el recurso se considerará obsoleto.
Last-Modified Indica la fecha y hora en la que el recurso original fue modificado
por última vez.

Tabla 2.6: Encabezados HTTP de entidad

28 CAPÍTULO 2. EL PROTOCOLO HTTP

Nuevas extensiones: existe un grupo de trabajo que intenta estandarizar la forma en que las
nuevas extensiones al protocolo HTTP deben ser reflejadas en los encabezados HTTP.

2.2.5 Tipos MIME

Los tipos MIME (Multipart Internet Mail Extension) fueron definidos en los RFC 2045 [99],
2046 [100], 2047 [101], 2048 [102], 2049 [103] y otros. Son una forma abierta y extensible de
representar el contenido de los datos. Como su nombre indica fueron en un primer momento
utilizados para extender las características del correo electrónico, hoy su uso se ha generalizado
también puede llamárseles IMT (Internet Media Types).

Los MIME se componen de un tipo y un subtipo, como ejemplo, un archivo que es un documento
de texto y que ha sido escrito en HTML, tendrá como tipo MIME:

text/html

El registro de los tipos MIME los controla la IANA (Internet Asigned Numbers Authority) según
lo especificado en el RFC 2048 [102], y en su sitio Web podemos obtener la lista completa y
actualizada de los tipos registrados. Es importante el registro de tipos MIME, esto asegura que
dos tipos de contenido distintos no acaban con el mismo nombre. El prefijo especial x- queda
reservado para tipos experimentales (desplegados sin que haya terminado el proceso de registro)
o tipos de uso interno de organizaciones, por ejemplo:

image/x-fwf

El protocolo HTTP usa tipos MIME en sus encabezados, por ejemplo para:

Informar al cliente el tipo de datos que está recibiendo del servidor. Esto se hace con el
encabezado Content-Type. Por ejemplo, un navegador típico puede manejar los datos de
tres maneras distintas según el tipo MIME indicado en Content-Type:

1. Visualizar el documento, por ejemplo con tipos text/html.

2. Llamar a una aplicación externa, por ejemplo con tipos application/pdf.
3. O preguntarle al usuario que hacer ante un tipo que no se entiende, por ejemplo
image/x-fwf.

Permitir la negociación de contenido. El cliente, en su petición incluye los tipos MIME que
acepta. Por ejemplo, un navegador puede soportar documentos de tipo application/zip,
lo indicará con el encabezado HTTP:

Allow: application/zip
2.2. COMUNICACIÓN HTTP 29

Encapsular una o más entidades dentro del cuerpo de mensaje, mediante los tipos MIME
multipart (definidos en el RFC 2046 [100]). Quizá el ejemplo más conocido sea el tipo:

multipart/form-data

El tipo multipart/form-data ha sido definido en el RFC 1867 [96] para encapsular los
datos de un formulario en su envío hacia el servidor mediante el método POST.

2.2.6 Esquema de una comunicación

La estructura de un proceso de comunicación normal sigue los siguientes pasos:

1. Un programa cliente establece la conexión con un programa servidor Web.

2. El cliente envía una petición (vea la sección 2.2.2) indicando el método, URI a la que
pretende acceder y versión del protocolo. Además se pueden enviar diversos encabezados
HTTP (tabla 2.4). Un ejemplo simple de petición8 es el siguiente:

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

User-Agent: amano/1.0 [es]

3. El servidor responde con una línea de estado (vea la sección 2.2.3), que incluye la versión
de protocolo, un código de éxito o error y el texto explicativo al código. Además se
enviarán varios encabezados HTTP adicionales (tabla 2.5). Finalmente, dentro del cuerpo
del mensaje aparecerán los datos solicitados. Un ejemplo simple de respuesta es el siguiente:

HTTP/1.1 400 Bad Request

Date: Fri, 06 Jul 2001 18:26:55 GMT
Server: Apache/1.3.20 (Unix)
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

175
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
...

4. El programa servidor cierra la conexión.

Una forma de conocer más a fondo el esquema de comunicación es utilizar un cliente de telnet para
conectarse a un servidor HTTP y enviar “a mano” los comandos necesarios. El servidor responderá
en texto plano. Por ejemplo, desde un shell Linux puede teclearse: telnet localhost 80 para
comenzar la comunicación.
8 En una petición donde se usa el método es GET, el cuerpo del mensaje no se utiliza. Para otros métodos como

POST o PUT si será necesario.

30 CAPÍTULO 2. EL PROTOCOLO HTTP

2.3 Características avanzadas del protocolo

A continuación se analizan de una manera un poco más profunda una serie de características
avanzadas del protocolo HTTP:

Negociación de contenido.

Conexiones persistentes (Keep-Alive).

Servidores virtuales por nombre.

Autenticación.

Proxy-caché.

2.3.1 Negociación de contenido

La negociación de contenido provee el mecanismo para seleccionar la representación adecuada

cuando existen varias disponibles para un mismo recurso. Es un proceso en que el servidor intenta
responder a las preferencias del cliente de la manera más acertada.

Un recurso se define como una entidad que puede ser identificada por un URL. Suele ser un
fichero o directorio. Un recurso dado puede aparecer en varias representaciones o variantes.
Las diferentes representaciones suelen identificarse por la metainformación proporcionada por
los tipos MIME. Por ejemplo, un recurso fichero, puede tener varias representaciones9
fichero.html, fichero.pdf, ...

HTTP especifica tres formas de realizar la negociación de contenido:

Conducida por el servidor: la selección de la mejor representación la realiza un algoritmo

localizado en el servidor. Se puede elegir atendiendo a las distintas representaciones
disponibles (idioma, codificación del contenido, etc.) y a los diferentes parámetros
proporcionados por el cliente en el encabezado de la solicitud.

Conducida por el cliente: la selección de la mejor representación la realiza el cliente después

de recibir una respuesta inicial desde el servidor origen. Se elige en función de la lista de
representaciones incluida con esa primera respuesta. La selección la puede realizar el cliente
(navegador) por si mismo, o bien preguntándole al propio usuario.

Negociación transparente: es una forma que combina las dos anteriores. Ocurre cuando existe
una caché intermedia. Esta será capaz de usar la negociación dirigida por el cliente (siendo
la caché el cliente) hacia el servidor origen. A su vez actuará de cara al cliente realizando
una selección dirigida por el servidor (siendo la caché el servidor).
9 No es simplemente una negociación de formato, por que distintas representaciones pueden tener el mismo tipo

MIME. Por ejemplo cuando lo que se negocia es el lenguaje de la respuesta.

2.3. CARACTERÍSTICAS AVANZADAS DEL PROTOCOLO 31

2.3.2 Conexiones persistentes (Keep-Alive)

Antes de que esta característica existiese, se necesitaba una conexión TCP separada para cada
petición. Cuando un documento utilizaba enlaces a otros ficheros externos, la transmisión era
extremadamente ineficiente.

HTTP en su última versión, proporciona la posibilidad de establecer sesiones de mayor duración

de manera que se permiten múltiples peticiones sobre la misma conexión TCP. Esta característica
llega a proporcionar en algunos casos hasta un 50 por cien de mejora en los tiempos de latencia
entre documentos HTML. Los principales beneficios al usar conexiones persistentes son:

Se abren menos conexiones TCP, lo que ahora recursos (CPU, memoria, etc.).

Se pueden entubar (pipeline) peticiones y respuestas en una conexión. Esto permite al

cliente hacer múltiples peticiones sin esperar a las respuestas.

Se reduce la latencia en peticiones al utilizar varias veces un canal ya abierto.

Con los clientes que soportan HTTP/1.0, las conexiones Keep-Alive sólo pueden ser utilizadas
cuando son específicamente pedidas por el cliente, además están limitadas a documentos en los
que se conoce la longitud de antemano10 .

Para clientes con soporte a HTTP/1.1, las conexiones son persistentes por defecto y existen
métodos de envío de documentos de longitud no conocida.

2.3.3 Servidores virtuales (Virtual hosts)

El término servidor virtual (Virtual Host) hace referencia al hecho de simular más de un servidor
ejecutándose en una sola máquina. Pese a que en un mismo equipo estarán alojados diversos
servidores, cada uno de ellos será independiente y contendrá su propios recursos.

En las primeras versiones de HTTP cada host virtual necesita una dirección IP distinta, esta era
la única manera que permitía distinguir entre ellos. Esta dependencia de la disponibilidad de
direcciones IP puede limitar el número de servidores virtuales que se pueden ejecutar.

El protocolo HTTP/1.1 (y el HTTP/1.0 con extensiones) permite identificar el servidor al que se

quiere acceder por nombre (mediante la línea de cabecera Host). Este método tiene bastantes
ventajas:

Permite un número prácticamente ilimitado de servidores, sólo dependiente de los recursos

físicos de la máquina.

Es de fácil configuración y uso. Siempre es más cómodo usar nombres que números.

No requiere software ni hardware adicional.

10 Esto invalida el uso de Keep-Alive en documentos generados dinámicamente (SSI, CGI, etc.)
32 CAPÍTULO 2. EL PROTOCOLO HTTP

La principal desventaja es el soporte del protocolo por parte del cliente. Clientes antiguos, con
soporte al protocolo HTTP anterior a HTTP/1.0 pueden causar problemas.

2.3.4 Autenticación

HTTP/1.0 incluía una especificación de como implementar un esquema básico de autenticación de

acceso (Basic Access Authentication). Este método no se considera seguro para la autenticación
de usuario porque envía el nombre de usuario y la clave por la red en texto claro.

Existe otra posibilidad que se apoya en técnicas criptográficas. La autenticación de acceso por
medio de resumen (Digest Access Authentication) verifica que ambas partes de la comunicación
conocen una clave secreta compartida. Se basa en el paradigma de reto-respuesta y utiliza el
algoritmo MD5 para generar el resumen (hash). Al contrario que la comunicación básica, puede
ser utilizada sin enviar la clave en claro por la red.

Como muchos otros protocolos, la mayor fuente de problemas de seguridad no es el protocolo en

sí, sino las políticas que se establecen para su uso (cambio y distribución de claves por ejemplo).
De todas formas no se pretende que la autenticación de acceso por medio de resumen sea el
mecanismo de seguridad definitivo para la Web. Este esquema no proporciona encriptación del
contenido del mensaje. Está pensado simplemente para utilizar como un método de autenticación
que evite la mayor parte de los problemas de seguridad de la autenticación de acceso básica.

2.3.5 Proxy-caché

Proxy

Un servidor proxy actúa como intermediario entre clientes y servidores Web. Generalmente el
proxy suele ubicarse en una red local y se usa para controlar el tráfico hacia redes externas como
Internet. De esta manera un sólo equipo tiene acceso a la red externa y actúa como una versión
muy básica de cortafuegos (firewall) con varias utilidades:

Centralizar el acceso a una red pública (Internet) desde otra privada (Intranet).

Filtrar las URLs externas a las que tienen acceso los usuarios internos.

Ocultar información acerca de la red interna.

y también algunas desventajas:

Mayor vulnerabilidad a fallos, al estar todo el acceso centralizado en un sólo equipo. Puede
solucionarse añadiendo varios proxys.

Reducción de la velocidad de acceso, al tener que pasar todas las peticiones por un servidor
proxy intermedio.
2.4. MEJORAS DEL SERVICIO OFRECIDO A TRAVÉS DE HTTP 33

La especificación insta a que los desarrolladores de proxys HTTP pongan especial cuidado en la
implementación de las propiedades de la cabecera Connection y la característica Keep-Alive.

Caché

Un servidor caché aparte de funcionar como proxy, es capaz de almacenar copias de las URLs
que han pasado a través de él. Cuando una solicitud llega al servidor proxy, este consulta si
el documento seleccionado forma parte de su copia local, si es así lo devuelve. Esta forma de
funcionar incrementa drásticamente el rendimiento en el acceso a Internet. En Intranets de tamaño
medio/grande a veces también se utilizan jerarquías de servidores proxys-cachés, para incrementar
el rendimiento.

El principal problema del uso de cachés es la gran cantidad de contenidos que no son susceptibles
de ser almacenados. Por ejemplo: los recursos que dependen de cookies, de la negociación de
contenidos según preferencias de cliente, de la autenticación de usuario, etc.

El protocolo HTTP/1.1 incluye diversas características para optimizar el trabajo de las cachés.
Hay dos métodos básicos de control de caché:

Eliminar la necesidad de enviar peticiones mediante la cabecera Expiration.

Eliminar la necesidad de enviar peticiones completas a cada momento por medio de diversas
cabeceras para validar la caché (If-Range, If-Match, etc.)

2.4 Mejoras del servicio ofrecido a través de HTTP

Sobre el funcionamiento básico de HTTP que se ha definido en las secciones anteriores, han
surgido multitud de tecnologías. Estas permiten desde la gestión remota de recursos en el
servidor (WebDav) o el establecimiento de una plataforma de objetos distribuidos (SOAP), hasta
la generación de contenido dinámico. Algunas de ellas integran los últimos avances en campos
clásicos, por ejemplo pueden utilizar XML para la representación de datos o proporcionar acceso
cómodo a las bases de datos más potentes. Se analizarán estas nuevas posibilidades en capítulos
posteriores.
34 CAPÍTULO 2. EL PROTOCOLO HTTP
Capítulo 3

Ejecución de programas externos

Contenidos de este capítulo

3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1 La especificación CGI . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2 Datos de entrada al programa CGI . . . . . . . . . . . . . . . . . . . . 37
3.2.3 Proceso de los datos de entrada . . . . . . . . . . . . . . . . . . . . . 39
3.2.4 Datos de salida del script CGI . . . . . . . . . . . . . . . . . . . . . . 41
3.2.5 Un ejemplo de script muy simple . . . . . . . . . . . . . . . . . . . . 42
3.3 Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.2 Esquema de ejecución de un Servlet . . . . . . . . . . . . . . . . . . . 44
3.3.3 Resumen del API Java Servlet . . . . . . . . . . . . . . . . . . . . . . 45
3.3.4 Esquema general de un Servlet . . . . . . . . . . . . . . . . . . . . . . 45
3.3.5 Un ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4 Otras opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.1 Introducción

Una de las extensiones que más ha hecho avanzar al Web es la capacidad del servidor para
ejecutar programas externos. Con ello se gana en dinamismo, dando la posibilidad de crear
páginas interactivas según el contexto de cada petición. Un usuario puede introducir datos que
son añadidos a la petición, estos datos adicionales son recuperados por un programa externo que
creará la respuesta en función de ellos. Ejemplos en los que se necesita interactividad son:

Cuando la página Web debe estar basada en datos enviados por el usuario. El caso más
común son las páginas resultado de los motores de búsqueda.

35
36 CAPÍTULO 3. EJECUCIÓN DE PROGRAMAS EXTERNOS

Cuando los contenidos cambian frecuentemente. Como por ejemplo, páginas de periódicos
digitales, información del tiempo, ...

Cualquier página con acceso a bases de datos. El típico ejemplo, son las tiendas virtuales.

En este capítulo se comentan de manera concisa varias tecnologías que permiten la ejecución
de programas externos (CGI, Servlets, etc.). Las explicaciones se centran principalmente en la
especificación CGI, que fue la primera solución y es la más comúnmente implementada en los
servidores actuales.

3.2 CGI

3.2.1 La especificación CGI

La interface CGI [39] (Common Gateway Interface, o en español, Interface de pasarela común)
es la especificación de un protocolo que permite al servidor Web comunicarse con programas o
scripts1 externos.
Los programas CGI trabajan en el servidor Web y pueden implementarse utilizando diferentes
lenguajes de programación (COBOL, C, Perl, etc.) siempre y cuando respeten las convenciones
definidas en la especificación.

Figura 3.1: Arquitectura de la interface CGI.

Para que el usuario recupere un documento dinámico HTML a través de CGI, generalmente se
sigue la siguiente secuencia básica (figura 3.1).
1 Generalmente un programa es código compilado y un script interpretado. En esta memoria no se atiende a esta

diferencia y abusando del lenguaje se utilizan ambos términos con el mismo significado.
3.2. CGI 37

1. El usuario cumplimenta los campos de un formulario HTML2 y pulsa el botón de envío.

Antes de proceder al mismo, el navegador realiza algunos pasos:

(a) Determina el método HTTP para el envío3 según el valor del atributo del formulario
method.
(b) Identifica los campos del formulario.
(c) Construye el conjunto de datos como pares: nombre del control / valor asociado.
(d) El conjunto de datos se codifica según el valor seleccionado en el atributo del
formulario enctype.

2. El navegador realiza una solicitud HTTP al servidor Web, enviando el conjunto de datos del
formulario para que sea procesado por el programa especificado en el atributo del formulario
action.

3. El servidor recibe la solicitud y a partir de ella determina qué se le está pidiendo la

activación de un programa CGI. Se lanza un nuevo proceso CGI que recibe la información
necesaria para su ejecución.

4. El programa CGI se ejecuta procesando la información y devolviendo el resultado al

servidor Web.

5. El servidor recibe el resultado de proceso CGI y prepara una respuesta HTTP válida
(anexando alguna cabecera) que se le envía al cliente.

6. El navegador muestra el resultado recibido que contendrá información dependiente de lo

que el usuario introdujo en el formulario HTML.

3.2.2 Datos de entrada al programa CGI

El servidor Web se encarga de proporcionar varios datos de entrada al programa CGI, entre ellos:

La propia entrada que se incluye en la solicitud HTTP. Generalmente habrá sido introducida
desde formularios Web.

Una serie de datos específicos del servidor (nombre de servidor, etc.).

Algunos detalles sobre cómo el servidor Web transfiere los datos al programa CGI dependen de si
el navegador utiliza el método GET o POST:

1. GET: se transfiere la información a través de argumentos de la línea de órdenes o de la

variable de entorno QUERY_STRING.

2. POST: la información llega al CGI a través de la entrada estándar.

2 Más información sobre los formularios HTML en el apéndice (vea el apéndice A.3 en la página 362).
3 GET por defecto, pero también puede ser POST.
38 CAPÍTULO 3. EJECUCIÓN DE PROGRAMAS EXTERNOS

Método GET

Cuando se utiliza el método GET se pueden recibir los datos de entrada de dos formas:

A través de argumentos en la línea de órdenes. La petición será todo lo que sigue al signo
de interrogación en una URL. Por ejemplo para la siguiente URL:

http://www.ei.universidad.es/cgi-bin/test-cgi?uno+dos+tres

el servidor Web inicia el programa /cgi-bin/test-cgi con la línea de órdenes:

/cgi-bin/test-cgi uno dos tres

A través de la variable de entorno QUERY_STRING. Si la URL contiene un signo igual (=),

entonces el servidor Web no proporciona argumento alguno en la línea de órdenes. En
este caso, la solicitud entera se proporciona en la variable de entorno QUERY_STRING. Por
ejemplo con la siguiente URL:

http://www.ei.uvigo.es/cgi-bin/test-cgi?entrada=uno+dos+tres

el programa CGI podrá conocer sus datos de entrada consultando la variable QUERY_STRING:

QUERY_STRING:entrada=uno+dos+tres

El valor de la variable de entorno estará disponible durante todo el tiempo de vida del script
CGI.

Método POST

Cuando se utiliza el método POST en un formulario HTML, el servidor Web envía los datos a la
entrada estándar. En otras palabras, un programa CGI debe leer la entrada estándar (stdin) para
aceptar los datos enviados.

La variable de entorno CONTENT_LENGTH indica el número total de bytes a leer. El tipo MIME
en el que están codificados los datos de entrada estará almacenado en la variable de entorno
CONTENT_TYPE. A no ser que se especifique un método de codificación diferente a través de la
etiqueta <form enctype=”...” ...>, esta variable tendrá el valor application/x-www-form-
urlencoded.
3.2. CGI 39

Variables de entorno

Tanto si se usa el método GET como el POST, el servidor utiliza variables de entorno (tabla 3.1)
para transferir información útil al programa CGI. Una variable de entorno no es nada más que un
nombre asociado a una cadena. Por ejemplo, en un sistema UNIX, puede definirse una variable
EDITOR desde la línea de órdenes con:

EDITOR=/usr/local/bin/emacs

La cadena situada a la derecha del signo igual es el valor de la variable, el significado de la misma
depende del programa que la utiliza. Por ejemplo, y por convenio, la variable de entorno EDITOR
contiene la ruta hasta el editor de texto predeterminado.

Para ver el valor de una variable de entorno en una shell UNIX (el intérprete de órdenes de UNIX),
se puede usar el comando echo seguido del nombre de la variable con un símbolo del dólar ($)
prefijo. Así, para obtener el valor de la variable EDITOR, teclee el siguiente comando:

# echo $EDITOR
/usr/local/bin/emacs

Los programas CGI pueden obtener y establecer el valor de las variables de entorno a través de
ciertas funciones implementadas. Por lo tanto, este es un mecanismo apropiado para transferir
información entre el servidor Web y los programas CGI.

3.2.3 Proceso de los datos de entrada

Independientemente de la tarea que ejecute el programa CGI, la primera tarea a realizar suele
ser interpretar los datos que llegan codificados. Un script CGI recibe la información de manera
distinta dependiendo del método de la solicitud (GET o POST). Sabiendo esto se puede diseñar el
programa para que analice la entrada adecuadamente. Los pasos básicos serían los siguientes:

1. Comprobar la variable de entorno REQUEST_METHOD para determinar el método solicitado.

2. Si se trata del método GET, se usa el valor de la variable de entorno QUERY_STRING como
entrada. Se comprueba también cualquier nueva información sobre la ruta en la variable de
entorno PATH_INFO.

3. Si se trata del método POST, se obtiene la longitud de la entrada (en número de bytes)
a partir de la variable de entorno CONTENT_LENGTH. Después se lee ese número de bytes
desde de la entrada estándar.

4. Descodificar los datos de entrada4 :

4 Que vienen codificados por defecto como application/x-www-form-urlencoded.
40 CAPÍTULO 3. EJECUCIÓN DE PROGRAMAS EXTERNOS

Variable Descripción
AUTH_TYPE Nombre del método de verificación para validar el
usuario.
CONTENT_LENGTH Número de bytes de datos enviados (con el método
POST).
CONTENT_TYPE El tipo MIME en el que están codificados los datos de
entrada (con el método POST).
GATEWAY_INTERFACE Nombre y número de versión de la interfaz de pasarela
(normalmente CGI/1.1).
HTTP_ACCEPT Tipos MIME que acepta el navegador Web (como
image.gif, image/x-xbitmap, image/jpeg y */*).
HTTP_REFERER URL del documento desde el que parte la solicitud.
HTTP_USER_AGENT Nombre y número de versión del navegador Web que
realiza la solicitud.
PATH_INFO Cualquier otro nombre de ruta que sigue al nombre del
programa CGI en el URL.
PATH_TRANSLATED PATH_INFO anexado al directorio raíz del documento
del servidor.
QUERY_STRING Todo lo que sigue al signo de interrogación (?) en el URL
(así recibe el programa CGI los datos desde un formulario
HTML que utiliza el método GET).
REMOTE_ADDR Dirección IP del sistema desde el que parte la solicitud.
REMOTE_HOST Nombre del host del sistema que realiza la solicitud (este
es el sistema donde el usuario ejecuta el navegador Web).
REMOTE_USER Nombre de verificación del usuario (si el programa CGI
está protegido con una contraseña, éste es el nombre del
usuario con el que se accede al programa).
REQUEST_METHOD Método usado para la transmisión de datos (GET o
POST).
SCRIPT_NAME Ruta del script CGI que se ejecutará.
SERVER_NAME Nombre del host o dirección IP del sistema donde se
ejecuta el servidor Web.
SERVER_PORT Número de puerto en el que se recibe la solicitud (por
defecto 80).
SERVER_PROTOCOL Nombre y número de versión del protocolo usado para la
solicitud (por ejemplo, HTTP/1.0).
SERVER_SOFTWARE Nombre y número de versión del software del servidor
Web (como Apache/1.3.20).

Tabla 3.1: Variables de entorno CGI

3.2. CGI 41

(a) Extraer los pares nombre=valor dividiendo la entrada a la altura del signo &.

(b) En cada par nombre=valor, convertir todas las secuencias %xx en caracteres ASCII
(aquí, xx representa un par de dígitos hexadecimales).

(c) En cada par nombre=valor, convertir todos los signos más + en espacios.

5. Guardar los pares nombre=valor que representen valores de campos para su posterior uso.

Después de descodificar la entrada y encontrar los valores de todos los campos, ya se puede
trabajar con ellos para conseguir que el script CGI haga lo que debe.

3.2.4 Datos de salida del script CGI

Independientemente de cómo transfiere el servidor Web la información al script CGI, éste

siempre devuelve el resultado escribiendo en la salida estándar (stdout). Pero el script no puede
simplemente empezar devolviendo un documento HTML al servidor; debe también enviar alguna
información de encabezado. Tres de los posibles encabezados son:

Content-type: le indica al servidor el tipo MIME del contenido que se está devolviendo. Por
ejemplo, lo más habitual es devolver una página Web:

Content-type: text/html

Aunque también se puede devolver una imagen5 :

Content-type: image-gif

O cualquier otro tipo.

Location: se le indica al servidor que no debe devolver contenido, sólo hacer una solicitud
de redirección a otra URL. Por ejemplo:

Location: /novedades/index.htm

Status: le proporciona al servidor una línea de estado HTTP (vea la sección 2.2.3 en la
página 24) para que sea enviada al cliente:

Status: 403 Forbidden

5 Si se devuelven datos binarios (como una imagen GIF) desde un programa CGI, se debe incluir la cabecera

Content-length con el tamaño de los datos.

42 CAPÍTULO 3. EJECUCIÓN DE PROGRAMAS EXTERNOS

Es importante recordar que la última línea de un bloque de cabecera debe terminar con una línea
de espacios en blanco. Después de marcar el final de la cabecera puede empezar la salida del
programa CGI. El servidor acepta la salida del script, anexa algunos encabezados HTTP, y envía
el resultado al navegador.

Por convenio a todo script cuyo nombre empiece por nph se le permite comunicarse directamente
con el cliente (los encabezados HTTP que produce no los analiza ni cambia el servidor). Este tipo
de scripts permiten que el servidor vaya enviando datos al cliente según el CGI los va escribiendo
en la salida estándar. Los scripts no nph usan una memoria intermedia en su paso de datos al
servidor, de manera que hasta que no acaba el proceso del script, el servidor no envía resultado
alguno.

3.2.5 Un ejemplo de script muy simple

Por ejemplo en un sistema que ejecute un servidor Apache, existen algunos scripts de prueba que
permiten observar las variables de entorno. A continuación se muestra uno de ellos codificado en
el propio lenguaje shell de Unix. El listado, aunque corto, conforma un script CGI completo que
mantiene la estructura básica mínima:

#!/bin/sh

# disable filename globbing

set -f

echo Content-type: text/plain

echo

echo CGI/1.0 test script report:

echo

echo argc is $#. argv is "$*".

echo

echo SERVER_SOFTWARE = $SERVER_SOFTWARE

echo SERVER_NAME = $SERVER_NAME
echo GATEWAY_INTERFACE = $GATEWAY_INTERFACE
echo SERVER_PROTOCOL = $SERVER_PROTOCOL
echo SERVER_PORT = $SERVER_PORT
echo REQUEST_METHOD = $REQUEST_METHOD
echo HTTP_ACCEPT = "$HTTP_ACCEPT"
echo PATH_INFO = "$PATH_INFO"
3.3. SERVLETS 43

echo PATH_TRANSLATED = "$PATH_TRANSLATED"

echo SCRIPT_NAME = "$SCRIPT_NAME"
echo QUERY_STRING = "$QUERY_STRING"
echo REMOTE_HOST = $REMOTE_HOST
echo REMOTE_ADDR = $REMOTE_ADDR
echo REMOTE_USER = $REMOTE_USER
echo AUTH_TYPE = $AUTH_TYPE
echo CONTENT_TYPE = $CONTENT_TYPE
echo CONTENT_LENGTH = $CONTENT_LENGTH

Listado 3.1 Un script de prueba de CGI. test-cgi.

3.3 Servlets

3.3.1 Introducción

Los Servlets son pequeños programas Java que producen como salida contenido para la Web.
Son la respuesta de la tecnología Java a los problemas de la programación CGI. Se enumeran a
continuación las soluciones aportadas por los Servlets frente a los CGIs:

Eficiencia: un CGI tradicional, se arranca como un nuevo proceso para cada solicitud HTTP.
Esta sobrecarga puede ser inaceptable cuando el script CGI se ejecuta frecuentemente. Con
los Servlets, la máquina Virtual Java (JVM) permanece corriendo concurrentemente con el
servidor Web, y es capaz de manejar cada nueva petición con un hilo (thread) Java. Los hilos
tienen peso ligero6 , frente a los pesados procesos del sistema operativo como por ejemplo
los scripts CGI.
Para aclarar el concepto, puede pensarse en que pasaría si en un momento se tienen varias
peticiones (por ejemplo X) simultáneas para el mismo programa CGI. En este caso el código
del script se cargará X veces en memoria. Sin embargo, con los Servlets, habrá X threads
pero sólo una copia de la clase Servlet.

Portable: al estar escritos en Java, los Servlets siguen un API bien estandarizado. Un
Servlet debería ser capaz de funcionar de la misma manera en diferentes plataformas
hardware/software (por ejemplo un Servlet que corre en una plataforma Microsoft Windows
2000 con Internet Information Server, debe funcionar exactamente igual en un Linux con
Apache + Tomcat). Los Servlets son soportados por la mayoría de los servidores Web, bien
directamente (por ejemplo Jigsaw) o mediante un módulo adicional (por ejemplo Apache).
La portabilidad de programas CGI, aunque posible, es menos evidente.
6 EL termino “peso” se asocia con la sobrecarga que se provoca en el sistema.
44 CAPÍTULO 3. EJECUCIÓN DE PROGRAMAS EXTERNOS

Conveniencia: los Servlets tienen una gran infraestructura apoyada en la estrategia comercial de
Sun. Existen multitud de clases ya implementadas (decodificación de datos de formularios
HTML, manejo de cabeceras HTTP, cookies, sesiones, etc.). Aunque existen librerías para
hacer todas estas cosas en la mayoría de los lenguajes habituales para manejo de CGIs, su
forma de uso, en muchos casos, no es tan fácil.

Potencia: los Servlets Java permiten hacer muchas cosas que son más difíciles con CGIs
normales. Por ejemplo pueden compartir datos entre ellos (cada petición es un hilo Java,
y todos ellos tienen el mismo “padre”), simplificar el seguimiento de sesiones, utilizar
automáticamente una caché de cálculos anteriores, ...

3.3.2 Esquema de ejecución de un Servlet

Los Servlets se ejecutan dentro de un contenedor de Servlets (Servlets container), que no es más
que una JVM (Java Virtual Machine) que funciona complementando al servidor Web (figura 3.2).

Figura 3.2: Esquema de ejecución Servlet

El funcionamiento podría resumirse como:

1. Al igual que en scripts CGI, el usuario cumplimenta los campos de un formulario HTML y
pulsa el botón de envío. El navegador prepara los datos para su envío y con ellos realiza una
solicitud HTTP al servidor Web.
3.3. SERVLETS 45

2. El servidor recibe la solicitud y a partir de ella determina qué se le está pidiendo la

activación de un Servlet. El contenedor Servlet está ejecutándose al mismo tiempo que el
servidor Web. Se lanza un nuevo hilo en el contenedor que recibe la información necesaria
para su ejecución.

3. El Servlet se ejecuta y genera una respuesta que es enviada de nuevo al servidor Web (el
hilo muere).

4. El servidor recibe el resultado del Servlet y se encarga de enviar la respuesta, para ello
prepara una respuesta HTTP válida (anexando alguna cabecera) que será lo que se envía al
cliente.

5. El navegador muestra el resultado recibido.

3.3.3 Resumen del API Java Servlet

El API propuesta por SUN para su tecnología de Servlets es muy amplia, en esta sección se tratan
de resumir las características principales de la última versión (API Java Servlet 2.2) [23]:

Administración de sesiones y aplicaciones. Un Servlet es capaz de almacenar datos durante

la vida de una sesión o aplicación.

Utilidades HTTP. Por ejemplo acceso a cookies, encabezados HTTP, codificación /

decodificación de caracteres, traducción de rutas, ...

Soporte para subprocesos múltiples.

Empaquetado y seguridad a nivel de aplicación. Se han añadido estas características para

fomentar el uso de Servlets de manera segura en entornos multiusuario (por ejemplo en el
servidor de un ISP7 ).

Soporte a programación distribuida, que proporciona la posibilidad de desarrollar

aplicaciones que residen en varias máquinas, dotando a los productos de una característica
muy deseable en la Internet actual, la escalabilidad.

3.3.4 Esquema general de un Servlet

En esta sección se presenta y comenta la estructura básica de un Servlet. Un análisis detallado

queda fuera del alcance de este proyecto8 .

import java.io.*;
import javax.servlet.*;
7 Internet Service Provider, o en español, Proveedor de servicios Internet.
8 Existen muchos buenos libros sobre el tema [5] [2]
46 CAPÍTULO 3. EJECUCIÓN DE PROGRAMAS EXTERNOS

import javax.servlet.http.*;

public class SomeServlet extends HttpServlet {

public void doGet(HttpServletRequest request,

HttpServletResponse response)
throws ServletException, IOException {

// "request" es un objeto que maneja la entrada

// "response" es un objeto que maneja la salida

PrintWriter out = response.getWriter();

// "out" puede utilizarse para enviar salida al navegador

out.println("...");
}
}

Listado 3.2 Estructura de un Servlet básico.

En cualquier programa en Java se deben importar las clases necesarias. En un Servlet como
mínimo se utilizan los siguientes paquetes:

java.io para PrintWriter, ...

javax.servlet para HttpServlet, ...

javax.servlet.http para HttpServletRequest y HttpServletResponse.

Cualquier Servlet debería extender la clase HttpServlet y sobreescribir los métodos doGet y/o
doPost, dependiendo de si los datos están siendo enviados mediante GET y/o POST. Además
estos métodos lanzan excepciones y es necesario incluirlas en la declaración. doGet y doPost
toman dos argumentos:

HttpServletRequest tiene métodos que permiten acceder a información entrante (datos

de un formulario, cabeceras de petición HTTP, etc.).

HttpServletResponse tiene métodos que permiten especificar líneas de respuesta HTTP

(200, 404, etc.), cabeceras de respuesta ( Content-Type, etc.), y sobre todo permiten utilizar
un PrintWriter para enviar el contenido de la salida al cliente.

Un último comentario, en un Servlet sencillo casi todo el contenido son sentencias println que
generan la página deseada.
3.3. SERVLETS 47

3.3.5 Un ejemplo

¿Cuáles son los pasos necesarios para poner un Servlet en explotación?. Se enumeran basándose
en un Servlet de ejemplo que procesa peticiones GET para leer y mostrar los datos de un
formulario9 :

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class Formulario extends HttpServlet {

public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException{
response.setContentType("text/html");
PrintWriter out = response.getWriter();

// Comienzo de salida HTML

out.println("<html><head>");

String title = "Datos del formulario";

out.println("<title>" + title + "</title>");

out.println("</head>");
out.println("<body bgcolor=\"white\">");
out.println("<h1>" + title + "</h1>");

// Obtener y presentar datos de formulario

out.println("<p>Su número de tarjeta es:");
out.println(request.getParameter("ntarjeta"));
out.println("<p>Su banco es:");
out.println(request.getParameter("banco"));

out.println("</body></html>");
}
}

Listado 3.3 Recuperar y presentar los datos de un formulario con un Servlet. Formulario.java.

9 Las peticiones GET son las más habituales que recibe el servidor (cuando se escribe una URL en la línea de

direcciones, se sigue un enlace, o se rellena un formulario que no especifica un METHOD).

48 CAPÍTULO 3. EJECUCIÓN DE PROGRAMAS EXTERNOS

Al igual que un programa CGI, una de las primeras cosas que debe hacer un Servlet es descodificar
los datos de entrada. La clase request proporciona el método getParameter para obtener los
valores de los campos de un formulario. A modo de ejemplo se utiliza el siguiente formulario:

<HTML>
<HEAD>
<TITLE>Un formulario simple</TITLE>
</HEAD>
<BODY>

<FORM ACTION="/examples/servlet/Formulario">
N tarjeta: <INPUT TYPE="TEXT" NAME="ntarjeta"><BR>
Banco: <INPUT TYPE="TEXT" NAME="banco">
<INPUT TYPE="SUBMIT" VALUE="Enviar" NAME="Enviar">
</FORM>

</BODY>
</HTML>

Listado 3.4 El formulario de entrada: formulario.htm.

Para ofrecer la salida en HTML el Servlet debe además incluir código para:

Informar al navegador de que le está devolviendo código HTML. Se usa un método especial
setContentType para este propósito.

Incluir sentencias println para construir una página Web.

3.4 Otras opciones

CGI es la interface estándar que permite la ejecución de programas externos, prácticamente todos
los servidores del mercado lo soportan. El principal problema es la eficiencia, un CGI tradicional
se arranca como un nuevo proceso (con toda su sobrecarga asociada) para cada solicitud HTTP.
Los Servlets, discutidos en la sección anterior, son quizá la solución más utilizada hoy en día,
aunque no es la única. A continuación se enumeran otras posibilidades:

FastCGI: [41] es una extensión al CGI independiente del lenguaje y escalable que proporciona
un mejor rendimiento. Básicamente FastCGI permite que un programa CGI ligeramente
modificado se cargue una sola vez y permanezca residente en memoria para atender a las
siguientes peticiones.
3.4. OTRAS OPCIONES 49

Existen implementaciones disponibles para los principales servidores Web del mercado
(Apache, Netscape, IIS, Zeus) y bibliotecas para su utilización con los principales lenguajes
(C, C++, Perl, Java, Python, etc.). Más información en http://www.fastcgi.com.

ISAPI/NSAPI: [64] [80] son APIs propietarias que se proponen como alternativas de ejecución
más rápida que CGI. Permiten la creación de módulos binarios que son cargados
dinámicamente por el servidor Web cuando se inicia, se mantienen residentes en memoria y
no provocan la sobrecarga de iniciar procesos separados.
ISAPI se incluyen en los servidores de Microsoft (IIS, etc.). Los programas escritos usando
la interfaz ISAPI son compilados como bibliotecas DLL (Dynamic Link Library). Más
información en http://www.microsoft.com.
NSAPI es la API propuesta por Netscape para extender la funcionalidad de sus servidores.
Más información en http://www.netscape.com.

mod_perl: [86] la ejecución de scripts Perl es lenta, tanto por ser un lenguaje interpretado como
por la necesidad de arrancar un proceso nuevo para cada petición. mod_perl es un módulo
de Apache que elimina estos problemas, para ello:

Enlaza las bibliotecas de ejecución de Perl dentro del servidor Web, dándole a cada
instancia de Apache su propio intérprete Perl. De esta manera se elimina la necesidad
de lanzar un nuevo interprete para cada petición, por que se tiene uno ejecutándose
permanentemente con el propio servidor.

Mediante Apache::Registry (una parte de mod_perl)se ofrece la posibilidad de que

los scripts Perl sean compilados en bytecodes (al estilo Java), lo que incrementa aún
más el rendimiento.

mod_perl sólo está disponible para Apache y puede obtenerse su código fuente en cualquier
mirror del CPAN, por ejemplo http://www.perl.com/CPAN/modules/by-module/
CPAN/.
50 CAPÍTULO 3. EJECUCIÓN DE PROGRAMAS EXTERNOS
Capítulo 4

Código embebido en HTML

Contenidos de este capítulo

4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.2 XSSI de Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.3 Hotwired XSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.4 JSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.5 Un ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3 JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.2 El lenguaje JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.3 Un ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.4 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4.2 El lenguaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.4.3 Potencia de PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.4.4 Un ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5 ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.5.2 Componentes ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.5.3 Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.5.4 Un ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.6 Otras posibilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.7 Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

51
52 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

4.1 Introducción

La aproximación basada en código embebido [44] se diferencia claramente de la ejecución de

programas externos que se trata en el capítulo anterior. En vez de escribir un programa con
diversos comandos para crear una salida en HTML, se escribe HTML con código embebido1
(introducido entre etiquetas especiales) que producirá alguna salida.
Los lenguajes de código embebido implementan un conjunto de directivas que pueden aparecer
incluidas en páginas HTML y que son evaluadas antes de que esa página sea servida. El resultado
de esta evaluación (tan simple como el valor de una variable de entorno, o tan compleja como el
resultado de una consulta a una base de datos) reemplaza el código embebido en el documento
HTML antes de que sea enviada la respuesta al usuario. Esta técnica permite conseguir un
contenido dinámico independientemente de las características del navegador (como por ejemplo
soporte a Javascript).

Figura 4.1: Esquema general para un lenguaje de código embebido en HTML.

Todas las aproximaciones al código embebido funcionan de manera similar (figura 4.1):

1. El navegador envía una solicitud HTTP al servidor.

2. El servidor se da cuenta de que el recurso solicitado es una página con código embebido,
por lo que le transfiere el control al manejador correspondiente, enviándole el archivo con
etiquetas embebidas necesario.
1 Escrito en algún lenguaje que no es HTML. Existen múltiples posibilidades Java, Perl, PHP, etc.
4.2. SSI 53

3. El manejador recibe la petición, compila (ASP, JSP, PHP, etc.) o interpreta (SSI, PHP, etc.)
el código, y devuelve el resultado.

4. El resultado en HTML es recibido por el servidor Web que finalmente se encargará de

crear una respuesta HTTP válida y enviársela al cliente.

5. El cliente recibe la respuesta y presenta el código HTML.

Las alternativas de código embebido que se discuten en este capítulo, son ejecutadas en el servidor.
Un cliente solamente recibe el resultado de esta ejecución, sin tener la posibilidad de determinar
que código lo ha producido.

También existen algunas alternativas de código embebido en el lado cliente, la más conocida es
Client Side Javascript [80], pero queda fuera del alcance del proyecto. Si necesita más información
sobre este tema puede visitar la página de manuales de Netscape http://developer.netscape.
com/docs/manuals/.

4.2 SSI

4.2.1 Introducción

SSI (Server Side Includes) es la opción más básica para usar código embebido y ofrece un modo
sencillo de obtener contenido dinámico en la Web.

Para funciones simples como incluir fechas de actualización de documentos, SSI es probablemente
la opción más eficiente; de todas formas no es lo suficientemente potente para reemplazar
un lenguaje de programación, que puede ofrecer características avanzadas como por ejemplo
funciones de acceso a BBDD.

La implementación inicial de SSI se hizo en el servidor NCSA HTTPd, que definía directivas con
la siguiente sintaxis:

<!--#elemento atributo="valor" atributo="valor" ... -->

Se puede observar que no son más que comentarios HTML, de forma que si por algún motivo
falla el parser2 SSI, el cliente las ignora. Casi todas las directivas tienen al menos un par
atributo=”valor”, si bien en algunas no es necesario. Hay que tener en cuenta dos consideraciones
importantes para no dar lugar a posibles confusiones del parser:

En un par atributo="valor", el valor debe ir siempre entre comillas.

El comentario de terminación --> debe ser precedido por un espacio en blanco.

2 Analizador sintáctico.
54 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

Hoy en día existen varias implementaciones de directivas SSI, entre ellas:

XSSI (eXtended Server Side Includes) de Apache: se puede decir que es la implementación
estándar de facto.

Hotwired XSSI: una ampliación de la anterior.

JSSI (Java Server Side Includes): una implementación en Java.

4.2.2 XSSI de Apache

XSSI (eXtended Server Side Includes) implementa las directivas básicas que ya tenía el servidor
NCSA HTTPd (config, include, echo, fsize, flastmod, exec), así como algunas características
añadidas. A continuación se realiza una descripción de las mismas.

Directivas básicas

La directiva <!--#config -->: Controla distintos aspectos del "parsing". Acepta tres posibles
atributos:

errmsg: el valor es el mensaje que se enviará como resultado si al procesar una directiva,
esta devuelve un error. Por ejemplo cuando se quiere incluir un fichero que no está en el
lugar indicado se produce un error.

sizefmt: el valor configura el formato en el que se muestra el tamaño de los ficheros, y será
uno de estos tres (bytes|Kb|Mb). Esta configuración sólo tiene efecto en la directiva <!-
-#fsize -->.

timefmt: el valor es una cadena de formato (al estilo de la función C strftime()) utilizada
al mostrar fechas y horas.

Ejemplo: Personalizar el mensaje de error, indicar que los tamaños de los ficheros deben aparecer
en KiloBytes y definir un formato de fechas del estilo día/mes/año - hora:minuto:segundo:

<!--#config errmsg="Error en el parsing de directiva SSI" -->

<!--#config sizefmt="Kb" -->
<!--#config timefmt="%d/%m/%y - %H:%M:%S" -->

La directiva <!--#echo -->: Imprime el valor de alguna de las variables de entorno. Si la

variable no está asignada se muestra como none. Los posibles atributos son:

var: el valor es el nombre de la variable de entorno a mostrar. Se puede acceder tanto a

variables CGI (tabla 3.1), como a otras variables específicamente definidas por SSI (tabla
4.1).
4.2. SSI 55

Variable Contenido
DATE_GMT Fecha actual del sistema según el meridiano de Greenwich.
DATE_LOCAL Fecha actual del sistema en tiempo local.
DOCUMENT_NAME Nombre del fichero SSI pedido por el usuario.
DOCUMENT_URI Camino URL del documento pedido por el usuario.
LAST_MODIFIED Última fecha de modificación del documento SSI pedido por el
usuario.

Tabla 4.1: Variables específicas de SSI

encoding: especifica como se deben codificar los caracteres especiales contenidos en la

variable antes de proceder a mostrarlos. Por defecto se asume entity, aunque se puede
elegir también none o url.

Ejemplo: Presentar la fecha y hora local.

<!--#echo var="DATE_LOCAL" -->

La directiva <!--#exec -->: Esta directiva permite realizar llamadas a un comando de shell o a
un programa CGI. Es potencialmente peligrosa y puede deshabilitarse completamente utilizando
la opción Option IncludesNOEXEC dentro de la configuración de Apache. Sus atributos válidos
son:

cgi: el valor especifica una URL relativa a la ruta de los scripts CGI (si comienza con /), o
bien relativa al documento actual (si no comienza con /). Si el script devuelve una cabecera
Location esta es traducida a un enlace HTML.
Existe un posible riesgo de seguridad, sería posible que ejecutar ficheros CGI que en realidad
no deberían tener permiso.3

cmd: el valor será el comando que se ejecutará a través del shell.

Ejemplo: Ejecuta un comando de shell que devuelve información sobre la máquina actual.

<!--#exec cmd="uname -m -r -s" -->

La directiva <!--#fsize -->: Inserta el tamaño4 de un determinado documento dentro de la

página. Los atributos soportados son:

file: el valor es la ruta relativa desde el documento actual hasta el fichero (no se admite ../).
3 Se aconseja usar <!--#include virtual="..."--> en vez de <!--#exec cgi="..."-->, para asegurar que sólo se ejecutan
scripts CGI estándar a los que se puede acceder desde una URL aceptada por Apache.
4 Este parámetro está sujeto a la configuración dada por la directiva <!--#config sizefmt="..."-->
56 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

virtual: el valor será la ruta URL.

Ejemplo: Muestra el tamaño de varios ficheros.

<!--#fsize virtual="/manual/bind.html" -->

<!--#fsize virtual="/manual/dso.html" -->

La directiva <!--#flastmod -->: Imprime la fecha de última modificación de un documento5 .

Los atributos soportados son:

file: el valor es la ruta desde el documento actual hasta el fichero (no se admite ../).

virtual: el valor será la ruta URL.

Ejemplo: Muestra la fecha de última modificación de varios ficheros.

<!--#flastmod virtual="/manual/bind.html" -->

<!--#flastmod virtual="/manual/dso.html" -->

La directiva <!--#include -->: Esta directiva inserta el texto de otro fichero (o el resultado de
la ejecución de un programa) en el documento que está siendo analizado. Los ficheros incluidos
están sujetos a las restricciones de acceso habituales (por ejemplo con la directiva de Apache
Option IncludesNOEXEC).
Una característica importante es que se permite anidamiento, es decir, un fichero SSI puede incluir
otro fichero con directivas SSI y así sucesivamente. Dos son los atributos posibles:

file: el valor es la ruta relativa al directorio que contiene el documento que se está analizando
actualmente. No es posible acceder a rutas que comiencen por “/” o por “../”

virtual: el valor es una URL relativa al documento que está siendo analizado. Esta URL no
puede contener nada más que un camino (ni protocolo “http://, etc.”, ni nombres de host) y
opcionalmente un QUERY_STRING (si comienza con “/” será relativo al DocumentRoot).
Este es el modo preferido de utilizar la directiva <!--#include -->, ya que hacen el código
lo más independiente de la plataforma posible al usar URLs y no rutas.

<!--#include virtual="..."--> es la manera recomendada de incluir los resultados de un

programa CGI. Tiene algunas ventajas sobre <!--#exec cgi="..."-->. Por ejemplo, ofrece la
posibilidad de modificar la cadena de entrada al CGI añadiendo al URL un QUERY_STRING.
Ejemplo: Preparar un modelo de página. Quizá esta es una de las aplicaciones más utilizadas, la
versión más simple se basaría en incluir ficheros de encabezado y pie de página.

<!--#include virtual="/prueba_ssi/cabecera.shtml" -->

...
<!--#include virtual="/prueba_ssi/pie.shtml" -->
5 Esta directiva está sujeta al formato especificado en <!--#config timefmt="..."-->.
4.2. SSI 57

La directiva <!--#printenv -->: Imprime el resultado de todas las variables de entorno

existentes y sus valores, los caracteres especiales son codificados como entidades HTML (entity
encoded) antes de proceder a su impresión. Esta directiva no tiene atributos.

Ejemplo:

<!--#printenv -->

La directiva <!--#set -->: Establece el valor de una variable, creándola si no existe. Sus
atributos son:

var: donde se indica el nombre de la variable a establecer.

value: el valor de la variable indicada.

Ejemplo: Establecer dos variables.

<!--#set var="local" value="puede subir archivos" -->

<!--#set var="externo" value="no puede subir archivos" -->

Sustitución de variables

La sustitución de variables se hace entre cadenas entrecomilladas, en la mayoría de los casos

ocurrirá como argumento de una directiva o una expresión condicional SSI. Para poder usar el
valor de las variables se debe preceder su nombre del símbolo $. También puede ocurrir que una
referencia a variable necesite ser sustituida en el medio de una cadena de caracteres de forma que
se pueda dar lugar a confusión. Esta ambigüedad se supera utilizando llaves {}.

Flujo de control

SSI implementa una forma muy básica de flujo de control, la sintaxis de la única expresión
permitida es:

<!--#if expr="condición_test" -->

<!--#elif expr="condición_test" -->
<!--#else -->
<!--#endif -->

El elemento if funciona igual que lo haría en cualquier lenguaje de programación, la

condición_test es evaluada, se permiten varias operaciones de comparación (tabla 4.2). Si
el resultado es verdadero se procesa hasta el siguiente else, elif o endif. Las instrucciones
else y elif, son opcionales y caso de que aparezcan serán procesadas cuando el resultado de la
condición sea falso. El elemento endif marca la finalización del if.
58 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

Sintaxis Semántica
string Verdadero si la cadena no está vacía.
string1 = string2 Verdadero si las cadenas son iguales.
string1 != string2 Verdadero si las cadenas son distintas.
string1 < string2 Verdadero si string1 es alfabéticamente menor que
string2.
string1 <= string2 Verdadero si string1 es alfabéticamente menor o
igual que string2.
string1 > string2 Verdadero si string1 es alfabéticamente mayor que
string2.
string1 >= string2 Verdadero si string1 es alfabéticamente mayor o
igual que string2.
condición1 && condición2 AND lógico, verdadero si ambas condiciones son
ciertas.
condición1 || condición2 OR lógico, verdadero si alguna condición es cierta.

Tabla 4.2: Condiciones de test SSI

Las condiciones de test son casi siempre operaciones de comparación sobre cadenas, aunque si la
string2 tiene la forma /string/ entonces es comparada como una expresión regular al estilo del
comando egrep de Unix (vea el apéndice C en la página 373).

Ejemplo: Testear la variable de entorno que se refiere a la dirección del remitente y según el
resultado mostrar un texto y el valor de una variable definida anteriormente.

<!--#if expr="$REMOTE_ADDR=127.0.0.1" -->

Se esta conectando desde el propio servidor,
<!--#echo var="local" -->
<!--#else -->
Se esta conectando desde un cliente externo,
<!--#echo var="externo" -->
<!--#endif -->

4.2.3 Hotwired XSSI

Hotwired XSSI [45] es una implementación que proporciona una versión extendida al XSSI que
se incluye en Apache. Las características añadidas más importantes son:

Añade una nueva directiva <!--#parse_form ... --> que es capaz de analizar una
entrada desde el cliente codificada según el método GET (vea la sección 2.2.2 en la página
23) y transformarla en en un conjunto de variables listas para ser usadas por otras directivas
SSI.
4.3. JSP 59

Añade una nueva directiva <!--#random ... --> que es capaz de generar un número
aleatorio y asignárselo a una variable, que al igual que antes puede ser luego utilizada en
otras expresiones SSI.

Extiende la directiva <!--#echo ... --> de manera que se pueden asignar cadenas de
código HTML a variables y luego elegir si se desea que echo las imprima como tales o
escapadas (aparecen como un texto más de la página Web).

4.2.4 JSSI

JSSI es un Servlet que proporciona parsing SSI sobre archivos con extensión jhtml. Tiene algunas
limitaciones y también características adicionales:

1. Posibilidad de incluir en una página HTML la salida dinámica de otros Servlets mediante la
etiqueta <servlet> ... </servlet>.

2. Es compatible con sesiones mediante una directiva que reescribe URLs (no necesita cookies
en el cliente).

3. Incluye directivas (experimentales) para comprimir la salida que devuelve el servidor si esta
excede la longitud máxima que acepta el navegador.

Aunque se sigue pudiendo descargar y probar esta implementación, el proyecto en sí ha

desaparecido como resultado de la integración de sus creadores (Java Apache Group) en el
proyecto Jakarta [53]6 .

4.2.5 Un ejemplo

Un buen ejemplo que utiliza todas las directivas, se muestra como parte del ejemplo final de este
proyecto (vea la sección 22.2.2 en la página 313).

4.3 JSP

4.3.1 Introducción

Frente a los Servlets que no son más que pequeños programas Java que producen como salida
contenido para la Web, existe una tecnología de código embebido basada en Java llamada JSP
(Java Server Pages). Los JSP combinan HTML con fragmentos de Java para producir páginas
Web dinámicas. Este nuevo enfoque permite al programador un manejo más cómodo de las
6 El objetivo del proyecto Jakarta es proporcionar soluciones servidor de calidad comercial basadas en plataforma

Java, pero desarrollándolas de manera abierta y colaborativa

60 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

partes estáticas en HTML, mezclando código Java cuando sea necesario para generar el contenido
dinámico. Incluso existen etiquetas que interaccionan con objetos Java del servidor, sin necesidad
de aparezca código fuente en la página.

Los JSP no están completamente aparte de los Servlets, de hecho ambas tecnologías se
complementan. Por un lado los JSP se traducen a Servlets antes de su ejecución y por otro los
Servlets puede usar plantillas JSP.

Actualmente la última versión de la especificación que está disponible en el sitio de SUN, es la

API JSP 1.1 [22].

Funcionamiento

Cuando un cliente pide una página JSP del sitio Web, la página es inicialmente pasada al motor
de JSP, el cual compila la página convirtiéndola en Servlet7 , la ejecuta dentro del contenedor de
Servlets y devuelve el contenido de los resultados al cliente.

Características

Destacar:

Lenguaje embebido: el código JSP se integra en etiquetas embebidas en el código HTML.

Mejor rendimiento: heredado de los beneficios que proporcionaba el contenedor Servlet (vea la
sección 3.3 en la página 43).

Reutilización: integra toda la tecnología de componentes reutilizables JavaBeans de Java.

División del trabajo: los diseñadores maquetan y crean el código de visualización HTML,
mientras los programadores se centran en la lógica del programa.

Extensiones de etiqueta: la última versión del API permite a los programadores implementar
etiquetas JSP propias que engloban áreas de funcionalidad. De esta forma se puede
mantener lo más separada posible la presentación y la lógica de negocio.

4.3.2 El lenguaje JSP

JSP ofrece un nuevo conjunto de etiquetas que pueden incluirse en páginas HTML8 :

1. Directivas.

2. Elementos de script.
7 La
compilación de la página sólo tiene lugar la primera vez que se invoca al JSP.
8 Unadescripción exhaustiva se aparta del objetivo de este proyecto, para más información puede consultarse algún
libro sobre el tema [2].
4.3. JSP 61

3. Acciones.

4. Comentarios.

Directivas

Contienen instrucciones para el contenedor JSP con información acerca de la página en la que se
encuentran. No producen ninguna salida visible. Su sintaxis general es:

<%@ directiva [atributo ="valor"] %>

Algunas directivas son:

Include: incluye archivos en la página JSP actual.

<%@ include file="cabecera.html" %>

Page: ofrece información para la página.

<%@ page atributo="valor" ...%>

Pueden especificarse diversos atributos, que indican desde en que lenguaje se escribe el
código de la página (por ejemplo language="java") hasta si la página maneja contenidos
de error (isErrorPage="true|false").

Taglib: indica una librería de etiquetas que se usará en la página JSP.

<%@ taglib uri="tagLibraryURI" prefix="tagPrefix" %>

Elementos de script

Encapsulan código Java que formará parte del Servlet resultado de la conversión de la página JSP.
Existen tres tipos de elementos de script:

Declaraciones: una declaración JSP será una definición de variables y métodos a nivel de
clase que son usadas en la página. Un bloque de declaraciones típico sería:

<%! aquí la declaración %>

Scripts JSP (scriptlets): son bloques de código Java, aparecerán dentro de la etiqueta:

<% aqui el código del scriptlet %>

62 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

Objeto Descripción
request Encapsula una petición del cliente, normalmente es una subclase de
la case HttpServletRequest.
response Es la página JSP de respuesta, subclase de HttpServletResponse.
pageContext Para permitir que se pueda compilar una página JSP, los atributos y
los objetos implícitos a la misma deben ser accesibles a través del
API.
session El objeto de sesión HTTP asociado a la petición.
application Lo que devuelve el Servlet cuando se llama a
getServletConfig().getContext().
out El objeto que representa la salida de texto por pantalla.
config El objeto ServletConfig de la página.
page Es la forma que tiene la página para referirse a si misma. Se usa
como alternativa al objeto this.
exception Es una subclase Throwable que es pasada a la página que maneja los
errores.

Tabla 4.3: Objetos implícitos JSP.

Desde el código Java embebido puede accederse a cualquier variable o Bean que haya sido
declarado. También hay algunos objetos implícitos disponibles desde el entorno del Servlet
(tabla 4.3).

Expresiones: JSP puede manejar expresiones9 , para ello se usa la siguiente etiqueta:

<%= aqui el código de la expresión %>

Cualquier cosa que aparezca dentro de la etiqueta será evaluado, convertido a cadena de
manera automática y mostrado en pantalla como parte del resultado.

Acciones

Java proporciona cuatro tipos diferentes de acciones:

Forward: transfiere el control desde una página JSP realizando una redirección a otra URL.

<jsp:forward page="otraURL.html"/>

Include: incluye contenido de otro documento en la salida de la página JSP.

<jsp:include page="unaURL.html" flush="true"/>

Plug-in: genera código específico para invocar Applets en el cliente.

9 La expresión no termina en punto y coma. Esto es así porque el Servlet resultante tras compilar el archivo JSP

pone la expresión automáticamente dentro de un out.println().

4.3. JSP 63

<jsp:plugin type="applet" code="Clock2.class">

<jsp:fallback>
No soportado por navegador
</jsp:fallback>
</jsp:plugin>

Beans: proporciona métodos de acceso a Beans de Java mediante <jsp:useBean ...>,

<jsp:setProperty ...> y <jsp:getProperty ...>.

Comentarios

Tres tipos de comentarios pueden aparecer en una página JSP:

Comentarios de contenido HTML: los propios comentarios estándar en HTML pueden

incluirse en los JSP como un elemento estático más. La sintaxis es la siguiente:

<!-- comentario -->

Comentarios JSP: son propios de la página JSP original, están ahí como ayuda al
programador. La sintaxis es la siguiente:

<%-- comentario --%>

Comentarios del lenguaje de script: permiten realizar comentarios dentro de los scriptlets.
En este caso la sintaxis es:

<% /* comentario */ >

4.3.3 Un ejemplo

Uno de las operaciones más realizadas desde cualquier lenguaje embebido es leer los datos de un
formulario y presentarlos en una página Web, a continuación se presenta un pequeño código de
ejemplo:

<!-- Importar las clases de entrada/salida -->

<%@ page import="java.io.*" %>

<html>
<head>
<title>Ver datos enviados desde un formulario</title>
</head>
<body>
64 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

<!-- El formulario sería de este estilo -->

<h1>Formulario</h1>
<form method="POST" action="formulario.jsp">
N tarjeta: <input type="text" name="ntarjeta"></br>
Banco: <input type="text" name="banco"></br>
<input type="submit" value="Enviar" name="Enviar">
</form>

<!-- Los valores devueltos mediante JSP -->

<h1>Variables de formulario</h1>

<b>Número de tarjeta</b>: <%= request.getParameter("ntarjeta") %>

<br><b>Banco</b>: <%= request.getParameter("banco") %>

</body>
</html>

Listado 4.1 JSP para acceder a los datos de un formulario. formulario.jsp.

4.4 PHP

4.4.1 Introducción

PHP (PHP: Hypertext Preprocessor) [88] es un lenguaje interpretado de alto nivel embebido en
páginas HTML y ejecutado en el servidor. Es uno de los lenguajes embebidos más ampliamente
utilizados ya que puede integrarse con prácticamente todos los servidores Web del mercado, posee
un conjunto de opciones muy amplio, buen rendimiento y sobre todo conectividad con un gran
número de bases de datos.

PHP fue concebido a finales de 1994 por un programador independiente (Rasmus Lerdorf) para
uso personal. La primera versión estuvo disponible al público a principios de 1995. Se le llamó
herramientas para paginas Web personales (Personal Home Page Tools). Utilizaba un analizador
sintáctico simple y proporcionaba una serie de utilidades comunes (libro de visitas, contador, etc.).

Posteriormente el analizador sintáctico fue reescrito y renombrado como PHP/FI version 2. En

esta versión se combinaban las herramientas para páginas Web personales (PHP) y un intérprete
de formularios (FI), además se añadió soporte para la base de datos mSQL.

A mediados de 1997 el proyecto dejó de ser personal y se convirtió en un proyecto de un grupo

4.4. PHP 65

organizado. El analizador sintáctico fue totalmente reescrito (y mucho código en PHP/FI también)
y se establecieron las bases para PHP versión 3.

La versión actual es PHP 4.X y tras el acuerdo con la empresa Zend Technologies Ltd. (http:
//www.zend.com) ya no es completamente código libre. La llegada de Zend Technologies
[132] ha revolucionado el funcionamiento interno de PHP, mediante una gran cantidad de nuevas
herramientas. Algunas se distribuyen de forma libre:

Zend Engine: un nuevo analizador sintáctico.

Zend Optimizer: nueva herramienta capaz de interpretar el código PHP y optimizarlo hasta
doblar su rendimiento.

y para otras debe obtenerse licencia:

Zend Compiler: un componente que funciona al estilo del javac de Java, es decir, es
capaz de compilar el código PHP en código de bytes más adecuado para el despliegue de
aplicaciones.

Zend IDE: un entorno de desarrollo para PHP.

...

Funcionamiento

Cuando un cliente pide una página PHP esta es inicialmente pasada al motor PHP. Este puede
actuar de distintas formas antes de devolver el resultado al servidor Web:

Interpretar el contenido de la página, es la forma de actuar por defecto.

Si se dispone de la herramienta Zend compiler, las páginas pueden ser también compiladas
al estilo de JSP o ASP, para su posterior ejecución.

4.4.2 El lenguaje

Esta sección sólo pretende ser una pequeña introducción a las características del lenguaje, puede
ampliarse información en el manual [88] on-line en la página Web de PHP http://www.php.net.

Sintaxis básica

Como en todo lenguaje, en PHP hay una serie de cuestiones de sintaxis que es fundamental conocer
antes de comenzar a programar:
66 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

Etiquetas PHP: hay cuatro formas de marcar que se está escribiendo código PHP dentro de
un documento HTML.

<!-- Modo abreviado -->

<? echo ("esta es la más simple\n"); ?>

<!-- Etiqueta php -->

<?php echo("una etiqueta php\n"); ?>

<!-- Bloque script -->

<script language="php">
echo ("Un bloque de código entre etiquetas script");
</script>

<!-- Etiquetas al estilo ASP -->

<% echo ("Etiquetas tipo ASP"); %>
<!-- Pueden usarse abreviaturas de la función "echo" -->
<%= $variable; %>

Separación de instrucciones: las instrucciones se separan igual que en C o Perl, terminando

cada sentencia con un punto y coma. La etiqueta de cierre (?>) también implica el fin de la
sentencia.

Comentarios: PHP soporta comentarios tipo C, C++ y shell de Unix.

<?
echo "Hola"; // Comentario tipo c++ para una línea
/* Comentario multilínea
segunda línea de comentario
...
*/

echo "Buenas noches"; # Comentario tipo shell

?>

Tipos de datos

Tipos básicos: los tipos básicos del lenguaje PHP son:

– array
– entero
– real
4.4. PHP 67

– objeto
– cadena

Comprobación de tipos: el interprete PHP utiliza una comprobación de tipos débil, de

manera que el tipo de una variable normalmente no lo indica el programador, si no que lo
decide PHP en tiempo de ejecución dependiendo del contexto. Si puede forzar la conversión
de tipos, para ello se utiliza la función settype() .

Variables

En PHP las variables se representan como un signo de dólar seguido por el nombre de la variable.
Este nombre de la variable es sensible a minúsculas y mayúsculas. Es importante recordar
que el carácter “punto” (.) no es válido en una variable, y será tomado como el operador de
concatenación. En PHP 4 pueden asignarse variables por valor o referencia, algunos ejemplos
son:

<?
# A la variable se le asigna el "valor" Hola
$variable = "Hola";
# Referencia a $variable vía $variable2
$variable2 = &$variable;
?>

PHP permite ciertos tratamientos interesantes de las variables:

Variables predefinidas: existen una gran cantidad de variables predefinidas a las que PHP
puede acceder10 , entre ellas variables de Apache, variables de entorno, variables específicas
de PHP (para manejo de cookies, datos de formularios, etc.).

Determinar el tipo de las variables en tiempo de ejecución: no siempre resulta obvio

de qué tipo es una variable dada en un momento concreto. PHP incluye varias
funciones que desvelan el tipo de una variable (gettype(), is_long(), is_double(),
is_string(), is_array(), is_object()).

Constantes

Se pueden definir constantes usando la función define(), también existen constantes predefinidas
(por ejemplo TRUE y FALSE). Como se pude esperar, las constantes no pueden ser redefinidas
más tarde con otro valor.
10 Una buena manera de ver la mayoría de estas variables es utilizando la función phpinfo().
68 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

<?php
define("MICONSTANTE", "Ejemplo versión 1.0");
echo CONSTANTE; //Presenta el valor de la constante
?>

Expresiones

En PHP una definición simple de una expresión es “cualquier cosa que tiene un valor”. Esto es
literalmente así, en PHP casi todo son expresiones:

Las constantes y variables.

Las asignaciones, incrementos y decrementos.

Expresiones de comparación.

Las funciones son expresiones que valen el valor que retornan.

...

Operadores

Existen tres tipos principales de operadores; aritméticos, lógicos y relacionales. Se puede decir que
a grandes rasgos coinciden con los del lenguaje C. Se presentan a continuación algunos operadores
que suelen ser bastante cómodos:

(.) el operador punto permite la concatenación de cadenas.

echo "operador" . "concatenación"

(?) este es el operador condicional ternario, que permite expresar una condición de manera
muy abreviada.

(expr1) ? (expr2) : (expr3);

(‘) el operador apóstrofe invertido o de ejecución, intentará ejecutar la instrucción

contenida dentro de los apóstrofes como si fuera un comando del shell.

echo ‘ls -al‘;

4.4. PHP 69

Estructuras de control

Un archivo PHP se compone de una serie de sentencias, podemos controlar la lógica del programa
con diversas combinaciones de estructuras de control:

Grupos de sentencias: es la estructura de control más simple. Las sentencias se pueden

agrupar en grupos mediante llaves.

Condiciones: se soportan las estructuras clásicas como if y switch.

Bucles: se permiten varios tipos de bucles como while , do...while, for y foreach.
Además también existen las instrucciones break y continue que proporcionan un control
más avanzado de las iteraciones.

Funciones

PHP es un lenguaje modular que permite al usuario declarar nuevas funciones. Una función se
define con la siguiente sintaxis:

<?php

function unaFuncion ($arg_1, $arg_2, ..., $arg_n) {

echo "Función de ejemplo.\n";
return $retval;
}

?>

El cuerpo de una función está delimitado entre llaves y puede contener cualquier instrucción
válida de PHP. No es posible la sobrecarga de funciones, y tampoco redefinir u ocultar funciones
previamente declaradas. PHP 4 soporta un número variable de parámetros, paso de parámetros
por valor o referencia, y valores devueltos de cualquier tipo (arrays, objetos, etc.).

Clases y objetos

Aunque inicialmente PHP no se pensó como un lenguaje orientado a objetos, su continua

evolución le llevó a dar soporte a ese paradigma desde la versión 3.0.

Una clase es una colección de variables y de funciones que acceden a esas variables. Un ejemplo
de clase que define una lista muy sencilla es:
70 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

<?php
class Lista {
var $items; // Array de items en la lista

// Añadir $num elementos de tipo $artnr a la lista

function add_item ($artnr, $num) {
$this->items[$artnr] += $num;
}

// Sacar $num elementos del tipo $artnr de la lista

function remove_item ($artnr, $num) {
if ($this->items[$artnr] > $num) {
$this->items[$artnr] -= $num;
return true;
} else {
return false;
}
}
}
?>

Una vez definida la clase se creará una variable del tipo deseado con el operador new. Tal y como
indica la teoría clásica de objetos, las clases en PHP pueden declararse como extensiones de otras
clases, si bien la herencia múltiple no es soportada.

Entre funciones de una clase, la variable $this hace referencia al propio objeto. Debe usarse esta
variable para acceder a una variable o método del objeto actual.

Una función se convierte en constructor cuando tiene el mismo nombre que la clase.

4.4.3 Potencia de PHP

PHP puede hacer cualquier cosa que se pueda hacer con un script CGI, como procesar la
información de formularios, generar páginas con contenidos dinámicos, o mandar y recibir
cookies. Además ofrece características avanzadas muy interesantes como el soporte a diversos
protocolos como el propio HTTP, protocolos de correo (IMAP, POP3, etc.), de news (NNTP),
interfaces con COM y CORBA ...

Pero quizá lo más destacado de PHP es que ofrece soporte a una gran cantidad de bases de datos.
Esta amplia cobertura es una de las características que han hecho a muchos desarrolladores utilizar
PHP, sobre todo en los últimos años, donde se ha producido el boom del comercio electrónico y
con él la necesidad de almacenar ingentes cantidades de datos. En la actualidad se ofrece soporte
a:
4.4. PHP 71

Adabas D IBM DB2 Microsoft Sql Server PostgresSQL

dBase InterBase mSQL Solid Embedded Engine
DBMaker Informix MySQL Sybase
Empress LDAP IBM DB2 Velocis
filePro Linux/Unix DBM ODBC

4.4.4 Un ejemplo

Una de las características más potentes de PHP es su forma de manejar los formularios HTML. A
continuación se muestra un código básico para leer los datos de un formulario y presentarlos en
una página Web:

<html>
<head>
<title>Ver datos enviados desde un formulario</title>
</head>
<body>

<!-- El formulario sería de este estilo -->

<h1>Formulario</h1>
<form method="POST" action="formulario.php">
N tarjeta: <input type="text" name="ntarjeta"></br>
Banco: <input type="text" name="banco"></br>
<input type="submit" value="Enviar" name="Enviar">
</form>

<!-- Los valores devueltos mediante PHP -->

<h1>Variables de formulario</h1>

<b>Número de tarjeta</b>:
<? print($ntarjeta); ?>
<br><b>Banco</b>:
<? print($banco); ?>

</body>
</html>

Listado 4.2 PHP para acceder a los datos de un formulario. formulario.php.

72 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

4.5 ASP

4.5.1 Introducción

Las páginas ASP (Active Server Pages) [10] son otro buen ejemplo de código script embebido
en archivos HTML. Esta tecnología ha sido creada por Microsoft y conforma uno de los pilares
básicos de los servidores Web de esta empresa (Internet Information Server, Personal Web Server).
El núcleo de ASP es un manejador externo que funciona como extensión del servidor11 . El
servidor Web asociará los archivos de tipo .asp con el programa manejador, de esta manera cuando
una página ASP es solicitada, la petición se le pasa al programa que interpreta y compila los scripts
embebidos antes de ejecutarlos12 .

Funcionamiento

El esquema de funcionamiento es bastante parecido al de las otras tecnologías. El servidor se da

cuenta de que se le ha solicitado es una página ASP y le transfiere el control al manejador, este
compila el código si es necesario y luego ejecuta el resultado. La página dinámica obtenida se
devuelve hacia el servidor Web que se encargará de redirigirla al cliente.

4.5.2 Componentes ASP

La implementación ASP tiene una serie de componentes:

Ficheros ASP: tienen la extensión .asp, básicamente son archivos de texto que contienen
combinaciones de HTML e instrucciones ASP13. Las instrucciones ASP se encierran entre
etiquetas especiales o también en secciones especiales de código script:

<!-- Una etiqueta ASP, que declara una variable -->

<% Dim variable %> .

<!-- Una sección de código ASP -->

<SCRIPT LANGUAGE="VBScript" RUNAT="SERVER">
...
</SCRIPT>.

Objetos: hay una serie de objetos que se pueden utilizar directamente (sin instanciarlos) en las
páginas ASP. Se encargan de encapsular la información relacionada con el protocolo HTTP
(peticiones, respuestas, sesiones mediante cookies, etc.), facilitando su acceso desde el
lenguaje. Estos objetos integrados se presentan en una tabla (tabla 4.4).
11 En Windows, se implementa como una extensión ISAPI (asp.dll)
12 El proceso de compilar los scripts sólo se hace la primera vez.
13 Las instrucciones ASP pueden escribirse en distintos lenguajes, por defecto VBScript, aunque también se permite

Jscript y PerlScript.
4.5. ASP 73

Objeto Significado
Application Se utiliza para almacenar información referente a una aplicación
dada, que puede ser compartida entre los usuarios de la misma.
Request Provee el acceso a la información que acompaña a las peticiones
HTTP (método, valores de formularios, etc.).
Response Controla la información de la respuesta HTTP que es enviada al
usuario (páginas HTML, información de redirección, valores de
cookies, etc.).
Server Encapsula el acceso a métodos y propiedades del servidor
(codificación URL, creación de instancias de objetos ActiveX, etc.).
Session HTTP es un protocolo sin estados, ASP implementa en este objeto
el soporte que permite almacenar información para crear sesiones de
usuario.
ObjectContext Se utiliza para confirmar o anular una transacción iniciada para una
secuencia de instrucciones.

Tabla 4.4: Objetos implícitos ASP.

Componentes ActiveX: encapsulan tareas relacionadas con distintos aspectos (envío de correo,
etc.). Quizá los más destacados sean los objetos ADO (Active Data Objects), que facilitan
el acceso al sistema de ficheros, bases de datos, ...

4.5.3 Implementaciones

Microsoft, como creador de esta tecnología, tiene implementaciones de la misma disponibles para
sus servidores Web. Estas implementaciones están fuertemente ligadas a las plataformas Windows.

Existen varios intentos de portar la tecnología ASP a otras plataformas y servidores. Se pueden
distinguir las opciones de código abierto de la comerciales.

Dentro de las soluciones en código abierto:

Apache:ASP: [13] se trata de un módulo Perl que permite programar ASP, aunque sólo en
PerlScript. Más información en http://www.apache-asp.org/.

OpenASP: [83] intenta dar soporte a todos los lenguajes de script soportados por el ASP original
(VBScript, JScript), además de PerlScript, para hacer un poco más accesible el salto
hacia plataformas Linux/Unix de usuarios acostumbrados a tecnología Microsoft. Más
información es http://www.activescripting.org.

Y como soluciones comerciales:

InstantASP: [49] es un producto comercial que necesita un servidor Web que soporte Servlets
para poder ejecutarse. Más información en http://www.halcyonsoft.com/.
74 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

Chili!Soft: [27] es quizá el producto que alardea de ser más compatible con el ASP original, se
integra con algunos de los servidores Web más conocidos como Apache, iPlanet, Zeus, etc,
y ofrece compatibilidad con:

Microsoft Active Server Pages 2.0 escritas en VBScript 3.2 o JScript 3.2: cualquier
aplicación que utilice estos estándares en un servidor IIS, debería funcionar
exactamente igual sobre un servidor con las extensiones que proporciona Chili!Soft.

Microsoft Active Data Objects (ADO) 2.0 : proporciona un amplio soporte a bases de
datos a través de objetos ActiveX, incluso ODBC.

Internationalization: Multi-byte.

Character Set (MBCS).

Además ofrece valores añadidos como objetos propios de acceso a datos, conectividad con
Java y CORBA, herramientas de administración, ...
En la parte negativa se puede resaltar que necesita bastantes recursos (256 megas de
RAM y 200 megas de disco duro), y por su puesto, su precio. Más información en
http://www.chilisoft.com.

4.5.4 Un ejemplo

Quizá uno de los ejemplos más sencillos de código ASP es el que permite acceder a los valores de
los campos que fueron introducidos en un formulario:

<html>
<head>
<title>Ver datos enviados desde un formulario</title>
</head>
<body>
<!-- El formulario sería de este estilo -->
<h1>Formulario</h1>
<form method="POST" action="formulario.asp">
N tarjeta: <input type="text" name="ntarjeta"></br>
Banco: <input type="text" name="banco"></br>
<input type="submit" value="Enviar" name="Enviar">
</form>

<!-- Los valores devueltos mediante ASP -->

<h1>Variables de formulario</h1>

<%for each unvalor in request.form

for i=1 to request.form(unvalor).count
4.6. OTRAS POSIBILIDADES 75

response.write unvalor&"="&request.form(unvalor)(i)&"<br>"
next%>

</body>
</html>

Listado 4.3 Asp para acceder a los datos de un formulario. formulario.asp.

4.6 Otras posibilidades

Existen una gran cantidad de proyectos que permiten embeber código fuente de distintos lenguajes
en páginas HTML. De hecho para los lenguajes más conocidos (como Perl o C) se puede elegir
entre varias implementaciones distintas. A modo de ejemplo se pueden citar los siguientes:

SSJS (Server Side JavaScript): [80] JavaScript es un lenguaje script orientado a objetos
desarrollado por Netscape. Existen dos versiones: una orientada a ser ejecutada en el
navegador Client Side JavaScript, y otra para utilizarse en el lado servidor Server Side
JavaScript. Aunque ambas comparten la misma funcionalidad básica (objetos, arrays, etc.),
la versión del lado servidor ofrece características avanzadas como:

– Gestión de sesiones.
– Tecnología LiveWire de acceso a BBDDs.
– Tecnología LiveConnect para comunicación entre Javascript y Java.
– Acceso a servicios CORBA.
– ...

Los servidores de Netscape (iPlanet, etc.) ofrecen implementaciones de este lenguaje,

también hay algunos intentos de portar esta tecnología a otros servidores como
Apache. Puede encontrarse más información en http://developer.netscape.com/
docs/manuals/js/server/jsref/index.htm.

Perl embebido: existen distintos módulos de Perl [87] [68] que permiten introducir
instrucciones en plantillas HTML. La idea se deriva de otras tecnologías muy conocidas
como JSP y el funcionamiento es muy parecido. Pueden ejecutarse en cualquier servidor
que soporte CGI con PERL, aunque por eficiencia se recomienda su ejecución dentro del
marco de un servidor Apache con mod_perl. Hay dos implementaciones importantes:

– PEE (Perl Embebed Engine): http://pee.sourceforge.net/.

– Mason HQ: http://www.masonhq.com/.
76 CAPÍTULO 4. CÓDIGO EMBEBIDO EN HTML

C/C++: [25] [26] existen multitud de implementaciones que permiten embeber C o C++
en HTML, la mayoría son módulos para Apache. Algunos ejemplos pueden encontrarse
en http://linux.medyatext.com.tr/apache/cint.html o http://d-000631-pp.
dhcp.fnal.gov/~onuchin/Carrot/.

CFML: [28] [29] es el lenguaje script utilizado en el servidor de aplicaciones Coldfusion

(vea la sección 1.5.5 en la página 15), además existen varios intentos de portabilidad a
Apache como por ejemplo http://mod-fusion.indyhosting.net/.

Haskell, Prolog, Python, etc.: también tienen sus versiones embebidas que funcionan como
módulos de Apache, más información en http://modules.apache.org.

4.7 Conclusión

Embeber algún lenguaje de programación dentro del código HTML es una forma muy cómoda y
rápida de trabajar. En un entorno que cambia a la velocidad del Web, esto es algo importante. En
este capítulo se presentan algunas de las opciones disponibles. ¿Cuál es la mejor?, la respuesta es
depende de los criterios de comparación. Hoy en día PHP, JSP y ASP ofrecen un gran abanico
de funcionalidades, mucha documentación, integración con varios servidores Web y una amplia
implantación en el mercado.

Pero también es posible elegir alguna de las opciones “minoritarias”, por ejemplo habrá personas
a las que no les interesa aprender un nuevo lenguaje de programación y prefieran utilizar alguno
de los que ya conocen como C, Prolog, etc.

Si la decisión se complica siempre es posible añadir nuevos criterios que faciliten la criba
(precio, disponibilidad para el sistema operativo, etc.), o simplemente instalar todas las opciones
interesantes (ya que no son excluyentes) y dejar la elección para otro momento.
Capítulo 5

HTTP seguro

Contenidos de este capítulo

5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2 HTTP + SSL = HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.1 Introducción al protocolo SSL . . . . . . . . . . . . . . . . . . . . . . 78
5.2.2 Características de SSL v3 . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.3 Cuestiones de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.4 Pasos del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.5 Implementaciones de SSL . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.6 HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.3 S-HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3.2 El protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.3.3 Implementaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.1 Introducción

La seguridad es un tema fundamental en Internet al que desgraciadamente no se le dedica

demasiada atención. El Web como servicio ofrecido a través de Internet, también debe tener
en cuenta consideraciones de seguridad. De hecho los servidores Web se están convirtiendo en
un objetivo muy atractivo para todo tipo de personajes con malas intenciones. Los objetivos
principales de este tipo de gente son dos:

1. Poner de manifiesto los fallos en la seguridad realizando sin permiso algún cambio en el
sitio Web de una organización. Por ejemplo, fue muy sonado el caso de la página Web de
La Moncloa (http://www.lamoncloa.es). Estos ataques, aparte de la mala imagen no
suelen tener otras consecuencias.

77
78 CAPÍTULO 5. HTTP SEGURO

2. Robar información sensible, como pueden ser los datos personales o información de tarjetas
de crédito. Como ejemplo, los fallos de seguridad en Hotmail (http://www.hotmail.com)
que daban acceso a las bases de datos de usuarios.

Aún considerando que es muy complejo garantizar la seguridad en una red como Internet, se
ha trabajado en varios protocolos que hacen un poco más segura la transferencia de datos sobre
HTTP. Lo más utilizado es HTTP sobre una capa de sockets seguros con SSL, aunque existen
otras aproximaciones como S-HTTP. Ambas se apoyan en técnicas criptográficas (encriptación
simétrica y asimétrica, firmas y certificados digitales, etc.). Una explicación en profundidad de
estas técnicas se aparta del objetivo de este proyecto1 . En las siguientes secciones simplemente se
dará un vistazo general a HTTP sobre SSL y a S-HTTP.

5.2 HTTP + SSL = HTTPS

5.2.1 Introducción al protocolo SSL

El protocolo SSL (Secure Sockets Layer) es un protocolo de comunicación que se ubica en la pila
de protocolos sobre TCP/IP2 . SSL proporciona servicios de comunicación “segura”3 entre cliente
y servidor, como por ejemplo autenticación (usando certificados), integridad (mediante firmas
digitales), y privacidad (mediante encriptación).

El protocolo se diseñó de forma escalable permitiendo la elección de diversos algoritmos para

la criptografía, compendios y firmas. Esto permite que la elección del algoritmo pueda hacerse
teniendo en cuenta cuestiones legales, de exportación u otras preocupaciones, y también permite al
protocolo aprovecharse de nuevos algoritmos. Las opciones se negocian entre el cliente y servidor
al comienzo de la sesión.

Hay varias versiones del protocolo, la primera, SSL v1 fue creada por Netscape Corporation
y nunca tuvo uso público. La versión 2 ya formaba parte del las primeras versiones del
navegador Netscape Navigator. Actualmente la versión que incluyen todos los navegadores de
última generación es SSL v3. El nuevo paso se llama TLS (Transport Layer Security), este
nuevo protocolo ha sido diseñado por el IETF (Internet Engeneering Task Force) [47] como una
ampliación de SSL v3 con mejoras en la forma de realizar la autenticación. Por último y muy
relacionado con el anterior ha surgido WTLS (Wireless Transport Layer Security) que implementa
un TLS para comunicaciones inalámbricas.
1 Los interesados en el tema pueden consultar algún buen libro, como por ejemplo Cryptography and network

security: principles ans practice [3].

2 SSL puede funcionar no sólo sobre TCP / IP, sino también sobre cualquier protocolo a nivel de transporte orientado

a conexión.
3 “Segura”, entre comillas, porque nada está completamente seguro en la red. En esta memoria se abusa del término

seguridad, quizá debería haberse utilizado seguridad relativa.

5.2. HTTP + SSL = HTTPS 79

5.2.2 Características de SSL v3

SSL ofrece algunas características de interés:

Separación de responsabilidades: utiliza algoritmos independientes para la encriptación,

autenticación e integridad de datos, con claves diferentes (claves secretas) para cada función.
Esto permite la utilización de acuerdo con las leyes, por ejemplo las leyes de exportación de
EEUU4 o las leyes anti-criptografía de Francia5 .

Eficiencia: aunque la fase de saludo utiliza algoritmos de clave pública, la operativa de

intercambio de datos se realiza mediante encriptación y des-encriptación de clave privada.
Los algoritmos de clave privada son más rápidos. Además la fase de saludo no tiene que
repetirse para cada comunicación entre un cliente y un servidor, la “clave secreta” negociada
puede conservarse entre conexiones SSL. Esto permite que las nuevas conexiones SSL
inicien la comunicación segura de inmediato, sin necesidad de realizar lentas operaciones
de clave pública.

Autenticación con base en certificados: se utilizan certificados X.509 para la autenticación. Los
certificados de servidores son obligatorios, mientras que los de cliente son opcionales.

Independiente de protocolos: aunque SSL se diseño para funcionar sobre TCP/IP, puede hacerlo
sobre cualquier protocolo confiable orientado a conexiones (por ejemplo X.25). En cambio
no funcionará sobre un protocolo no confiable, como por ejemplo UDP (User Datagram
Protocol).

Protección contra ataques: SSL protege frente a ataques de hombre en el camino o de

reproducción.
En un ataque de hombre en el camino, el atacante intercepta todas las comunicaciones entre
las dos partes, haciendo a cada una de ellas creer que se comunica con la otra. SSL protege
contra estos ataques mediante certificados digitales que nos garantizan con quien se está
hablando.
En un ataque de reproducción, un atacante captura las comunicaciones entre las dos partes
y reproduce los mensajes. SSL no permite este tipo de ataques.

Soporte a algoritmos heterogéneos: aunque depende de las implementaciones, SSL suele dar
soporte a diversos algoritmos:

Intercambio de claves (RSA y Diffie - Hellman).

Compendio (MD5, SHA-1).

4 Los reglamentos federales imponen limites a la longitud en las claves utilizadas para guardar confidencialidad pero
no a las usadas para garantizar integridad de datos y autenticación.
5 Francia prohíbe la encriptación. SSL v3 permite conexiones no encriptadas pero si autenticadas y con protección

de integridad.
80 CAPÍTULO 5. HTTP SEGURO

Encriptación (RC2, RC4, DES, Triple DES, Idea, Fortezza).

Soporte de compresión: SSL permite comprimir los datos del usuario antes de ser encriptados
mediante múltiples algoritmos de compresión.

Compatibilidad hacia atrás con SSL v2: los servidores de SSL v3 pueden recibir conexiones
de clientes SSL v2 y manejar el mensaje de manera automática.

5.2.3 Cuestiones de rendimiento

SSL disminuye la velocidad de transmisión de información a través de Internet principalmente

como consecuencia de la sobrecarga que provoca la encriptación y des-encriptación de clave
pública necesaria para iniciar la primera conexión SSL. En comparación con esto, el tiempo
adicional que requiere la encriptación y des-encriptación de datos utilizando métodos de clave
privada es casi insignificante.

En el lado cliente, si se utiliza un ordenador relativamente rápido (Pemtium II) y una conexión de
red relativamente lenta6 , el tiempo invertido para operaciones de SSL es insignificante.

En el lado servidor, si lo habitual es atender varias peticiones de HTTP sobre SSL en cortos
espacios de tiempo, hay que pensar en obtener un equipo suficientemente rápido en las operaciones
de clave pública. Muchas organizaciones transmiten la mayor parte de su información en forma
clara y utilizan SSL solo para encriptar información realmente sensible. Esto reduce la necesidad
de potencia del servidor pero también es menos seguro, ya que durante su trayecto del cliente al
servidor, el HTML no encriptado puede ser modificado por algún atacante.

5.2.4 Pasos del algoritmo

Se muestra a continuación un resumen del esquema básico del algoritmo, y una figura (figura
5.1) que ubica los distintos protocolos relacionados en una torre general. Si se necesita más
información puede consultarse la especificación de SSL [116].

1. Un cliente SSL se conecta al servidor SSL.

2. Se inicia la fase de saludo (protocolo handshake). El cliente envía un mensaje que contiene
el número de versión del protocolo SSL que utiliza, los métodos criptográficos soportados
y un flujo de bytes aleatorio.

3. El servidor responde al saludo, envía el número de versión del protocolo SSL que utiliza, el
método criptográfico seleccionado, un identificador de sesión y un flujo de bytes aleatorios.

4. El servidor envía al cliente un certificado X.509 que le identifica.

6 ...y sin relativamente, hoy en día la conexión desde casa es “lenta”.
5.2. HTTP + SSL = HTTPS 81

Figura 5.1: Situación del protocolo SSL en la torre de protocolos.

5. Opcionalmente puede ser que el servidor requiera la autentificación por parte del cliente
(que debe disponer de su propio certificado X.509).

6. El cliente autentifica el servidor comprobando el certificado del mismo.

7. El cliente genera una clave secreta previa que se enviada encriptada con la clave pública del
servidor (conocida gracias al certificado).

8. Opcionalmente, si el servidor ha requerido la autentificación del cliente, este enviará firmado

algún dato adicional (certificado X.509 propio, etc.). El servidor autentificará al cliente
gracias al certificado.

9. El cliente y el servidor usan la clave secreta previa para determinar una clave maestra
(secreta) de sesión.

10. Se intercambian mensajes para especificar los métodos de cifrado (protocolo de cipher
method). Deberá llegarse a un acuerdo sobre que algoritmos utilizar para intercambio de
claves, cifrado para transferencia de datos y compendio de mensajes. Además se indica
que todos los mensajes posteriores deberán utilizar la clave maestra de sesión.

11. Finaliza la fase de saludo. Se intercambia un mensaje encriptado con la clave de sesión que
indica el comienzo de la comunicación “segura”. A partir de este momento se utiliza el
register protocol que encapsula los datos y los transfiere a través del protocolo de la capa
inferior.

Como se ha visto la sesión de SSL se establece siguiendo una serie de pasos de saludo
(handshaking) entre el cliente y servidor. Esta sucesión puede variar, dependiendo de si el
servidor se configura para pedir certificados de cliente. Además existen algunos casos en donde
se requieren pasos de saludo adicionales para el manejo de condiciones especiales (protocolo de
condiciones de advertencia o error).

Una vez una sesión de SSL se ha establecido puede reutilizarse, evitando así la penalización de
repetir los pasos necesarios durante la fase de saludo. El servidor asigna un identificador único a
82 CAPÍTULO 5. HTTP SEGURO

cada sesión de SSL que debe ser guardada de modo seguro para que el cliente pueda utilizarla en
próximas conexiones (hasta que el identificador de la sesión caduque).

5.2.5 Implementaciones de SSL

Secure Sockets Layer fue creado en julio de 1994, desde entonces (y en orden cronológico) han
surgido varias implementaciones:

Programas de Netscape con SSL

La primera implementación de SSL se encontraba dentro de los navegadores y servidores de

Netscape, cosa nada extraña teniendo en cuenta que fue esa empresa la que desarrollo el protocolo.
Era imposible encontrar una implementación por separado.

Implementación de referencia: SSLRef

Posteriormente, Netscape produjo una implementación de referencia de SSL 2.0 (SSLRef), que se
publicó en abril de 1995. Para su uso legal en EEUU debía obtenerse licencia de Netscape.

Era una implementación limitada que no incluía algoritmos de encriptación como RC2, RC4 y
RSA. Curiosamente, muchos programas que utilizan SSL, como Navigator de Netscape, sólo
contenían tales algoritmos. Por ello, para que un programa basado en SSLRef fuese compatible
con un programa como Navigator, era necesario obtener una licencia en forma independiente de
tales algoritmos7 .

SSLeay

SSLeay es una implementación independiente de SSL 3.0 desarrollada por Eric Young, un
programador australiano. Está disponible en forma gratuita en todo el mundo en varios sitios
de FTP anónimo.

SSLeay utiliza implementaciones de RC2 y RC4 basadas en los algoritmos publicados de forma
anónima en el grupo de discusión sci.crypt.

Además de RC2 y RC4, SSLeay también incluye IDEA, DES y Triple DES. Young sugiere a los
programadores utilizar Triple DES siempre que sea posible. A diferencia de los algoritmos IDEA,
RC2 y RC4, Triple DES se ha estudiado durante más de 20 años y se cree que es seguro.
7 RC2, RC4 y RSA necesitaban una licencia expedida por el propietario (RSA)
5.2. HTTP + SSL = HTTPS 83

OpenSSL

OpenSSL [84] es un conjunto de herramientas (basado en SSLeay) que implementa tanto los
protocolos SSL v2/v3 y TLS v1 como los estándares criptográficos relacionados y requeridos por
ellos. El programa openssl es una herramienta de shell que permite usar las diversas funciones
de la librería criptográfica. Puede ser utilizado para:

Creación de claves RSA, DSH y DSA.

Creación de certificados X.509, CSRs (petición) y CRLs (Lista de revocación).

Calculo de compendios (Message Digests).

Encriptación y des-encriptación.

Tests de clientes y servidores SSL/TLS.

Manejo de S/MIME (secure-Mime) mail firmado o encriptado.

SSLJava

La rápida expansión de Java, ha hecho que se implementen multitud de APIs. En relación con SSL,
se ha desarrollado la JSSE (Java Secure Socket Extension) [60], extensiones de sockets seguros
sobre Java.

JSSE es un paquete de Java que implementa el soporte de los protocolos SSL v3 y TLS v1. La
versión de JSSE puede usarse de forma libre como parte de las aplicaciones comerciales.

5.2.6 HTTPS

SSL puede utilizarse para asegurar la comunicación de la mayoría de los protocolos a nivel de
aplicación. La versión “segura” del protocolo suele añadir la letra (S) a su nombre. Así por
ejemplo:

SSMTP: indica el protocolo de envío de correo SMTP protegido con SSL.

SPOP3: es el protocolo de oficina de correos POP3 protegido con SSL.

HTTPS: protocolo de transferencia de hipertexto HTTP protegido con SSL.

...

Pero el protocolo que aquí interesa es HTTPS, muchos servidores actuales ya lo implementan, y
suelen reservar para él el puerto 443. Por tanto un servidor Web escuchando en el puerto 443 será
capaz de responder a peticiones del estilo:
84 CAPÍTULO 5. HTTP SEGURO

https://www.miservidorwebseguro.com/

Para dar soporte HTTPS los desarrolladores de servidores Web pueden programar el protocolo
SSL de forma nativa (por ejemplo iPlanet) o bien apoyarse en alguna implementación de terceras
partes (por ejemplo mod_ssl + openssl).

5.3 S-HTTP

5.3.1 Introducción

S-HTTP (secure HTTP) fue descrito en el RFC 2660 [109]. Secure HTTP no es HTTPS, se basa
en negociar la seguridad a través de extensiones a las cabeceras HTTP, no en un protocolo seguro
subyacente como SSL. Define la sintaxis para asegurar el envío de mensajes utilizando HTTP y
proporciona servicios de seguridad aplicables independientemente para:

Confidencialidad de transacciones.

Autenticación e integridad.

No repudiación.

También maneja negociación entre las partes para maximizar la flexibilidad en la elección de:

Mecanismos de gestión de claves.

Políticas de seguridad.

Algoritmos criptográficos.

5.3.2 El protocolo

Un mensaje S-HTTP es una cabecera de petición (request) o una línea de estado, seguida de un
conjunto de otras cabeceras y algún contenido. Este contenido puede ser texto plano, mensajes
seguros o simplemente mensajes HTTP. Una petición segura mediante S-HTTP, puede tener el
aspecto:

Secure * Secure-HTTP/1.4
...

Mientras una respuesta, comenzaría por:

Secure-HTTP/1.4 200 OK
...
5.3. S-HTTP 85

Presentar aquí el resto de la sintaxis S-HTTP, puede resultar algo crudo, simplemente
enumeraremos algunas de las características más importantes:

Protocolo seguro: es un protocolo de comunicaciones seguro orientado a mensajes.

Integrable con HTTP: ha sido diseñado para integrarse con HTTP de una manera fácil, a
través de extensiones de las cabeceras HTTP.

Compatible con HTTP: añade extensiones a las cabeceras, pero mantiene todas las
funcionalidades básicas.

Configurable: permite incorporar diversos formatos criptográficos según dos formatos de

encapsulación de la información: CMS (Cryptographic Message Syntax) [108] que es el
formato preferido y MOSS [93] [94]).

Interoperabilidad: entre diversas implementaciones.

No requiere certificados digitales o claves públicas del lado cliente. Puede trabajar sólo
con algoritmos de clave simétrica y aunque puede aprovecharse de las infraestructuras de
entidades certificadoras, en realidad no las necesita.

Transacciones seguras punto a punto: en contraste con los mecanismos originales de

autorización HTTP que necesitan que el cliente intente acceder antes de que se lance el
mecanismo de seguridad (mecanismos de reto-respuesta). Los clientes pueden comenzar
una transacción segura, basándose en las cabeceras de mensaje.

Flexible: gracias a la negociación pueden elegirse distintos los algoritmos criptográficos,

modos y parámetros, etc. Por ejemplo, ¿Debe el mensaje encriptarse, firmase o ambos? ¿Se
utilizará RSA o DSA, DES o RC2?

Generalista: intenta no presuponer modelos de seguridad particulares.

5.3.3 Implementaciones

Parece que S-HTTP no ha tenido mucha aceptación, pueden haber influido varios aspectos como
el apoyo de los grandes fabricantes a la solución basada en SSL (SSL fue creado por Netscape),
o una conocida debilidad en el intercambio de claves, que puede provocar que un usuario no
experimentado sea vulnerable a ataques [117].

De todas maneras existe algún servidor que sí ofrece soporte a este protocolo, aunque la lista no
es demasiado extensa y los productos que aparecen en ella no son especialmente conocidos:

Alibaba: http://www.csm-usa.com/

Secure HTTPd: http://hoohoo.ncsa.uiuc.edu/

86 CAPÍTULO 5. HTTP SEGURO

WebSite Professional: http://www.software.oreilly.com/

WebTen: http://www.tenon.com/

Wildcat Interactive Net Server: http://www.santronics.com/

El listado de clientes que soportan S-HTTP es aún más pequeño, de hecho sólo un navegador
bastante antiguo (Secure Mosaic) parece haber implementado una versión de este protocolo.
Capítulo 6

Relación entre Web y XML

Contenidos de este capítulo

6.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.2 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.2.2 Características de XML . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2.3 Definición de la estructura de un documento XML . . . . . . . . . . . 89
6.2.4 La sintaxis de XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2.5 Otras especificaciones y tecnologías desarrolladas en torno a XML . . . 92
6.3 XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3.2 Principales diferencias entre XHTML y HTML 4.X . . . . . . . . . . . 94
6.3.3 Un ejemplo sencillo de XHTML . . . . . . . . . . . . . . . . . . . . . 94
6.4 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.4.2 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.4.3 Estructura de funcionamiento SOAP sobre HTTP . . . . . . . . . . . . 97
6.5 Otras aplicaciones relacionados con XML y la Web . . . . . . . . . . . . . 99

6.1 Introducción

En los últimos tiempos, en cualquier campo de la informática (y sobre todo en el contexto de

la World Wide Web) se está hablando mucho de XML. Algunas de las empresas más importantes
como Microsoft, Oracle, etc, soportan esta tecnología en sus productos más vendidos (Office, Base
de datos Oracle, etc.). Como cabía esperar, el campo de los servidores Web también ha sucumbido
a esta tendencia, siendo muchas las aplicaciones que se basan en la combinación de HTTP y XML.

87
88 CAPÍTULO 6. RELACIÓN ENTRE WEB Y XML

Una pregunta muy frecuente es ¿XML es simplemente el sustituto de HTML?. La respuesta es no.
Básicamente XML no ha sido creado para una aplicación exclusiva en la Web, aunque hay líneas
de trabajo en este sentido (XHTML, etc.).

Este capítulo se tratan los conceptos básicos de XML y de algunas de sus aplicaciones más
importantes a la World Wide Web.

6.2 XML

6.2.1 Introducción

XML (eXtensible Markup Language) [130] [131] [129] es un lenguaje a nivel de aplicación para
intercambio de información estructurada, dicho de forma muy sencilla, es un nuevo formato de
datos. La versión 1.0 del lenguaje es una recomendación del W3C [127] desde febrero de 1998.
Desde esa fecha XML ha crecido exponencialmente (tanto en uso real en aplicaciones, como en
las veces que se oye hablar de él).

Historia

Figura 6.1: XML y los lenguajes de etiquetado

XML tiene su punto de partida en los lenguajes de marcado. Hasta la aparición de XML dos eran
los más utilizados:

HTML (HyperText Markup Language): (vea el apéndice A en la página 361) el lenguaje

más usado para crear páginas Web en la actualidad.

SGML (Standard Generalized Markup Language): [11] un lenguaje no tan conocido,

aunque extremadamente potente y utilizado con éxito desde 1986, cuando lo estandarizó
la ISO (International Organization for Standaritation) [51]. De hecho SGML (al igual que
XML) no es simplemente un lenguaje de marcas, más bien es un generador de lenguajes
de marcas. De todas maneras es lo suficientemente complejo como para que muchas
organizaciones no lo hayan adoptado.
6.2. XML 89

XML está a medio camino (figura 6.1) entre la sencillez de uso y posibilidades de HTML y la
potencia de SGML. Su objetivo básico es dotar a los datos de semántica y a los documentos de
estructura. A continuación se muestra un ejemplo sencillo donde se puede observar como XML
proporciona semántica y estructura:

<?xml version="1.0"?>
<producto>
<nombre>Carpeta anillas</nombre>
<fabricante>Carpetas monfortinas S.A</fabricante>
<precio unidad="euro">3</precio>
</producto>

Listado 6.1 Un documento XML de ejemplo.

6.2.2 Características de XML

Varias son las características que ofrece XML:

Aunque hoy día XML aún no está tan extendido como HTML, su uso futuro en la Web
mejorará la eficiencia de las búsquedas, al proporcionar cada documento XML metadatos
sobre sí mismo.

Permite proporcionar diferentes vistas sobre los datos (HTML, PDF, voz, etc.), dependiendo
de quién sea el cliente.

Facilita la integración desde fuentes de datos heterogéneas, por ejemplo, páginas Web,
distintas bases de datos, ...

Los documentos tienen una estructura que los hace legibles e inteligibles no sólo para los
ordenadores, si no también para los humanos.

Las aplicaciones de XML son fácilmente extensibles mediante definiciones de nuevos tipos
de documento (DTD).

6.2.3 Definición de la estructura de un documento XML

A lo largo del tiempo han surgido distintas formas de definir la estructura de un documento XML:

DTD (Document Type Definition): define la semántica del tipo de documento que se está
creando (los elementos disponibles, las relaciones entre ellos, los atributos, posibles valores,
etc.). Representa la estructura de una clase concreta de documentos XML. La definición
del DTD es la parte más compleja de la construcción del documento, aunque existen
repositorios con DTDs ya definidos que pueden ser reutilizados.
90 CAPÍTULO 6. RELACIÓN ENTRE WEB Y XML

XML SCHEMA: aunque el objetivo es el mismo que en los DTD, los XML SCHEMAs son
en sí mismos documentos XML, de esta manera se pueden utilizar las mismas herramientas
para crear las semánticas y los documentos propiamente dichos.

RDF (Resource Description Framework): esta siendo desarrollado como un proyecto del
W3C. El objetivo es manejar grandes cantidades de documentos HTML o XML. RDF crea
metadatos para un conjunto de documentos, de manera que estos pueden ser encontrados
más tarde.

XML Namespaces: proporcionan un método simple para distinguir nombres de elementos

y atributos que se utilizan en documentos XML, mediante una asociación de los mismos
con referencias a URIs. El objetivo principal de la especificación de espacios de nombre
(namespaces) es permitir que el autor del documento le diga al analizador sintáctico (parser)
qué DTD usar para analizar un elemento dado.

De acuerdo a las reglas que cumplen los documentos respecto a la especificación XML y a la
definición de su estructura, se pueden distinguir estos dos tipos:

Bien formados: todos aquellos documentos que cumplen las especificaciones del lenguaje
en lo que se refiere a las reglas sintácticas. Un documento bien formado podrá ser analizado
por un parser genérico.

Válidos: además de bien formados responden a la estructura semántica definida por su DTD.

Analizadores sintácticos de estructura de documentos

Un analizador sintáctico (en inglés parser) lee el documento XML y al menos verifica que está
bien formado, aunque algunos también comprueban que el código XML sea válido. El parser es
la herramienta principal de cualquier aplicación XML, permite reconocer las distintas partes de un
documento, trabajar con ellas, modificarlas, ...

Cuando un programa maneja datos en XML, debe incluir un parser. Por ejemplo los navegadores
de última generación incluyen uno. Para programadores que deseen crear sus propias aplicaciones
existen parsers ya implementados y disponibles públicamente como JAXP [55] para Java, Expat
para C [40], etc. Generalmente estos utilizan un API estándar que permite trabajar con ellos. Dos
son las APIs más utilizadas, DOM y SAX:

El API DOM (Document Object Model) [37] fue definida por el W3C, y la versión actual
es DOM level 3. Para cada documento analizado se proporciona una estructura en árbol de
objetos. El modelo de objetos completo se ubica en memoria donde puede ser accedido y
manipulado por el usuario.

El API SAX (Simple API for XML) [111] fue definida por el grupo XML-DEV, siendo la
versión actual SAX 2.0. Es un API basada en eventos, durante el análisis informa a la
6.2. XML 91

aplicación cuando ocurren eventos que considera relevantes (por ejemplo el comienzo o fin
de un elemento XML). No se construye ningún árbol explícito de documento, debe ser la
propia aplicación la que implemente la forma de tratar los diferentes eventos.

Construir un DOM requiere la lectura de toda al estructura XML y mantener el árbol de objetos
en memoria, lo que significa un mayor consumo de recursos. Mientras, SAX es más complejo de
manejar pero optimiza el uso de memoria al mantener en ella sólo lo estrictamente necesario.

6.2.4 La sintaxis de XML

De una manera muy general, un documento XML se compone de las siguientes partes:

Prólogo y declaración de tipo de documento: los documentos XML deben comenzar con
una línea de prólogo que describa la versión de XML, el tipo de documento, etc. Además
también puede existir una segunda línea de declaración de tipo de documento XML que
define el tipo de documento que se está creando. Generalmente esta segunda línea indica la
ubicación de un fichero que contiene el DTD. A veces esta línea es sustituida por un DTD
“inline”, es decir, definido en el propio documento.
Por ejemplo, un prólogo y una línea de declaración de tipo de documento podría ser:

<?xml version="1.0" encoding="UTF-8" ?>

<! DOCTYPE HTML PUBLIC "-/ /W3C/ /DTD HTML 3.2 Final/ /EN">

Elementos: que se nombran como etiquetas (<ejemplo>...</ejemplo>) y se estructuran

de manera jerárquica (mediante anidado). Los elementos pueden contener atributos. A
continuación se muestran algunos ejemplos:

...
<!-- Etiqueta de comentario -->

<!-- Una etiqueta simple -->

<nombre>Fulanito</nombre>

<!-- Una etiqueta con atributos -->

<aviso tipo="tormenta" peligrosidad="8"></aviso>

<!-- La etiqueta anterior abreviada -->

<aviso tipo="tormenta" peligrosidad="8"/>

<!-- Anidado de etiquetas -->

<parrafo>
92 CAPÍTULO 6. RELACIÓN ENTRE WEB Y XML

<linea>Una línea</linea>
<linea>Otra línea</linea>
</parrafo>
...

6.2.5 Otras especificaciones y tecnologías desarrolladas en torno a XML

A continuación se muestra una lista (agrupada por áreas afines) de los distintos trabajos que está
desarrollando el W3C sobre la base de XML1 .

Transformación de documentos

XSL (Extensible Stylesheet Language) es un lenguaje para componer hojas de estilo. Una hoja de
estilo XSL especifica como se obtiene la presentación de una clase de documentos XML. Consta
de tres partes:

Transformaciones XSLT: un lenguaje para transformar documentos XML.

XPath: un lenguaje de expresiones usado por XSLT2 para acceder o referirse a las partes de
un documento XML.

XSL Formatting Objects: un vocabulario XML para especificar la semántica del formateo.

Definición de enlaces entre documentos

Tres especificaciones que se presentan en el W3C hacen referencia a técnicas de construcción de

enlaces entre documentos XML. Muy brevemente:

XML POINTER: define el lenguaje XPointer (XML Pointer Language), que puede
ser utilizado para establecer referencias a fragmentos de recursos de tipo text/xml o
application/xml. Soporta el direccionamiento dentro de las estructuras internas de un
documento XML. Permite referencias internas a propiedades, tipos de elementos, ...

XML BASE: especifica la sintaxis para definir la BASE que se utiliza en los documentos
para resolver URIs relativas.

XML LINKING: define el lenguaje XLink (XML Linking Language), que permite que
ciertos elementos de un documento se utilicen para crear y describir enlaces entre recursos.
Es posible establecer no sólo enlaces unidireccionales (los tradicionales en HTML) si no
también estructuras más complejas.
1 Puede obtenerse más información en el sitio Web del W3C http://www.w3c.org
2Y por otras especificaciones como XML Linking.
6.3. XHTML 93

Temas de seguridad

Existen grupos de trabajo que se están ocupando de temas de seguridad relacionados con XML. Por
ejemplo como representar documentación encriptada (XML Encryption), firmas digitales (XML
signature) o mecanismos de autenticación y autorización mediante una sintaxis XML.

Búsqueda y recuperación de información

EL grupo de trabajo XML Query está estudiando como proporcionar facilidades de búsqueda y
extracción de datos desde documentos en la Web. Intenta proporcionar un medio de comunicación
entre las bases de datos y la Web, siendo el objetivo último poder acceder a colecciones de
documentos XML como si fuesen una base de datos.

Otras líneas de trabajo del W3C

En la W3C existen otras líneas de trabajo muy interesantes relacionadas con la Web, que se
analizan en más profundidad en las secciones posteriores:

XHTML: un nuevo lenguaje para especificar documentos de hipertexto. Es el nuevo

estándar al que ha convergido la especificación de HTML 4.X.

SOAP: implanta la comunicación en un entorno distribuido utilizando XML como lenguaje

para encapsular los mensajes.

6.3 XHTML

6.3.1 Introducción

XHTML [128] es una especificación del W3C, la última versión XHTML1.1 fue publicada el día
31 de mayo de 2001. Define un HTML escrito de forma que cumple las normas sintácticas del
XML. Esta transformación permite que el nuevo lenguaje sea extensible en dos sentidos:

Por un lado los desarrolladores están constantemente introduciendo nuevos métodos para
expresar sus ideas. Para ello introducen etiquetas diferentes. En XML es relativamente fácil
introducir nuevos elementos o atributos. XHTML está diseñado para acomodarse a estas
extensiones utilizando módulos [75].

Por otro lado, los métodos de acceso a Internet están cambiando, ordenadores, móviles,
PDA, etc. XHTML se ha diseñado para proporcionar interoperabilidad con agentes de
usuario generales.
94 CAPÍTULO 6. RELACIÓN ENTRE WEB Y XML

6.3.2 Principales diferencias entre XHTML y HTML 4.X

Las principales diferencias se deben al hecho de que XHTML es una aplicación XML, mientras
que HTML 4.X no lo es. Para conseguir la transformación de documentos HTML 4.X a XHTML
deben seguirse unas normas:

Los nombres de las etiquetas de elementos y de los atributos tienen que estar en minúscula.

Los valores de los atributos tienen que estar entre comillas dobles (") o simples (’).

Todos los elementos tienen que estar cerrados, ya tengan contenido (<p>...</p>) o no
(<br/>).

Los elementos deben de estar correctamente anidados.

Los valores de pares atributo=valor iguales no pueden ser simplificados, por ejemplo <dl
compact=’compact’> no se puede expresar como <dl compact>.

Algunos elementos son obligatorios (html, body, head, etc.)

Se debe incluir una declaración de tipo de documento. Existen tres posibles tipos de
documentos válidos en XHTML:

– strict: se utiliza cuando se da formato a los textos a través de CSS (Cascading Style
Sheets).
– transational: se utiliza cuando no se describe la presentación de los documentos por
medio de hojas de estilo en cascada, prefiriendo la descripción a base de etiquetas. Este
sistema es adecuado cuando se desea facilitar el acceso a usuarios con navegadores sin
posibilidades de tratamiento de CSS.
– frameset: se usa en documentos que incorporan frames.

Si dentro del código se describen elementos que incluyen listados en lenguajes diferentes,
como ocurre con los elementos <script> o <style>, XHTML exige que se acoten los guiones
en una sección CDATA. Las secciones CDATA ignoran el significado de los caracteres que
incluyen, evitando problemas con entidades que puedan confundirse.

Además existen ciertas incompatibilidades en el anidamiento de elementos, por ejemplo,

<a> no puede contener otros elementos <a>.

6.3.3 Un ejemplo sencillo de XHTML

A continuación se muestra un sencillo código de ejemplo. Se trata de un archivo con dos enlaces
a programas gratuitos muy útiles para el trabajo con XHTML:

1. Un validador de documentos (http://validator.w3.org/check/referer)

6.3. XHTML 95

2. Un conversor de HTML a XHTML (http://www.w3.org/People/Raggett/tidy/).

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="sp">

<head>
<title>Mi primera pagina en XHTML</title>
</head>
<body>
<p>Aquí teneis algunos enlaces de interes:</p>
<p><a href="http://validator.w3.org/check/referer">
Validación de documentos on-line</a></p>
<p><a href="http://www.w3.org/People/Raggett/tidy/">
Tidy, convierte de forma automatica HTML a XHTML</a></p>
</body>
</html>

Listado 6.2 Código de una página sencilla en XHTML.

Figura 6.2: Visualización de un ejemplo sencillo en XHTML.

Este ejemplo funcionará da adecuadamente siempre y cuando se disponga de un cliente y un

servidor capaz de manejar XHTML:

Servidor: cualquiera funcionará adecuadamente una vez se haya hecho un pequeño cambio
96 CAPÍTULO 6. RELACIÓN ENTRE WEB Y XML

en la configuración. Se trata de incluir la extensión .xhtml dentro de los tipos MIME que
el servidor Web es capaz de manejar.

Cliente: los navegadores más actuales ya incluyen soporte a XHTML. Por ejemplo un
Netscape Navigator 6.0 mostraría el resultado de la figura (figura 6.2).

6.4 SOAP

6.4.1 Introducción

SOAP (Simple Object Access Protocol) [118] es un protocolo ligero para intercambio de
información en un entorno distribuido. Se basa en XML, siendo la versión actual SOAP 1.2,
en ella se definen en cuatro partes:

Un marco de trabajo que describe qué es un mensaje y como procesarlo.

Un conjunto de reglas de codificación para expresar instancias de diversos tipos de datos

definidos por aplicaciones.

Una convención que indica como representar las llamadas a procedimientos remotos y las
respuestas de estos.

La descripción de una capa de enlace para intercambiar mensajes sobre un protocolo

subyacente. Aunque potencialmente SOAP puede funcionar sobre cualquier protocolo, la
versión 1.2 sólo define la capa de enlace para HTTP.

6.4.2 Antecedentes

SOAP no intenta solucionar un problema nuevo, hace ya bastantes años que surgió la necesidad
de obtener acceso distribuido a objetos y realizar llamadas a procedimientos remotos. Una de
las soluciones clásicas es RPC (Remote Procedure Call), pero no es la única. Muchas otras
tecnologías han abordado este problema proporcionando buenas soluciones, pero casi todas pecan
de ser cerradas, es decir, específicas para un lenguaje o plataforma. Dos son los ejemplos más
conocidos:

DCOM (Distributed Component Object Model) permite a objetos en cualquier lenguaje

comunicarse pero sólo en plataformas Windows.

RMI (Remote Method Invocation), en cambio, permite la comunicación sobre cualquier

plataforma, pero sólo en lenguaje Java.
6.4. SOAP 97

Pero también se ha trabajado en soluciones capaces de posibilitar la comunicación sea cual sea
la plataforma o el lenguaje, por ejemplo CORBA. CORBA (Commom Object Request Broker
Arquitecture) es una tecnología que está ampliamente disponible y proporciona tanto capacidad
de comunicación como interoperabilidad. En el lado negativo, CORBA es bastante complejo y
pesado, requiriendo de un período de aprendizaje alto que desanima a muchos programadores.
Llegados a este punto se constata la necesidad de alguna tecnología que sea a la vez útil y
que solucione los problemas de protocolos cerrados y/o complejos. Se busca que la creación
de aplicaciones distribuidas sea lo más sencilla posible, y que se permita la interoperabilidad
independientemente de lenguajes y plataformas.
El primer intento, XML-RPC, proporciona un mecanismo simple para realizar llamadas a
procedimientos remotos apoyándose en datos codificados con XML y transmitidos sobre HTTP.
Aunque la idea era buena, pronto surgió una gran limitación, XML-RPC no podía manejar
estructuras de datos complejas. SOAP surge como una segunda respuesta. La idea de
SOAP apareció en el mundo empresarial (grandes marcas como Microsoft, IBM, etc.), pero ha
evolucionado hasta llegar a ser un proyecto del W3C. Su desarrollo le ha sido asignado a un grupo
de trabajo (XML Protocol), lo que le da el caracter de protocolo abierto y a la vez un fuerte impulso.

6.4.3 Estructura de funcionamiento SOAP sobre HTTP

SOAP parte de una idea simple, garantizar la comunicación entre equipos heterogéneos, basándose
en protocolos preexistentes, muy extendidos e implementados (como HTTP y XML).

Figura 6.3: Esquema de invocación a un método con SOAP sobre HTTP.

HTTP fue tratado en profundidad en un capítulo anterior (vea el capítulo 2 en la página 19),
pero se pueden recordar algunas características relevantes. HTTP es básicamente un protocolo
sin estados que funciona bajo el paradigma cliente/servidor. Proporciona una comunicación
basada en mensajes de petición y respuesta. Estos mensajes están formados por dos partes
diferenciadas (cabeceras y cuerpo). Añadiendo nuevas cabeceras pueden desarrollarse nuevos
protocolos especializados. SOAP se aprovecha de esto para su implementación sobre HTTP.
98 CAPÍTULO 6. RELACIÓN ENTRE WEB Y XML

De XML ya se han comentado algunos aspectos en las secciones anteriores, simplemente recordar
que es un lenguaje muy extensible. SOAP utiliza esta característica y maneja una serie de mensajes
en XML. Los mensajes SOAP tienen dos partes, una cabecera opcional y un cuerpo, dispuestos
dentro de una envoltura (envelope).
Se analizan a continuación los pasos para una comunicación simple sobre HTTP y SOAP (figura
6.3).

Construir invocación en cliente

El cliente SOAP quiere invocar un método en un objeto particular del servidor. El método y los
parámetros asociados se codifican en el cuerpo de un documento XML. Por ejemplo:

<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

<env:Body>
<m:GetLastTradePrice
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://example.org/2001/06/quotes">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</env:Body>
</env:Envelope>

El cliente envía la solicitud HTTP

El cliente envía una solicitud HTTP que incluye una nueva cabecera (SOAPAction), y el
documento XML anterior. Por ejemplo:

POST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://example.org/2001/06/quotes"

<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

...
</env:Envelope>

El servidor recibe petición HTTP

El servidor Web recibe la petición. A veces al servidor Web se le llama proxy SOAP, ya que no
procesa por si mismo la petición, sólo actúa de intermediario para un nodo SOAP3 .
3 Programa capaz de procesar los mensajes SOAP según lo definido en la especificación.
6.5. OTRAS APLICACIONES RELACIONADOS CON XML Y LA WEB 99

La cabecera HTTP SOAPAction suele estar asociada con el nombre del objeto al que se está
invocando. Por ejemplo, SOAPAction: "http://example.org/2001/06/quotes" se refiere
al objeto quotes.

Proceso de petición SOAP

El nodo SOAP recibe la petición en XML, la interpreta e invoca la ejecución del método solicitado.
Los resultados de la ejecución son encapsulados en un mensaje SOAP de respuesta.

<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

<env:Body>
<m:GetLastTradePriceResponse
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://example.org/2001/06/quotes">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</env:Body>
</env:Envelope>

Respuesta HTTP

El servidor Web se hace con el control para enviar la respuesta recibida del nodo SOAP, en un
mensaje HTTP. Por ejemplo:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >

...
</env:Envelope>

El cliente recibe la respuesta

El cliente recibe la respuesta del servidor Web, para procesar correctamente la misma es necesario
que incorpore capacidades de análisis XML.

6.5 Otras aplicaciones relacionados con XML y la Web

A parte de los proyectos iniciados directamente por el W3C, existen incontables aplicaciones que
relacionan el Web con XML.
100 CAPÍTULO 6. RELACIÓN ENTRE WEB Y XML

Cada día hay más implementaciones de parsers, procesadores de hojas de estilo, protocolos como
SOAP, etc. Incluso importantes organizaciones como la Apache Software Foundation ha creado
un grupo (Apache XML [129]) que se ocupa de la construcción de herramientas basadas en XML
con calidad comercial, respetando los estándares y de código abierto. Algunos de los proyectos
actuales son:

Un parser (Xerces) y un procesador de hojas de estilo (Xalan).

Una implementación de SOAP.

Cocoon, un marco de trabajo para la publicación Web basada en XML.

Xang, una herramienta de desarrollo rápido de aplicaciones del lado servidor basada en
HTTP, XML, y JavaScript.

...

Otra aplicación relacionada muy interesante, es WebDAV, una especificación del W3C que
extiende al HTTP e intercambia mensajes en XML. Se trata más en detalle en el siguiente capítulo.
Capítulo 7

Gestión de recursos remotos

Contenidos de este capítulo

7.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.2 FrontPage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.3 WebDav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.3.2 Posibles usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.3.3 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.3.4 Aplicaciones que soportan WebDAV . . . . . . . . . . . . . . . . . . . 104

7.1 Introducción

En los comienzos del Web (en 1990), Tim Berners-Lee desarrolló un primer prototipo de
navegador con capacidades de lectura y escritura1 . Más adelante, NCSA Mosaic se convirtió en el
navegador de referencia y la capacidad de escritura pasó a un segundo plano, no siendo utilizada
durante bastante tiempo.

Fue en 1995, cuando aparecen nuevas tecnologías (como FrontPage) capaces de utilizar
propiedades de escritura sobre la base del protocolo HTTP. Desde ese momento, más y más
herramientas (procesadores de texto, manipuladores de imágenes, etc.) han ido ofreciendo soporte
para publicar en servidores Web.

Las primeras tecnologías para la creación y gestión de documentos remotos coincidían en un

punto, necesitaban ampliar la funcionalidad de HTTP. Tecnologías como Frontpage han añadido
este soporte, pero trabajando de manera aislada, impidiendo la interoperabilidad. El siguiente paso
es WebDAV2 que extiende HTTP proporcionando un conjunto de estándares abiertos que pueden
ser utilizados por las herramientas que lo deseen.
1 Escritura,publicación Web o gestión de recursos remotos.
2 Muchas veces llamado simplemente DAV.

101
102 CAPÍTULO 7. GESTIÓN DE RECURSOS REMOTOS

En las siguientes secciones se analizan estas dos soluciones para proporcionar la gestión de
recursos remotos. Se hará más hincapié en WebDAV, ya que es un estándar del W3C y actualmente
incluso Microsoft (propietario de FrontPage) le está dando su apoyo.

7.2 FrontPage

FrontPage es un programa de creación de sitios HTML, en un orden cronológico, fue de los

primeros clientes que soportaron gestión remota de documentos sobre HTTP (incluso con una
versión segura basada en SSL).

La contrapartida en el lado servidor son una serie de herramientas llamadas extensiones FrontPage.
Estas extensiones implementan un conjunto de mejoras basadas en los métodos PUT y DELETE
definidos por HTTP. Se definen también mecanismos para gestión de bloqueos y autenticación.

FrontPage es una tecnología propietaria de Microsoft, e inicialmente se integraba en los servidores

Web ofrecidos por esa empresa (por ejemplo Internet Information Server). Actualmente las
extensiones de FrontPage están también disponibles para plataformas Linux/Unix, permitiendo
a servidores como Apache, Netscape, etc, ofrecer soporte a las mismas.

7.3 WebDav

7.3.1 Introducción

WebDAV (Web Distributed Authoring and Versioning) que ha sido descrito en el RFC 2518 [106],
es un protocolo de red que extiende a HTTP. Los programas clientes que soportan WebDAV
hacen fácil que personas dispersas geográficamente puedan trabajar de manera conjunta sobre
documentos alojados en un servidor Web (imágenes, páginas Web, documentos Microsoft Office,
etc.).

Muchas aplicaciones bien conocidas integran ya soporte WebDAV, incluso las nuevas versiones de
sistemas operativos Windows utilizan Web Folders, que no son más que clientes de WebDAV.

El protocolo ha sido desarrollado por el WebDAV Working Group del IETF, y proporciona una
infraestructura abierta y basada en estándares para la creación y mantenimiento de documentos de
manera distribuida.

7.3.2 Posibles usos

Hay muchas situaciones en las que WebDAV puede ser muy útil (figura 7.1). Todas ellas tienen
en común la necesidad de crear páginas Web (u otros documentos) de manera remota. Como
ejemplos de estas posibles situaciones:
7.3. WEBDAV 103

Figura 7.1: Ejemplo de colaboración usando WebDAV.

Un grupo de trabajo de una misma empresa, distribuido geográficamente en unidades de

negocio que necesita desarrollar documentos de manera conjunta.

Un usuario particular, con pocos conocimientos sobre Internet (FTP, etc.) pero que desea
crear un sitio Web. WebDAV es una solución muy cómoda en este caso, ya que es probable
que este usuario conozca alguna aplicación de uso común (como Microsoft Word) que
proporcionan soporte DAV.

Un ISP (proveedor de servicios Internet) que aloja páginas, ofrece acceso mediante
WebDAV evitando así los problemas de seguridad inherentes a ofrecer cuentas de acceso
FTP o shell.

Un equipo de desarrollo Web disperso geográficamente, que trabaja en el mismo proyecto y

donde todos los miembros pueden realizar actualizaciones del sitio Web.

Un sitio Web corporativo que necesita aceptar contribuciones a sus contenidos desde varias
unidades de negocio de la empresa que se encuentran distribuidas geográficamente.

7.3.3 Características

El protocolo WebDAV extiende las capacidades de HTTP con seis nuevas características:

Protección ante escritura: necesaria para mantener a más de un usuario trabajando en un

documento con la seguridad de no “perder actualizaciones”. El problema se produce cuando
un usuario graba sus cambios machacando accidentalmente los datos que previamente había
modificado otra persona.
WebDAV proporciona un sistema de bloqueos de escritura exclusivos, que garantizan que
sólo el poseedor del bloqueo puede escribir en el recurso. Existen temporizadores asociados
a cada bloqueo de manera que este se libera pasada una determinada cantidad de tiempo.
Los bloqueos son independientes de las conexiones TCP3 , puede darse el caso de estar
3 Este esquema de trabajo es muy útil en las redes actuales donde no es extraño que se pierdan las conexiones.
104 CAPÍTULO 7. GESTIÓN DE RECURSOS REMOTOS

trabajando con un bloqueo, perder la conexión de red, y luego reconectarse para terminar
las actualizaciones.

Propiedades o metadatos: creación, borrado y recuperación de metainformación (autor, última

modificación, etc.) sobre los recursos. Las propiedades WebDAV se definen con pares
(nombre, valor) donde el nombre es una URL y el valor es una expresión bien formada
en XML. Al utilizar XML, WebDAV permite el almacenamiento de multitud de valores4 y
se beneficia de otras características como la extensibilidad, soporte para enlaces XLink y
valores RDF, ...

Gestión del espacio de nombres: es posible copiar, mover y borrar recursos dentro de los
espacios de nombres del servidor. También se puede crear nuevas colecciones y listar sus
contenidos. Estas operaciones podrían compararse con las que se realizan en un sistema de
ficheros.

Gestión de versiones: soporta el almacenamiento de revisiones de documentos importantes para

una posterior recuperación. También se soporta la colaboración, permitiendo a dos o más
autores trabajar en el mismo documento en paralelo. Existe la posibilidad de registro
automático, que almacena versiones aunque el cliente WebDAV no sea capaz de manejarlas.

Colecciones avanzadas: las colecciones avanzadas de recursos pueden ser tanto referencias,
como colecciones ordenadas por el cliente. Proporcionan un mecanismo para la
organización jerárquica de recursos en la red.
Las referencias a recursos actúan como enlaces simbólicos que pueden ser reutilizados en
múltiples colecciones, también permiten que la colección contenga recursos no HTTP.
Las colecciones ordenadas según lo establecido por el cliente también pueden ser útiles.
Por ejemplo en colecciones que se ordenan para mejor comprensión por parte de un lector
humano (como los capítulo de un libro).

Control de acceso: limita los derechos de acceso a un determinado recurso. WebDAV asume que
todas las aplicaciones WebDAV soportan el protocolo de autenticación sobre HTTP basado
en resúmenes (HTTP Digest Authentication)[108].

7.3.4 Aplicaciones que soportan WebDAV

Se presentan a continuación tres tablas con listas de aplicaciones con soporte DAV. La primera
(tabla 7.1) presenta un listado de servidores, la segunda (tabla 7.2) es un listado de aplicaciones
para creación de documentos y la tercera (tabla 7.3) recoge aplicaciones que emulan el
funcionamiento de gestores de ficheros. La información para construir estas tablas ha sido
obtenida de la página Web http://www.webdav.org y no pretende ser completa.

4 Prácticamente cualquier cosa, dependiendo del DTD.

7.3. WEBDAV 105

Apache con mod_dav Microsoft IIS 5 Microsoft Exchange 2000

Microsoft Sharepoint Adobe InScope Oracle Internet File System
Xythos Storage Server Novell Netware 5.1 Novell Net Publisher
Endeavors MagiExpress W3C Jigsaw IBM DAV4J
CyberTeams WebSite HyperWave Information Openlink Virtuoso
Director Server 5.5

Tabla 7.1: Servidores con soporte WebDAV.

Microsoft Office 2000 Adobe Photoshop 6 Adobe Acrobat 5

Excosoft Documentor Adobe Go Live 5 Macromedia Dreamweaver 4
(XML Editor)

Tabla 7.2: Herramientas de creación de documentos con soporte WebDAV.

WebDAV Explorer Apple MacOS X webdavfs Linux davfs

GNOME Nautilus Goliath cadaver

Tabla 7.3: Herramientas de gestión de ficheros con soporte WebDAV.

106 CAPÍTULO 7. GESTIÓN DE RECURSOS REMOTOS
Capítulo 8

Bases de datos y búsqueda en la Web

Contenidos de este capítulo

8.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

8.2 Sistemas gestores de bases de datos . . . . . . . . . . . . . . . . . . . . . . 108
8.2.1 MySql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.2.2 mSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.2.3 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.2.4 Soluciones comerciales . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.3 Acceso a datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.3.1 Interfaces de acceso a datos . . . . . . . . . . . . . . . . . . . . . . . 113
8.3.2 Ejemplos de acceso a datos con distintas tecnologías Web . . . . . . . 115
8.4 Búsqueda en la Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.4.2 Funcionamiento de un buscador . . . . . . . . . . . . . . . . . . . . . 121
8.4.3 Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
8.4.4 Indexador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.4.5 Motor de búsqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
8.4.6 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

8.1 Introducción

Casi cualquier aplicación basada en Web necesita manejar algunos datos. Aunque existen muchas
maneras de almacenar la información (desde el propio sistema de ficheros, hasta los servidores de
directorio), lo más extendido es utilizar BBDDs (bases de datos). Cuestiones como la eficiencia
de actualización y búsqueda llevan a esta elección.

107
108 CAPÍTULO 8. BASES DE DATOS Y BÚSQUEDA EN LA WEB

En este capítulo se cubren varios aspectos relacionados con la BBDDs. Por un lado se da una
visión general de algunos de los SGBD (sistemas gestores de bases de datos) más extendidos y se
comentan tecnologías que permiten a una aplicación Web utilizarlos. Por el otro lado se incluye
una sección donde se describen los aspectos teóricos de un buscador, una de las aplicaciones Web
que hace un uso más intensivo de los sistemas de bases de datos.

8.2 Sistemas gestores de bases de datos

Una BBDDs es un conjunto de datos con relación lógica. Un SGBD es un programa capaz
de gestionar adecuadamente las BBDDs. Actualmente casi todos los SGBD implementan los
conceptos descritos en la teoría relacional. Un SGBDR (sistema gestor de bases de datos
relacional) almacena la información en tablas organizadas lógicamente que se enlazan definiendo
relaciones y contienen datos. El lenguaje de consulta SQL (Structured Query Language), que ha
sido estandarizado por la ISO [51], proporciona la recuperación y gestión de estos datos.
Generalmente las BBDDs1 manejan transacciones, que deben cumplir una serie de propiedades.
Se les suele llamar propiedades ACID (Atomicity, Consistency, Isolation, Durability):


Atomocity (atomicidad): en una transacción, la atomicidad garantiza que o se ejecutan todas

las acciones o no lo hace ninguna.


Consistency (consistencia): surge como una necesidad cuando hay muchos usuarios
accediendo a la base de datos de manera concurrente. La consistencia garantiza que en
estos casos se mantiene la integridad de la información.


Isolation (aislamiento): garantiza que las transacciones que se están realizando

concurrentemente en el sistema no se interfieran entre ellas. EL aislamiento hace referencia
a las medidas que toma el SGBD para garantizar este punto.


Durability (durabilidad): garantiza que una transacción que finaliza correctamente (commit)
queda adecuadamente reflejada. Independientemente de fallos físicos (como por ejemplo
en el disco duro), el sistema será capaz de recordar todas la transacciones que han sido
realizadas.

Los SGBDR suelen incluir herramientas de administración que permiten ajustar el rendimiento en
función de las necesidades particulares. Este no es un trabajo trivial, de hecho el administrador
de BBDDs debería ser un profesional muy bien formado. Muchas empresas cuentan son sus
propios administradores de bases de datos, pero también hay muchas otras que no, en ellas lo
más probable es que el Webmaster termine administrando también las BBDDs. En estos casos le
será muy necesario tener algún conocimiento sobre el tema, por eso. en las siguientes secciones
se presentan algunos de los sistemas gestores de bases de datos más utilizadas en las aplicaciones
Web.
1 A veces, como en este capítulo, se abusa del lenguaje y se utiliza este término para referirse indistintamente al

SGBD y a la propia BBDD.

8.2. SISTEMAS GESTORES DE BASES DE DATOS 109

8.2.1 MySql

MySQL [8] [78], es una de las bases de datos relacional de código abierto más popular en Internet.
Existen distribuciones para distintas plataformas (Win32/NT, Unix/Linux), y en muchas de ellas
se instala por defecto (por ejemplo en los Red Hat Linux). Actualmente es propiedad de MySQL
AB (una empresa sueca), que se encarga de su desarrollo y ofrece servicios auxiliares (consultoría,
soporte técnico, etc.). Aunque el software es gratuito, su uso en según que aplicaciones está sujeto
a licencia de pago.

Características:

MySQL originalmente se desarrolló pensando en el manejo rápido y sencillo de grandes bases

de datos2 . Actualmente sigue en desarrollo y el producto obtenido es rápido, confiable, fácil de
manejar, ofrece conectividad desde distintas tecnologías, etc.

MySQL utiliza el paradigma de los sistemas cliente/servidor, implementando un servidor SQL

multihilo que soporta conectividad con diversos programas clientes, bibliotecas, herramientas de
administración e interfaces de programación. MySQL AB también proporciona una biblioteca
que puede utilizarse para integrar soporte MySQL en aplicaciones propias. De esta manera se
consiguen productos que proporcionan un acceso a BBDDs MySQL de manera más rápida y
fácil de gestionar. Actualmente son muchas las aplicaciones de terceras partes que soportan la
conectividad con MySQL (clientes de base de datos, lenguajes, etc.).

Compatibilidad ANSI/ISO SQL 92

Aunque MySQL se basa en el estándar ANSI/ISO SQL 92, existen algunas diferencias. Como es
lógico un sistema que utilice alguna de estas, dejará de ser portable a otros SGBDs compatibles
con SQL 92. Las diferencias más importantes de describen en la siguiente lista:

Ciertas características de SQL 92 se implementan de manera ligeramente diferente a la

indicada en la especificación. Por ejemplo en las columnas de tipo VARCHAR los espacios
finales son eliminados antes de almacenar el valor.


Se incluyen ciertas extensiones a SQL 92. Por ejemplo Like puede ser utilizado en campos
numéricos.


Además hay ciertas partes de SQL 92 que directamente no se implementan; para ellas la
documentación de MySQL proporcionan diversas alternativas. Quizá el caso más relevante
sea la falta de soporte a transacciones. MySQL tomó la decisión de utilizar otro paradigma,
llamado operaciones atómicas. Los desarrolladores de MySQL consideran que este sistema
garantiza la integridad sobre la BBDDs, a la vez que proporciona un mejor rendimiento. De
2 Frente a las soluciones comerciales disponibles en el mercado, que suelen ser complejas e incluso lentas
110 CAPÍTULO 8. BASES DE DATOS Y BÚSQUEDA EN LA WEB

todas formas MySQL no le da la espalda a las transacciones y planean su implementación

en futuras versiones.


Otras características no implementadas por ahora son sub-selecciones, restricciones

impuestas por claves foráneas (Foreign Key), vistas, ...

Para la descarga del software u obtención de más información puede visitar el sitio Web sobre
MySQL (http://www.mysql.com/).

8.2.2 mSQL

mSQL [77] (Mini SQL) es un gestor de bases de datos ligero, diseñado para proporcionar acceso
rápido a conjuntos relativamente pequeños de datos almacenados en sistemas con poca memoria.
Implementa un subconjunto de SQL e inicialmente fue desarrollado como un proyecto académico
en código abierto. Actualmente las últimas versiones estables son las numeradas como mSQL
2.X, aunque ya existen versiones Beta del nuevo mSQL 3.0.
Las primeras versiones de mSQL (msql 1.X) alcanzaron sus objetivos, son motores muy rápidos
sobre conjuntos de datos pequeños. Debido a ello y a su carácter de código abierto, se
popularizaron rápidamente en Internet. Pero estaban muy limitados y no son la elección adecuada
si se deben manejar aplicaciones con fuertes cargas de datos (más de 1 millón de registros) o que
necesiten de consultas SQL complejas.
Las nuevas versiones (de 2.X en adelante) tratan de conseguir los siguientes objetivos:

Proporcionar en operaciones simples el mismo rendimiento que con mSQL 1.X.



Conseguir acceso rápido a bases de datos con gran cantidad de datos o accedidas mediante
operaciones complejas.


Completar la implementación con otras funcionalidades definidas en la especificación ANSI

SQL.

El servidor de mSQL 2.X es capaz de servir múltiples peticiones simultáneas, para ello se utiliza
un esquema basado en un proceso principal y varios procesos hijos. El proceso principal es capaz
de aceptar conexiones de clientes, gestionar la distribución de trabajo entre los procesos hijos
y realizar otras tareas de administración. mSQL 2.0 implementa bloqueos a nivel de tabla, que
permiten lecturas compartidas y escritura exclusiva. El uso de bloqueos es el primer paso hacia el
soporte de transacciones, pero hoy por hoy mSQL aún no soporta transacciones.
El desarrollo de mSQL continúa, aunque parece que el producto ha perdido algo de fuerza con
respecto a su más directo competidor MySQL; es posible que haya influido el cambio en las
condiciones de licencia, ahora para un uso comercial del software se exige el pago de licencia.
Para conseguir una versión del software, documentación, comprobar las condiciones de licencia,
etc, puede visitarse el sitio de mSQL (http://www.hughes.com.au).
8.2. SISTEMAS GESTORES DE BASES DE DATOS 111

8.2.3 PostgreSQL

PostgreSQL [90] es un gestor de bases de datos Relacional-Objetual. Es uno de los SGBDR Open-
Source con más “solera”, la primera versión es de 1985 y actualmente se distribuye PostgreSQL
7.X. Está muy extendido, sobre todo en el mundo Unix/Linux (muchas distribuciones Linux, como
Red Hat lo instalan por defecto), aunque existen versiones para plataformas Windows. Entre sus
ventajas comentar:

Soporta casi todas las construcciones SQL, incluso extensiones orientadas a objetos (como
por ejemplo la posibilidad de definir tablas mediante herencia), en este sentido es el motor
de BBDDs en código abierto más avanzado. Entre las construcciones soportadas se pueden
destacar:

– Transacciones.
– Vistas.
– Triggers.
– ...


Amplia conectividad a través de:

– C, C++ y C embebido
– Perl (perl5)
– Python (PyGreSQL)
– TCL (libpgtcl)
– PHP
– JDBC y ODBC
– ...


Diversidad de herramientas disponibles:

– Herramientas de administración: copias de seguridad (pg_dump) y restauración

(pg_restore),
– Conexión segura de acceso a datos sobre SSL y SSH.
– Clientes, como por ejemplo pgaccess, una interface gráfica en TCL/TK para la
administración.
– ...

El mayor problema que se le achaca es su lentitud frente a otras opciones en código libre
como mSQL o MySQL. Para más información puede visitarse el sitio Web de PostgreSQL
http://www.postgresql.org/.
112 CAPÍTULO 8. BASES DE DATOS Y BÚSQUEDA EN LA WEB

8.2.4 Soluciones comerciales

Desde que la tecnología de las bases de datos vio la luz, hace ya bastantes años, han surgido
múltiples soluciones comerciales3 . Una de las tendencias más claras en la Web actual es
integrar fuertemente el acceso a datos en los servidores de aplicaciones. Esta tendencia llevada
a sus extremos hace que casi todos los fabricantes de SGBDs comerciales ofrezcan sus propios
servidores de aplicaciones que se integran a bajo nivel con los productos de bases de datos de la
misma empresa. Como ejemplos Sybase Enterprise Server y Oracle Application Server. Pero el
campo de los servidores de aplicaciones ya fue tratado en un capítulo anterior (vea la sección 1.3
en la página 6), ahora nos centraremos en los sistemas gestores de bases de datos:

Informix: [48] los productos de Informix han sido líderes en el mercado durante mucho
tiempo, actualmente esta empresa es propiedad de IBM. Más información en http://www.
informix.com.

Microsoft SQL Server: [67] es el SGBD más potente que ofrece Microsoft (frente a otros
productos de escritorio como Access). Se integra fuertemente en la nueva plataforma .NET
y funciona sobre Windows NT/2000. Más información en http://www.microsoft.com/
sql/default.asp.

Sybase Adaptative Server: [120] proporciona una plataforma diseñada para soportar
aplicaciones que utilizan transacciones de manera intensiva. Más información en http:
//www.sybase.com.

Pero quizás sean los sistemas gestores de bases de datos de la compañía Oracle [85] los que
tienen mayor presencia en la Web actual. Estos sistemas alardean de ser poderosos, configurables,
escalables y confiables. Proporcionan bastantes funcionalidades, muchas de ellas no soportadas
por los SGBD de código libre. Por ejemplo los productos de Oracle ofrecen soporte completo a:

Transacciones.

Concurrencia y consistencia.


Replicación y confiabilidad.

Optimizadores de ejecución basados en costes o en reglas.

Ejecución paralela.


Redo logs.

DataMining
3 Este campo mueve mucho dinero, de hecho el dueño de Oracle (una conocida marca de software dedicada a las

BBDDs) es hoy en día uno de los hombre más ricos del mundo.
8.3. ACCESO A DATOS 113

...

Pero también hay características negativas:

No son gratuitos.


Debido a la cantidad de funcionalidades extendidas, provocan una gran sobrecarga en los

recursos de la máquina. Por ello no funcionan en cualquier equipo, necesitan una máquina
potente.


Las múltiples posibilidades de configuración hacen necesario que los administradores de

BBDDs Oracle sean profesionales muy experimentados.


...

Pero con sus pros y sus contras los sistemas gestores de bases de datos de Oracle siguen siendo de
los más extendidos en el mercado y pueden ser una buena solución si realmente se necesita trabajar
en BBDDs muy grandes (Tbytes de datos) a unas velocidades aceptables. Más información sobre
los productos de Oracle en el sitio Web http://www.oracle.com.

8.3 Acceso a datos

8.3.1 Interfaces de acceso a datos

Muchos servidores de BBDDs utilizan protocolos específicos de la marca, lo que obliga a aprender
un lenguaje nuevo para trabajar con cada uno de ellos. Pero es posible “limar” las diferencias
mediante alguna interface de alto nivel (figura 8.1).

Figura 8.1: Arquitectura genérica de interfaces de acceso a datos.

Estas interfaces encapsulan los aspectos genéricos del servicio:

114 CAPÍTULO 8. BASES DE DATOS Y BÚSQUEDA EN LA WEB

Solicitar una conexión o desconexión.

Recuperar y añadir datos.

...

Diversas son las tecnologías que abstraen las complejidades subyacentes de cada producto y
proporcionan una interface común (basada en SQL) para el acceso homogéneo a los datos. A
continuación se comentan algunas de las más importantes:

ODBC: [65] Microsoft estableció una norma común para comunicarse con las bases de datos,
llamada ODBC (Open DataBase Conectivity). Se apoya en un amplio conjunto de drivers
ODBC. Estos drivers entienden una serie de funciones que permiten utilizar el lenguaje
SQL estándar y las traduce a la base de datos subyacente. ODBC permite la conexión fácil
desde varios lenguajes de programación, y tiene mucha aceptación, sobre todo en entornos
Windows. En plataformas Linux/Unix su uso no es tan cómodo y suelen utilizarse otras
alternativas. Sobre ODBC Microsoft está construyendo sus extensiones de “acceso universal
a datos” (Ole DB, ADO, etc.). La versión actual es ODBC 3.0 y se puede encontrar más
información en http://www.microsoft.com/data/.

Perl:DBI: [32] Perl es uno de los lenguajes más utilizados para programación en la Web y
proporciona su propia interface de acceso a datos, llamada DBI (DataBase Interface). Es
especialmente utilizado bajo plataformas Linux/Unix, solucionando las complejidades de
ODBC en estos sistemas. DBI actúa como una abstracción para un conjunto de módulos
DBD (DataBase Driver). Cada módulo DBD actúa como manejador de un sistema gestor
de base de datos distinto. Existen módulos para prácticamente cualquier SGBD (Oracle,
Informix, MySQL, etc.) y puentes hacia otras tecnologías como ADO, JDBC ...

Actualmente algunas distribuciones de Perl se acompañan con el DBI y los drivers más
habituales, aunque en otras no (como por ejemplo Red Hat). Pueden descargarse en
cualquier mirror del CPAN (Comprehensive Perl Archive Network) http://www.cpan.
org/.

JDBC: [57] Java intenta proporcionar una plataforma segura, flexible y completa para desarrollo
de aplicaciones en Internet. En ella no podía faltar una solución a la conectividad con bases
de datos, JDBC4 . JDBC es el estándar para la conectividad entre el lenguaje Java y un
amplio rango de sistemas gestores de BBDDs. Hay diversos tipos de controladores JDBC:

El puente JDBC-OBDC: fue uno de los primeros controladores disponibles,

implementa un enlace para utilizar un controlador ODBC desde Java. Con el tiempo
han surgido controladores JDBC específicos para cada base de datos que mejoran el
rendimiento del puente JDBC-ODBC.
4 JDBC son unas siglas que no significan nada, aunque se suelen asociar con Java BataBase Conectivity.
8.3. ACCESO A DATOS 115

Controladores Java parcialmente nativos: usan tanto código Java como binario
específico de cada plataforma.


Controladores JDBC-Net de Java puro: son controladores escritos completamente en

Java que entienden un protocolo de red estándar (HTTP, etc.) y permiten comunicarse
con un servidor de acceso a bases de datos, que es el que finalmente provee el acceso
al SGBD específico (posiblemente con ODBC).


Controladores de protocolo nativo en Java puro: escritos en Java puro, utilizan el

protocolo específico de la marca del SGBD.

La versión actual del API es JDBC 3.0. Puede encontrarse más información sobre ella en el
sitio de SUN http://java.sun.com/products/jdbc/.

8.3.2 Ejemplos de acceso a datos con distintas tecnologías Web

Prácticamente todas las tecnologías que extienden la funcionalidad del servidor Web implementan
algún tipo de pasarela que proporciona el acceso a datos. En esta sección se ilustra como acceder
a una base de datos MySQL con algunas de ellas. Se utilizará una sola tabla (clientes) con varios
campos (Nombre, Apellidos, Dni, Teléfono, Email). El ejemplo consistirá en recuperar todos los
datos de esta tabla y mostrarlos en una página HTML.

Conectividad desde CGI

La primera opción para acceder a las bases de datos es programar scripts CGI. Para ello se puede
utilizar cualquier lenguaje, siempre y cuando el SGBD proporcione alguna biblioteca de acceso.
Pero este acceso directo esconde bastantes complejidades para el programador (mantenimiento de
sesiones, etc.). Existen algunos proyectos que intentan hacer más cómodo el trabajo. Una de las
soluciones más difundidas es utilizar Perl junto con DBI.

Para que el ejemplo propuesto funcione, antes de nada, se debe conseguir una versión del DBI y
un driver DBD para MySQL5 . Una vez instalados puede probarse el siguiente código:

#!/usr/bin/perl

use DBI;
use CGI;
use strict;

my ($cgi) = new CGI;

my ($host) = "localhost";
my ($usuario) = "root";
5 Ambos disponibles en el sitio Web del CPAN http://www.cpan.org/.
116 CAPÍTULO 8. BASES DE DATOS Y BÚSQUEDA EN LA WEB

my ($clave) = "";
my ($basedatoss) = "ejemplo";

# Manejadores de base de datos, consulta y resultados

my ($dbh, $sth);
my (@datos);

# Cadena de conexion
my ($dsn) = "DBI:mysql:$basedatos:$host";

print $cgi->header;

# Conectar a base de datos

$dbh = DBI->connect ($dsn, $usuario, $clave, {RaiseError=>1});

# Preparar consulta
$sth = $dbh->prepare ("SELECT * FROM clientes");
$sth->execute ();

# Presentar resultados
while (@datos = $sth->fetchrow_array ()){
print join ("\t", @datos), "\n";
}

$sth->finish;
$dbh->disconnect ();
exit (0);

Listado 8.1 Acceso a bases de datos MySQL desde un script cgi en Perl.

ASP

ASP proporciona acceso a datos apoyándose en los objetos ADO (ActiveX Data Objects) y
ODBC6 . El uso de la interface ODBC le permite a ASP trabajar sobre cualquier sistema gestor
de bases de datos que proporcione un driver (MySQL, SQL Server, Oracle, Informix, etc.).

Los objetos ADO, basados en la tecnología COM (Component Object Model)7 , ofrecen métodos
que encapsulan el acceso a datos para su utilización en páginas ASP (Connection, RecordSet,
6 Las nuevas versiones pueden apoyarse en OLE DB, que es la mejora a ODBC que se incluye en la nueva plataforma

.NET de Microsoft.
7 Y el nuevo DCOM de la plataforma .NET de Microsoft.
8.3. ACCESO A DATOS 117

Command, etc.).

Para el ejemplo propuesto, se puede utilizar ASP sobre un Internet Information Server
ejecutándose en un Windows NT Server 4.0. Antes de poder probar el ejemplo se necesita dar de
alta un DSN (Data Source Name) que asocia el SGBD (MySQL), el nombre de la fuente de datos
(ejemplo) y un driver ODBC para MySQL8 . Una vez hecho esto sólo queda probar el siguiente
código:

<html>
<head>
<title>Acceso a base de datos desde ASP</title>
</head>
<body>
<%
‘declaración de variables
Dim objConex, objRset, consulta
‘se crea una instancia de un objeto ADO de tipo Connection
Set objConex = Server.CreateObject("ADODB.Connection")
‘se utiliza el método Open del objeto Connection para enlazar
‘al objeto con base de datos
objConex.Open "ejemplo"
‘indicamos la consulta SQL que se va a ejecutar
consulta = "SELECT * FROM clientes"
‘se ejecuta la consulta y se devuelve el resultado en un
‘objeto ADO de tipo RecordSet
Set objRset = objConex.Execute (consulta)
%>
<table>
<tr>
<td>Nombre</td> <td>Apellidos</td> <td>DNI</td>
<td>Teléfono</td> <td>E-mail</td>
</tr>

<%
Do While Not objRset.Eof
‘mientras haya registros
%>
<tr>
<td><%=objRset("nombre")%></td>
<td><%=objRset("apellidos")%></td>
8 Disponible en el sitio Web de Mysql http://www.mysql.com.
118 CAPÍTULO 8. BASES DE DATOS Y BÚSQUEDA EN LA WEB

<td><%=objRset("dni")%></td>
<td><%=objRset("telefono")%></td>
<td><%=objRset("email")%></td>
</tr>
<%
‘salta al siguiente registro
objRset.MoveNext
Loop
%>
</body>
</html>

Listado 8.2 Acceso a bases de datos MySQL desde una página ASP.

JSP

El acceso a base de datos desde JSP, al igual que desde Servlets, se apoya en la tecnología JDBC de
Java. Para que todo funcione adecuadamente se necesita un driver [56] que proporcione el acceso
a la bases de datos subyacente (MySQL). La instalación es fácil, basta con poner el archivo .jar
del driver en el CLASSPATH del contenedor de Servlets. Para conseguir los objetivos planteados
en el ejemplo puede utilizarse el siguiente código JSP:

<%@ page language="java" contentType="text/html" %>

<%@ page import="java.sql.*" %>

<html>
<head>
<title>Acceso a base de datos desde JSP</title>
</head>
<body>

<%
// Se indica donde está el driver JDBC adecuado a la BBDD
Class.forName("org.gjt.mm.mysql.Driver");

// Preparamos la cadena de conexión que indica

// la máquina "localhost"
// y el nombre de la BBDD "ejemplo" a utilizar.
String cadenaconexion = "jdbc:mysql://localhost/ejemplo";
8.3. ACCESO A DATOS 119

// Se realiza la conexión con la cadena anterior y un

// login/password válido
Connection con = DriverManager.getConnection
(cadenaconexion, "root", "");

// Se crea la consulta
Statement st = con.createStatement();
String cons = "Select * From clientes";

// Ejecutar y obtener los resultados de la consulta

ResultSet rs = st.executeQuery(cons);
%>

<!-- Presentar los resultados en una tabla -->

<table>
<tr>
<td>Nombre</td> <td>Apellidos</td> <td>DNI</td>
<td>Teléfono</td> <td>E-mail</td>
</tr>

<% while (rs.next()){

//mientras haya registros
%>
<tr>
<td><%= rs.getString("nombre")%></td>
<td><%= rs.getString("apellidos")%></td>
<td><%= rs.getString("dni")%></td>
<td><%= rs.getString("telefono")%></td>
<td><%= rs.getString("email")%></td>
</tr>
<% } %>

</table>
</body>
</html>

Listado 8.3 Acceso a bases de datos MySQL desde una página JSP.
120 CAPÍTULO 8. BASES DE DATOS Y BÚSQUEDA EN LA WEB

PHP

PHP ofrece interfaces propias de acceso a multitud de fuentes de datos: BBDDs (MySQL,
mSQL, Oracle 8, etc.), servidores de directorio (LDAP), texto en XML, etc. Todas ellas están
documentadas en la página Web de PHP [88]. Para el ejemplo propuesto en esta sección, un
código PHP sencillo es el siguiente:

<html>
<head>
<title>Consulta a BD con PHP</title>
<? // Establecer conexión con BBDD
mysql_connect("localhost", "root", "");
// Preparar y ejecutar consulta
$result = mysql_db_query("ejemplo","SELECT * FROM clientes"); ?>
</head>

<body>
<h1>Resultados de la consulta</h1>
<table border=1>
<tr><td>Nombre</td><td>Apellidos</td>
<td>Dni</td><td>Tlf</td><td>E-mail</td>
</tr>
<? // Presentar resultados
while($row = mysql_fetch_object($result)) {
echo ’<tr><td>’; echo $row->nombre; echo ’</td>’;
echo ’<td>’; echo $row->apellidos; echo ’</td>’;
echo ’<td>’; echo $row->dni; echo ’</td>’;
echo ’<td>’; echo $row->telefono; echo ’</td>’;
echo ’<td>’; echo $row->email;
echo ’</td></tr>’;
}
?>
</table>
<? //Cerrar la conexión
mysql_close();
?>
</body>
</html>

Listado 8.4 Acceso a bases de datos MySQL desde una página PHP.
8.4. BÚSQUEDA EN LA WEB 121

8.4 Búsqueda en la Web

8.4.1 Introducción

El crecimiento exponencial del número de documentos publicados en la World Wide Web han
hecho que una de las herramientas más utilizada en la actualidad sean los motores de búsqueda de
carácter general. Generalmente manejan ingentes cantidades de datos y se apoyan en algún SGBD
potente, probablemente alguno de los mencionados en las secciones anteriores. Esta tecnología ha
demostrado ser útil y está siendo adoptada para su uso en Intranets y sitios Web de mediano/gran
tamaño (empresas, universidades, etc).
Algunas de las grandes empresas de buscadores (Google, etc.) ofrecen sus servicios de indexación
y búsqueda a servidores particulares, reservando un espacio en sus bases de datos para la
información de ese servidor. Es una solución válida, pero en la actualidad los nuevos servidores
Web tienden a integrar las capacidades de búsqueda como un servicio más (por ejemplo Microsoft
IIS con Microsoft Index Server).
En este capítulo se da una introducción teórica a la tecnología sobre la que se apoyan las búsquedas
en la Web [123] [7].

8.4.2 Funcionamiento de un buscador

La arquitectura de un buscador genérico (figura 8.2) se basa en cuatro componentes fundamentales:

Figura 8.2: Arquitectura de un buscador genérico.

Robot


Indexador


Motor de búsqueda


Interface
122 CAPÍTULO 8. BASES DE DATOS Y BÚSQUEDA EN LA WEB

8.4.3 Robot

Prácticamente todos los buscadores de Internet (Google, AllTheWeb, etc.) construyen sus
bases de datos usando robots (webcrawlers o spiders). Los robots son programas que recorren
automáticamente la Web recuperando documentos. En general comienzan con un listado de URLs
preseleccionadas y recurrentemente visitan los documentos que se referencian desde las mismas.

Una parte importante de los robots son los algoritmos utilizados para:

Seleccionar los enlaces a seguir. Se pueden utilizar desde los algoritmos clásicos de
búsqueda sin información (profundidad, anchura) hasta cualquier solución compleja basada
en heurísticas (popularidad9 , etc.).


Determinar la frecuencia entre visitas. Existen robots (por ejemplo Altavista) capaces de
“aprender” el intervalo de actualización de las páginas y así replanificar automáticamente
sus visitas.

Cuando se es Webmaster, muchas veces se da la situación de no desear que ciertas páginas de

un sitio sean accedidas por los robots. Por ejemplo páginas semi-privadas (publicadas en la Web
pero no referenciadas desde ninguna otra página), scripts cgi, etc. Esta preocupación dio lugar a la
creación de dos soluciones que permiten impedir el acceso total o parcial de los robots a un sitio
Web:

El estándar de exclusión de robots: es un estándar de facto que permite al administrador

controlar el acceso de los robots a su sitio. El control se hace a través de un archivo de texto
(robots.txt) ubicado en el directorio raíz. Un ejemplo:

# El agente ‘‘mirobot’’ tiene acceso a todo el sitio

User-agent: mirobot
Disallow:
# El agente ‘‘webcrawler’’ no tiene acceso al sitio
User-agent: webcrawler
Disallow: /
# El resto de los agentes no pueden acceder a
# los directorios ‘‘/pruebas’’ y ‘‘cgi-bin’’
User-agent: *
Disallow: /pruebas
Disallow: /cgi-bin

Listado 8.5 Restringir el acceso de robots a un sitio Web. robots.txt.

9 Número de enlaces que apuntan a la página.

8.4. BÚSQUEDA EN LA WEB 123

META tags (etiquetas) HTML: muchas veces los usuarios no tienen permisos para crear un
fichero /robots.txt, pero desean controlar el acceso de los robots a sus páginas. En este
caso hay un nuevo estándar que permite usar META tags de HTML. Por ejemplo:

<META NAME="ROBOTS" CONTENT="NOINDEX,NOFOLLOW">

NOINDEX significa que la página no debe ser indexada y NOFOLLOW que no deben seguirse
los enlaces contenidos en la misma.

Mientras el uso del robots.txt está estandarizado y es utilizado por todos los robots importantes,
no sucede lo mismo con las META tags. De todas formas, hay que tener en cuenta que existen
miles de robots y muchos de ellos no respetan estas convenciones. Las instrucciones de restricción
de acceso sólo serán respetadas por aquellos que operen siguiendo la ética de la red.

8.4.4 Indexador

Un indexador es un programa que recibe las páginas recuperadas por un robot (muchas veces el
robot y el indexador son el mismo programa), extrae una representación interna de la misma y la
vuelca en forma de índice en una BBDD.

Existen varias técnicas para extraer la información del documento, algunos indexadores sencillos
almacenan los títulos HTML, otros los primeros párrafos, etc. Pero los más avanzados utilizan
técnicas complejas:

Extracción avanzada de vocabulario de términos:

– Listas de parada: son listas de palabras muy habituales que no aportan significado y
que no deben aparecer en el vocabulario. Por ejemplo preposiciones, artículos, etc.
– Extracción de raíces: consigue un termino único para el vocabulario que representa
distintas palabras de significado parecido, por ejemplo plurales, tiempos verbales, etc.

Medidas de la calidad según la frecuencia de aparición de cada palabra en cada documento.

...

8.4.5 Motor de búsqueda

Es un programa que se encarga de analizar una consulta de usuario y buscar en el índice los
documentos relacionados. Un buen motor de búsqueda será capaz de ordenar los resultados de
manera que aparezcan antes las páginas más relevantes atendiendo a varios indicadores, entre
otros:
124 CAPÍTULO 8. BASES DE DATOS Y BÚSQUEDA EN LA WEB

Localización: hace que dentro del resultado aparezcan antes aquellos documentos donde existen
ocurrencias de todas las palabras utilizadas en la consulta. La relevancia de los documentos
es mayor cuanto más al comienzo de los mismos aparecen las palabras buscadas. Por
ejemplo, si todas las palabras utilizadas en la consulta aparecen en el título del documento,
este será muy relevante y aparecerá antes en la respuesta que ofrece el motor de búsqueda.

Frecuencia de aparición: a mayor número de apariciones de los términos de la consulta en una

página, más relevante será ésta para el resultado. Algunos motores utilizan una valor de
frecuencia máxima y descartan los documentos que superan ese valor. Con esta política se
consiguen evitar documentos spam, que intentan subir posiciones en el listado de respuesta
sin tener un valor real.

Popularidad: algunos motores son capaces de medir la popularidad, es decir, el número de

enlaces que apuntan a una página. Una página a la que se hacen muchas referencias suele
ser mejor que otra a la que se hacen menos.

Dinero: en buscadores comerciales, se están implantando servicios de pago que permiten que una
página aparezca antes en los resultados en función de la cantidad de dinero pagada.

Los motores de búsqueda suelen estar implementados mediante alguna de las tecnologías que
permiten a los programas interactuar con los datos enviados sobre HTTP, por ejemplo CGI,
Servlets, ASP, CFML, etc.

8.4.6 Interface

La interface más utilizada es la basada en páginas Web con formularios:

Formularios: el mecanismo de entrada de datos de las páginas Web son los formularios (vea la
sección A.3 en la página 362). Una interface de entrada simple se compone de un formulario
con una caja de texto y un botón de envío. El usuario introduce la palabra buscada y
pincha en el botón. Soluciones más avanzadas permiten introducir varias palabras, añadir
expresiones booleanas, buscar por proximidad, buscar en un idioma determinado, etc.

Páginas Web de resultado: los resultados se mostrarán en una página Web. Cada ítem de
respuesta contiene típicamente el enlace a la página, el contexto en el que se han encontrado
las palabras buscadas, la fecha de indexación, etc. Además, y en función de la complejidad
de la interface, pueden añadirse características avanzadas como la posibilidad de traducción
automática, extracción a texto desde formatos binarios como PDF o PPT, etc.
Capítulo 9

Registro de actividad, log o bitácora

Contenidos de este capítulo

9.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

9.2 Posibilidades para almacenar información de registro . . . . . . . . . . . . 126
9.2.1 Ficheros de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.2.2 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
9.2.3 Otras alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
9.3 Utilidades relacionadas con los datos de registro . . . . . . . . . . . . . . . 128
9.3.1 Análisis de Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
9.3.2 Rotación del log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

9.1 Introducción

Cuando un cliente se conecta al servidor Web, se produce un intercambio de información que

puede ser registrado. Mediante el análisis de esta información de registro, el administrador conoce
datos que le ayudan en su trabajo.

El método básico para obtener información son los ficheros de registro almacenados en el
servidor. Existen formas para configurar estos ficheros atendiendo a necesidades particulares,
pero generalmente se utilizan dos ficheros estándar:

error_log: para mantener datos sobre errores en el servidor.

access_log: que registra la información básica sobre cada transacción HTTP.

Otro método, las cookies, surgieron en la última versión de HTTP y permiten nuevas posibilidades
para recolectar información que es mantenida en el propio cliente. Por último, mediante añadidos
como programas externos y acceso a bases de datos, se pueden conseguir potentes sistemas de log.

125
126 CAPÍTULO 9. REGISTRO DE ACTIVIDAD, LOG O BITÁCORA

En este capítulo se da una introducción al uso de estos tres métodos de registro de actividad, así
como a algunas herramientas relacionadas.

9.2 Posibilidades para almacenar información de registro

9.2.1 Ficheros de registro

Todos los servidores Web de calidad proporcionan un sistema para guardar registro de sus acciones
a fichero. Aunque es habitual disponer de directivas para personalizar estos ficheros (creando
un fichero individual para ciertos detalles de las peticiones, cambiando el formato de los datos
por defecto que se almacenan por cualquier otro formato personalizado, redirigiendo el log a un
proceso externo o base de datos, etc.), esta sección se centra en la configuración normal para los
ficheros de registro.

Registro de errores: error_log

Además de los logs de acceso, es muy habitual controlar la actividad del propio servidor a través
de un fichero llamado error_log1 . Mediante los mensajes almacenados en este fichero se obtiene
información útil para:

Monitorizar la actividad y el estado del servidor.



Asegurar el servidor. Por ejemplo una gran cantidad de errores repetidos en la autenticación
de acceso a secciones reservadas, pueden revelar un intento de ataque por fuerza bruta.
Incluso el conocido gusano code red puede ser detectado analizando este fichero.

Líneas típicas en el fichero de error son:

[Tue Mar 07 09:59:29 2001] [error] [client 193.147.87.211]

File does not exist: /ruta/noexiste.html

[Tue Apr 11 22:13:21 2001] [error] [client 192.168.1.3]

user txapi@a.es: authentication failure for
"/admin/": password mismatch

Registro de accesos: access_log

El fichero acces_log2 almacena una línea por cada petición HTTP. Todas las líneas siguen un
formato comúnmente aceptado, llamado common log format, que es el formato habitual que casi
todos los servidores Web entienden.
1 error.log en plataformas Windows.
2 access.log en plataformas Windows.
9.2. POSIBILIDADES PARA ALMACENAR INFORMACIÓN DE REGISTRO 127

A continuación se analiza campo a campo el contenido de una línea3 que se almacena con formato
Common log format:

212.34.211.79 - - [30/Jun/2001:09:46:30 +0300]

GET http://www.ei.universidad.es/index.html HTTP/1.1 200 1045

212.34.211.79: la dirección IP (o quizá el nombre del host) del visitante.



-: un campo que permite una identificación más detallada del cliente [92], pero que no suele
ser utilizado (y por eso aparece un guión).


-: nombre de usuario que el servidor necesita cuando se está intentando acceder a una
sección protegida por password.


30/Jun/2001:09:46:30 +0300: la fecha, hora y zona horaria.



GET http://www.ei.universidad.es/index.html HTTP/1.1: la solicitud del visitante (método,

URL, y versión del protocolo).


200: el código de estado HTTP que devolvió el servidor como parte de su respuesta.


1045: El número de bytes que envió el servidor (excluyendo cabeceras).

Registros personalizados: custom_log

¿Por qué formatos personalizados?, principalmente por dos motivos:

Facilitar la construcción de herramientas de análisis de log. Hay que tener en cuenta que
el common log format carece de un delimitador común de campos de datos, lo que hace su
análisis innecesariamente complejo.


Añadir datos no estándar que pueden resultar interesantes (como por ejemplo el agente de
usuario utilizado).

Hay un formato personalizado que debido a su amplia aceptación es casi un estándar de facto.
Es el llamado combined_log. Se trata de un formato idéntico al common log format que añade
información sobre el agente de usuario y el remitente (referer). Un ejemplo de la información que
contendría una línea en un archivo combined_log es:

212.34.211.79 - - [30/Jun/2001:09:46:30 +0300]

"GET http://www.ei.universidad.es/index.html" HTTP/1.1 200 289
"http://yahoo.es/" "linux 2.4 Netscape Navigator 4.05"

En este caso, se solicita la URL http://www.ei.universidad.es/serv/index.html, siendo

el sitio remitente http:/yahoo.es/ y el agente de usuario un equipo con sistema operativo linux
2.4 y un navegador Netscape Navigator 4.05.
3 La línea del ejemplo aparece partida, pero en realidad es “una” línea.
128 CAPÍTULO 9. REGISTRO DE ACTIVIDAD, LOG O BITÁCORA

9.2.2 Cookies

Las cookies son otro mecanismo que permite almacenar información. De manera breve, una
cookie es un pedazo de información generada por el servidor Web y almacenada en el cliente,
generalmente se trata de un identificador que está asociado al contenido de alguna BBDD en el
servidor. Se introdujeron en la especificación de HTTP/1.1 e intentan modelar el concepto de
estado o sesión. El estado se puede definir como una operación de registro sobre la secuencia de
acciones que un usuario realiza contra un servidor.

Las técnicas basadas en cookies permiten conseguir información sobre los hábitos de cada usuario
(crear perfiles) y son muy populares para aplicaciones de comercio electrónico (como un carrito de
compra). Estas aplicaciones no pueden basarse simplemente en la dirección IP, ya que en muchos
casos no identifica de manera única a un usuario. Por ejemplo un equipo que puede ser usado por
varios usuarios (en un ciber, aula de libre acceso, etc.) o ordenadores situados detrás de un firewall
o proxy, que ocultan direcciones IPs.

9.2.3 Otras alternativas

Como se ha comentado que el uso de cookies permite que un protocolo sin estados como HTTP,
sea capaz de utilizar el concepto de sesión. Pero hay un problema, la mayoría de los navegadores
permiten deshabilitar el soporte para cookies, de esta forma, aunque el servidor permita cookies,
puede ser que el cliente no las acepte.

La alternativa es utilizar alguna herramienta externa (por ejemplo CGI) que facilite el proceso
de log hacia una BBDDs, o incluso módulos del propio servidor (por ejemplo mod_session en
Apache) que permita establecer sesiones a través de URLs. Por ejemplo:

http://www.servidor.es/pagina.html?id=usuario1...

9.3 Utilidades relacionadas con los datos de registro

9.3.1 Análisis de Log

Una vez se tienen los datos registrados, el administrador necesita extraer información relevante.
Desde luego no parece buena idea contratar a alguien para que revise línea a línea el log y prepare
informes. Para hacer ese tipo de trabajo sucio, existen multitud de paquetes de análisis4 . Con ellos
se pueden recopilar multitud de datos que pueden ser de gran ayuda, por ejemplo:

Número de visitas: fundamental para saber si el sitio está siendo utilizada o no.
4 Puedeobtenerse un buen listado (aunque no completo) en el directorio yahoo:
http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/Servers/Log_
Analysis_Tools/.
9.3. UTILIDADES RELACIONADAS CON LOS DATOS DE REGISTRO 129

Páginas más visitadas: da una idea de cuales son los contenidos más demandados.

Clientes (navegadores) que acceden al sitio: permite orientar el perfil del usuario del sitio.

Informes sobre sistema operativo del cliente: es un buen indicador de como se mueve el
mercado de los sistemas operativos. Hoy en día las plataformas Windows se llevan la palma,
aunque Linux está teniendo un fuerte auge.

Datos de acceso divididos por franjas horarias: revelan los momentos de mayor y menor
sobrecarga del servidor. Pueden ayudar a decidir a que horas se deben lanzar procesos
costosos, como por ejemplo el propio análisis de los logs.

Informes de códigos de estado producidos por el servidor: ayudan a detectar errores, por
ejemplo cuando hay muchas solicitudes de una misma página y esta no se encuentra en el
servidor, quizá haya sido borrada accidentalmente.

...

De todos los analizadores, uno de los más utilizados es Analog [12], varias características invitan
a elegirlo sobre los demás:

1. Rapidez: es la característica más importante de un buen analizador de logs. De poco sirve

obtener unos informes maravillosos si para generarlos dejamos la máquina completamente
colapsada durante cinco horas.

2. Configurabilidad: Analog es capaz de recolectar prácticamente toda la información de

relevancia que alguien, alguna vez, pudiera necesitar5 . Puede configurarse hasta el más
pequeño detalle, tanto editando los ficheros a mano, como mediante una interface Web.

3. Diversos formatos de salida: puede generarse la salida en formato texto o HTML, siendo
este último configurable mediante hojas de estilo y gráficos personalizados.

4. Internacionalización: actualmente puede generar informes es 28 idiomas.

5. Precio: es gratis6 , y se distribuye libremente como código fuente en ANSI C estándar.

6. Capacidad gráfica: aunque Analog no tiene un gran potencial generando gráficas, mejora en
cada nueva versión e incluso existen paquetes adicionales que añaden nuevas posibilidades.

En un capítulo posterior se explica de manera detallada como usar Analog junto con los ficheros
de registro generados por Apache (vea la sección 19.5 en la página 286).
5 Naturalmente, Analog no inventa nada, la información debe estar de alguna manera reflejada en los ficheros de log.
6 Frente a otros analizadores comerciales, como por ejemplo Webtrends, cuyo precio puede ser superior al millón de
pesetas.
130 CAPÍTULO 9. REGISTRO DE ACTIVIDAD, LOG O BITÁCORA

9.3.2 Rotación del log

Tarde o temprano, será necesario reiniciar los ficheros de log. Las razones que llevan a
hacerlo pueden ser diversas, entre ellas, que el registro haya crecido demasiado7 o contenga
mucha información antigua que ya no es necesaria. Un listado con algunas herramientas que
automatizan este proceso puede encontrarse en la siguiente dirección: http://www.cio.com/
forums/careers/site_mgmt_content.html#435

Algunas de las más conocidas son cronolog [34] (una utilidad de rotación de código libre) o
logrotate (la utilidad de rotación de logs que se distribuye con Apache).

7 Por ejemplo, access_log suele crecer 1Mb por cada 10.000 peticiones.
 Parte II

Aplicación práctica 1:
Configuración de un servidor Web
Apache

131
Capítulo 10

Instalando Apache para Linux/Unix

Contenidos de este capítulo

10.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

10.2 Requisitos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
10.3 Conseguir una copia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
10.4 Instalación desde código fuente . . . . . . . . . . . . . . . . . . . . . . . . . 136
10.4.1 Configurando la instalación . . . . . . . . . . . . . . . . . . . . . . . 136
10.4.2 Compilar y acabar la instalación . . . . . . . . . . . . . . . . . . . . . 139
10.4.3 Compilando nuevos módulos con apxs . . . . . . . . . . . . . . . . . . 140
10.5 Instalación desde código precompilado . . . . . . . . . . . . . . . . . . . . 140
10.5.1 Distribución binaria . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
10.5.2 Gestores de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
10.6 Arranque y parada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
10.6.1 Arranque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
10.6.2 Parada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
10.6.3 Rearranque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
10.6.4 Volver a leer la configuración . . . . . . . . . . . . . . . . . . . . . . 145
10.6.5 El ejecutable httpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
10.6.6 El script apachectl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

10.1 Introducción

Apache está disponible para una gran cantidad de plataformas:

133
134 CAPÍTULO 10. INSTALANDO APACHE PARA LINUX/UNIX

Linux SunOS UnixWare Darwin/Mac OS

FreeBSD Solaris AIX OpenStep/Mach
OpenBSD IRIX SCO DYNIX/ptx
NetBSD HPUX ReliantUNIX BSDI
Digital Unix DGUX Windows ...

y en diversos formatos de distribución:

precompilado (binario, paquete).



código fuente.

Cualquiera con un conocimiento mínimo de manejo del sistema puede efectuar la instalación
básica de Apache, incluso eligiendo el método de instalación basado en código fuente, que en
teoría es el modo de instalación más duro. En este capítulo se presentan los pasos a seguir para
hacerlo.

10.2 Requisitos del sistema

No se necesita un equipo “último modelo” para que el servidor funcione, a decir verdad los
requisitos son más bien pocos. Un ordenador con procesador 486, 15 megas de espacio en disco
duro para espacio temporal durante la instalación son suficientes. Una vez instalado, el servidor
ocupa sobre 4 megas, y a partir de aqui el administrador deberá hacer cuentas sobre el espacio que
necesario para alojar sitios Web.

Para un uso comercial, desde luego, no es aconsejable usar un 486, lo lógico es usar un equipo
potente capaz de soportar altas cargas, con un disco duro grande y rápido, y la cantidad necesaria
de RAM para que no se produzca swapping.

Si se va a elegir el método de instalación basado en el código fuente, se necesitará también:

Compilador ANSI C, como por ejemplo el gcc que se distribuye con Linux.


Interprete de Perl 5.003 o superior, para dar soporte a ciertos scripts de instalación escritos
en este lenguaje.

10.3 Conseguir una copia

Hay varias formas de hacerse con una copia de Apache, (CDs de revistas, acompañando a
distribuciones Linux, etc.) pero la manera más cómoda de obtener la versión más actualizada
es visitar la zona de descarga (figura 10.1) de la página Web del Apache Group (http://httpd.
apache.org/dist), o alguno de sus mirrors a lo largo del mundo.
10.3. CONSEGUIR UNA COPIA 135

Figura 10.1: Página de descarga de Apache.

Existe la posibilidad de conseguir versiones en distintos formatos de distribución, una elección

importante es el formato a elegir. La respuesta dependerá de las necesidades particulares:

Distribución binaria o empaquetada: propociona un servidor básico y todas sus extensiones

por defecto compiladas de manera separada como módulos DSO (Dynamic Shared Objects)
(vea el apéndice B en la página 367). Este tipo de distribución es la más adecuada si:


Se tiene un sistema operativo que soporta DSO, y toda la funcionalidad necesaria está
incluida en los módulos por defecto.


o se planea expandir el servidor con módulos de terceras partes que pueden ser
compilados como módulos DSO1 y añadidos a un servidor previamente instalado.
Estos nuevos módulos DSO pueden ser activados simplemente retocando el fichero
de configuración.

Distribución como código fuente: es la única opción disponible cuando se necesita incluir algún
módulo de terceras partes que necesitan “parchear” el código de Apache para funcionar (el
ejemplo más conocido es mod_ssl, que parchea el código incluyendo una API extendida
llamada EAPI). También es la opción a elegir si se desea ejecutar siempre la última versión
del servidor, ya que el código fuente está siempre disponible antes que cualquier versión
precompilada. Una ventaja de esta forma de distribución es que permite ajustar al máximo
los parámetros de optimización del compilador para que el código resultante se ejecute de
la forma más eficiente en nuestra máquina.
1 La mayoría de los módulos soportan este estilo de instalación.
136 CAPÍTULO 10. INSTALANDO APACHE PARA LINUX/UNIX

10.4 Instalación desde código fuente

Se parte de una copia de la última versión estable del software en codigo fuente (a junio de
2001 apache_1.3.20.tar.gz). Es habitual utilizar un directorio estándar (/usr/src) para
desempaquetar los archivos de instalación, pero para los ejemplos de este proyecto se opta por
utilizar otro:

# cd /usr/local/proyecto/src

Se descomprime el archivo usando gzip y se extraen los ficheros que componen el árbol de
instalación con la utilidad tar.

# gzip -d -c apache_1.3.20.tar.gz | tar xvf -

En el directorio actual aparece un nuevo árbol de directorios cuya raíz es apache_1.3.20.

10.4.1 Configurando la instalación

Al compilar se transforman los ficheros de código fuente en código binario ejecutable que entiende
la máquina. En los sistemas tipo Unix/Linux la acción de compilar suele ser asistida por la utilidad
make. Esta es capaz de compilar adecuadamente un proyecto de código en función de un conjunto
de reglas. Las reglas se almacenan en ficheros llamados Makefile que especifican cosas como
el orden de compilación del código fuente, las dependencias, etc. En un Makefile también se
indican distintos objetivos, como crear todo el proyecto (all), limpiar árbol de código fuente
(clean) o instalar el ejecutable previamente compilado (install).

Apache hace uso de make, y además permite personalizar al máximo la configuración por medio
de dos métodos:

Configurar a mano.


Usar APACI (APache AutoConf-style Interface).

Configurar a mano

Este es el método antiguo, era la única forma de hacer las cosas en las versiones anteriores a
Apache 1.3. Para usuarios que ya conociesen Apache quizá sea la manera más cómoda trabajar.
Para modificar la configuración manualmente, se deben seguir varios pasos:

1. Cambiar al directorio src (dentro del árbol de instalación).

2. Sobreescribir el fichero Configuration con el contenido de Configuration.tmpl.

10.4. INSTALACIÓN DESDE CÓDIGO FUENTE 137

3. Editar el fichero Configuration. Este está muy bien comentado y en el se pueden indicar
instrucciones específicas al compilador C, reglas para generar los Makefiles y módulos
que se van a construir y/o activar.

4. Ejecutar ./Configure2 para crear los Makefile.

Usar APACI

Desde la versión 1.3 Apache incorpora el APACI, este es el sistema de instalación recomendado
por los desarrolladores del Apache Group. APACI proporciona un modo sencillo de configurar la
instalación. Se basa en el script ./configure3 al que se le proporcionan opciones en la línea de
comandos. Al ejecutarlo realiza dos acciones fundamentales:

Realiza ciertas comprobaciones sobre el hardware y el software del sistema que pueden
afectar al proceso de compilar Apache.


Si todo va bien en el paso anterior, construye los Makefile necesarios.

El ejemplo más sencillo es usar este sistema de configuración para variar la ruta base por defecto
para la instalación:

# ./configure --prefix=/usr/local/proyecto/apache1.3.20
Configuring for Apache, Version 1.3.20
+ using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
+ configured for Linux platform
+ setting C compiler to gcc
+ setting C pre-processor to gcc -E
+ checking for system header files
+ adding selected modules
+ checking sizeof various data types
+ doing sanity check on compiler and options
Creating Makefile in src/support
Creating Makefile in src/regex
Creating Makefile in src/os/unix
Creating Makefile in src/ap
Creating Makefile in src/main
Creating Makefile in src/lib/expat-lite
Creating Makefile in src/modules/standard
2 Configure con la primera “C” mayúscula, no confundir con el configure del método APACI.
3 Se puede encontrar en la raíz del árbol de instalación.
138 CAPÍTULO 10. INSTALANDO APACHE PARA LINUX/UNIX

Un ejemplo un poco más complejo permite habilitar los módulos que son utilizables
en todas las plataformas (--enable-module=most) y compilarlos como módulos DSO
(--enable-shared=max):

# ./configure --prefix=/usr/local/proyecto/apache1.3.20 \
> --enable-module=most \
> --enable-shared=max

Otra opción interesante es --show-layout que muestra cuales van a ser las ubicaciones
de los ficheros una vez se complete la instalación. Existe un fichero especial llamado
config.layout, en el que se definen varias combinaciones de rutas habituales (GNU, Solaris,
OpenBSD, Suse, RedHat, Apache por defecto, etc.) que pueden ser escogidas con la opción
--with-layout=NOMBRE_DE_LAYOUT.

# ./configure --show-layout
Configuring for Apache, Version 1.3.20
+ using installation path layout: Apache (config.layout)

Installation paths:
prefix: /usr/local/apache
exec_prefix: /usr/local/apache
bindir: /usr/local/apache/bin

---- Omitimos datos de salida ----

# ./configure --with-layout=GNU

Son muchos los parámetros que se pueden pasar al script ./configure, para obtener un listado
completo puede ejecutarse:

# ./configure --help

Cada vez que se ejecuta ./configure se crea un nuevo fichero de nombre config.status4 .
Este fichero contiene la última línea de comando con la que se ejecutó ./configure. Si tiene los
permisos adecuados actúa como un script de shell que puede ejecutarse de nuevo e incluso acepta
nuevos parámetros. Por ejemplo, se puede repetir la configuración anterior pero deshabilitando un
módulo (por ejemplo mod_imap):

# ./config.status "--disable-module=mod_imap"
4 Es creado en el raíz del árbol de instalación.
10.4. INSTALACIÓN DESDE CÓDIGO FUENTE 139

10.4.2 Compilar y acabar la instalación

Una vez acabada la configuración de manera correcta se habrán generado los ficheros Makefile
necesarios para que la herramienta make sepa como compilar el proyecto.

# make
===> src
make[1]: Cambiando a ‘/usr/local/proyecto/src/apache_1.3.20’
make[2]: Cambiando a ‘/usr/local/proyecto/src/apache_1.3.20/src’
===> src/regex
sh ./mkh -p regcomp.c >regcomp.ih
gcc -I. -I../os/unix -I../include -DLINUX=22 -DUSE_HSREGEX
-DUSE_EXPAT -I../lib/expat-lite -DNO_DL_NEEDED ‘../apaci‘
-DPOSIX_MISTAKE
-c -o regcomp.o regcomp.c
gcc -I. -I../os/unix -I../include -DLINUX=22 -DUSE_HSREGEX
-DUSE_EXPAT -I../lib/expat-lite -DNO_DL_NEEDED ‘../apaci‘
-DPOSIX_MISTAKE
-c -o regexec.o regexec.c

---- Omitimos más datos de salida ----

Por último queda que el servidor recién compilado sea movido a su ubicación definitiva. Esta
ubicación habrá sido especificada durante el proceso de configuración:

--prefix: selecciona una ruta “base” para la instalación.



--with-layout: selecciona un layout (combinación de directorios) específico.



Si no se ha escogido nada en particular a este respecto se usa la ruta por defecto

/usr/local/apache.

La utilidad make permite rematar la instalación, para ello se le pasa el parámetro install. Durante
el proceso aparecerán algunos mensajes en pantalla siendo el más importante el último. En este
mensaje final se indica si la instalación ha concluido correctamente, como ejecutar el servidor y
donde está el fichero de configuración:

# make install

---- Omitimos más datos de salida ----

+--------------------------------------------------------+
140 CAPÍTULO 10. INSTALANDO APACHE PARA LINUX/UNIX

| You now have successfully built and installed the |

| Apache 1.3 HTTP server. To verify that Apache actually |
| works correctly you now should first check the |
| (initially created or preserved) configuration files |
| |
| /usr/local/proyecto/apache1.3.20/conf/httpd.conf
| |
| and then you should be able to immediately fire up |
| Apache the first time by running: |
| |
| /usr/local/proyecto/apache1.3.20/bin/apachectl start
| |
| Thanks for using Apache. The Apache Group |
| http://www.apache.org/ |
+--------------------------------------------------------+

10.4.3 Compilando nuevos módulos con apxs

Si disponemos de una versión de Apache previamente construida con soporte a DSO, podremos
utilizar apxs5 . apxs (APache eXtenSion) es un script Perl que permite instalar un nuevo módulo
DSO sin necesidad de tener el código fuente de Apache. La idea es simple, cuando se instala
Apache, el proceso make install instala los ficheros C de cabecera de Apache y mete en apxs
los flags del compilador y enlazador dependientes de la plataforma para construir ficheros DSO. De
este modo el usuario puede usar apxs para compilar nuevos módulos del servidor sin la necesidad
de disponer del árbol de código fuente de Apache. El uso típico tendrá esta apariencia:

# apxs -i -a -c mod_foo.c

Más información puede obtenerse en las páginas man que se incluye con la distribución de Apache
(man apxs).

10.5 Instalación desde código precompilado

La instalación desde código fuente no es compleja, pero si para alguien supone algún problema,
siempre se puede recurrir a la versiones precompiladas. Existen varias posibilidades:

Distribución binaria.


Gestores de paquetes.
5 Desde la versión de Apache 1.3
10.5. INSTALACIÓN DESDE CÓDIGO PRECOMPILADO 141

10.5.1 Distribución binaria

Puede obtenerse una distribución binaria desde la zona de descarga del sitio web de Apache
Software Foundation (http://www.apache.org/dist/binaries). Existen distribuciones
binarias compiladas para un gran número de sistemas operativos y plataformas hardware. Los
nombres suelen ser explicativos, por ejemplo:

apache_1.3.20-i686-whatever-linux2.tar.gz

Es el código binario de Apache 1.3.20 para plataformas hardware basadas en procesadores

intel 686 (i686) con un sistema operativo basado en cualquier kernel Linux 2 o superior
(whatever-linux2).

El primer paso es obtener la distribución adecuada para la plataforma hardware donde se va a

instalar, esto puede determinarse de una manera sencilla mediante la utilidad uname. Por ejemplo:

# uname -m
i686

Una vez obtenido el archivo de instalación necesario, se seguirán una serie de pasos. Estos pasos
se detallan en el fichero INSTALL que acompaña a la distribución. También se puede saber que
módulos se incluyen en la distribución consultando el fichero README:

1. Se descomprime (con gzip) y extraen los ficheros (con tar) para crear el árbol de
directorios de la instalación.

# gzip -d -c apache_1.3.20.tar.gz | tar xvf -

2. En el directorio actual aparece un nuevo árbol de directorios cuya raíz es apache_1.3.20:

# cd apache_1.3.20

3. En este directorio se debe ejecutar el script de instalación que moverá los archivos binarios
a las localizaciones adecuadas:

# ./install-bindist.sh

10.5.2 Gestores de paquetes

Los gestores de paquetes son la manera de instalar programas que más se está popularizando en
los últimos tiempos.
142 CAPÍTULO 10. INSTALANDO APACHE PARA LINUX/UNIX

Paquetes rpm (Red Hat Package Manager)

El gestor de paquetes de Red Hat es sin duda el más extendido, a ello ha contribuido su naturaleza
open-source. No sólo Red Hat, sino también muchas otras distribuciones de Linux como por
ejemplo Mandrake o Caldera, incluyen el gestor de paquetes rpm.

A continuación se detallan los pasos para instalar apache-1.3.20_i386.rpm que se ha obtenido

de alguno de los sitios que distribuyen estos paquetes [91] [43] [110]: Red Hat (http://www.
redhat.com), buscadores de RPMs (http://www.rpmfind.net, http://freshrpms.net), etc.

1. Casi todas las distribuciones de Linux traen un servidor Apache preinstalado, si este es el
caso, el primer paso debe ser desinstalarlo. Por ejemplo en un Red Hat 7 se incluye la
versión apache_1.3.12. Para comprobarlo se le indica al gestor rpm que liste todos los
paquetes instalados (rpm -qa) y que se quede con los que contengan la palabra apache (|
grep apache).

# rpm -qa | grep apache

apache-manual-1.3.12-25
apache-1.3.12-25
apache-devel-1.3.12-25

Una vez verificado que existía una versión previa, podemos eliminarla (rpm -e). El gestor
rpm nos indicará si es necesario borrar también algún paquete adicional:

# rpm -e apache-1.3.12-25
error: removing these packages would break dependencies:
apache = 1.3.12-25 is needed by mod_ssl-2.6.6-25
webserver is needed by mod_perl-1.24-4
webserver is needed by mod_dav-1.0.1-2
webserver is needed by mod_php-4.0.1pl2-9
webserver is needed by nut-cgi-0.44.0-4
# rpm -e mod_ssl-2.6.6-25
# rpm -e mod_perl-1.24-4
# rpm -e mod_dav-1.0.1-2
# rpm -e mod_php-4.0.1pl2-9
# rpm -e nut-cgi-0.44.0-4
# rpm -e apache-1.3.12-25

2. Ahora el sistema ya está preparado para recibir la nueva versión de Apache. Instalaremos el
paquere RPM con la opción -i:

# rpm -i apache-1.3.20_i386.rpm
10.5. INSTALACIÓN DESDE CÓDIGO PRECOMPILADO 143

3. Con esto el servidor está listo para su ejecución. Si se tienen dudas sobre que ficheros y en
que directorios ha sido instalado puede ejecutarse:

# rpm -ql apache-1.3.20

---- Omitimos más datos de salida ----

/usr/lib/apache/mod_vhost_alias.so
/usr/sbin/ab
/usr/sbin/httpd
/usr/sbin/logresolve
/usr/sbin/rotatelogs
/usr/sbin/suexec
/usr/share/man/man1/dbmmanage.1.gz

---- Omitimos más datos de salida ----

dpkg

Dpkg es el gestor de paquetes que se utiliza en la distribución Debian. Existen varios programas
que actúan como interface a este sistema, desde el propio dkpg, que permite manejar los paquetes
a bajo nivel y de manera poco agradable al usuario, hasta las utilidades Apt:

apt-cache search: lista los paquetes que contienen la palabra clave indicada, por ejemplo:

# apt-cache search apache

apt-get: proporciona un método simple y seguro para instalar o actualizar los paquetes. Por
defecto busca directamente en el fuente desde donde se instaló el sistema (HD, CD, http,
ftp, etc.). Con el parámetro install busca, recupera e instala el paquete seleccionado. Por
ejemplo:

# apt-get install apache

apt-get se encarga de informar al usuario de la existencia de una versión antigua del

software y/o de la necesidad de paquetes adicionales para completar la instalación. Una vez
el usuario enterado apt-get es capaz de obtener todos los paquetes necesarios, eliminar las
versiones antiguas e instalar las nuevas de manera automática.

Para más información de como instalar Apache con formato de paquete debian puede consultarse
el sitio http://www.debian.org/.
144 CAPÍTULO 10. INSTALANDO APACHE PARA LINUX/UNIX

10.6 Arranque y parada

Aunque el ejecutable del servidor Web es un fichero que se llama httpd, para el control del
servicio también suele utilizarse un script llamado apachectl. Debido a esto existen dos formas
de realizar las tareas de arranque y parada. Generalmente se automatizan estas tareas para que
tengan lugar con el arranque y parada general de la máquina. Todos los sistemas UNIX/Linux
proporcionan un método de arranque/parada automático. Este se suele basar en scripts que aceptan
los parámetros start para arrancar y stop para parar. Se puede escribir un script personalizado
(basado en httpd) o bien utilizar el propio apachectl.

10.6.1 Arranque

# /usr/local/proyecto/apache1.3.20/bin/httpd

o bien:

# /usr/local/proyecto/apache1.3.20/bin/apachectl start

Tras el primer arranque del servidor a veces se obtienen mensajes de error, generalmente son
pequeños problemas que tienen que ver con la configuración. Junto con el error, Apache suele
dar una buena explicación del motivo del mismo y como solucionarlo. Lo ideal sería no observar
ningún mensaje, eso indica que el servidor ha arrancado correctamente. Para verificarlo puede
utilizar el comando ps y buscar httpd entre los procesos que están ejecutándose actualmente:

# ps -aux | grep httpd

10.6.2 Parada

Con el tiempo es probable que sea necesario parar el servidor, un cambio en los ficheros de
configuración es el motivo más habitual. ¿Cómo se hace?. También hay dos posibilidades, por un
lado se puede matar el proceso en función de su identificador numérico (almacenado en el fichero
httpd.pid ):

# kill ’cat /usr/local/proyecto/apache1.3.20/logs/httpd.pid’

o bien utilizar el script apachectl:

# /usr/local/proyecto/apache1.3.20/bin/apachectl stop
10.6. ARRANQUE Y PARADA 145

10.6.3 Rearranque

Aunque siempre es posible rearrancar el servidor en dos pasos, primero parar y luego arrancar,
existen otras formas de rearrancar en un sólo paso:

# kill -HUP ‘cat /usr/local/proyecto/apache1.3.20/logs/httpd.pid‘

o bien

# /usr/local/proyecto/apache1.3.20/bin/apachectl restart

10.6.4 Volver a leer la configuración

El motivo más habitual que fuerza al rearranque del servidor es un cambio en la configuración.
Pero, ¿es realmente necesario reiniciar el servidor?. La respuesta es no, llega con indicar a Apache
que vuelva a leer sus ficheros de configuración. Existen dos formas de hacerlo:

# kill -USR1 ‘cat /usr/local/proyecto/apache1.3.20/logs/httpd.pid‘

o bien

# /usr/local/proyecto/apache1.3.20/bin/apachectl graceful

10.6.5 El ejecutable httpd

Este programa proporciona algo más que el arranque del servicio Web. Para conocer todas sus
funcionalidades puede ejecutarse con el parámetro (-h):

# /usr/local/proyecto/apache1.3.20/bin/httpd -h
Usage: httpd [-D name] [-d directory] [-f file]
[-C "directive"] [-c "directive"]
[-v] [-V] [-h] [-l] [-L] [-S] [-t] [-T]
Options:
-D name : define a name for use in <IfDefine name> directives
-d directory : specify an alternate initial ServerRoot
-f file : specify an alternate ServerConfigFile
-C "direct." : process directive before reading config files
-c "direct." : process directive after reading config files
-v : show version number
-V : show compile settings
-h : list available command line options (this page)
146 CAPÍTULO 10. INSTALANDO APACHE PARA LINUX/UNIX

-l : list compiled-in modules

-L : list available configuration directives
-S : show parsed settings (currently only vhost settings)
-t : syntax check for config files (with docroot check)
-T : syntax check for config files (without docroot check)

Listado 10.1 Opciones de httpd.

Algunos de los parámetros más interesantes son los que permiten obtener información sobre la
configuración:

httpd -V: muestra información del número de versión, fecha de compilación y todos los
valores por defecto compilados con el servidor. Por ejemplo:

./httpd -V
Server version: Apache/1.3.20 (Unix)
Server built: Aug 9 2001 19:14:48
Server’s Module Magic Number: 19990320:10
Server compiled with....
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D USE_SYSVSEM_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D HTTPD_ROOT="/usr/local/proyecto/apache1.3.20"
-D SUEXEC_BIN="/usr/local/proyecto/apache1.3.20/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/httpd.scoreboard"
-D DEFAULT_LOCKFILE="logs/httpd.lock"
-D DEFAULT_XFERLOG="/usr/local/proyecto/logs/access_log"
-D DEFAULT_ERRORLOG="/usr/local/proyecto/logs/error_log"
-D TYPES_CONFIG_FILE="/usr/local/proyecto/conf/mime.types"
-D SERVER_CONFIG_FILE="/usr/local/proyecto/conf/httpd.conf"
-D ACCESS_CONFIG_FILE="/usr/local/proyecto/conf/access.conf"
-D RESOURCE_CONFIG_FILE="/usr/local/proyecto/conf/srm.conf"

httpd -l: muestra los módulos que se han compilado dentro del propio httpd (enlazados
estáticamente). Con este comando también puede verificarse que suEXEC6 ha quedado
correctamete instalado. Por ejemplo:
6 suEXEC es un wrapper de ejecución CGI que a veces se instala con el servidor.
10.6. ARRANQUE Y PARADA 147

# ./httpd -l
Compiled-in modules:
http_core.c
mod_so.c
suexec: enabled;
valid wrapper /usr/local/proyecto/apache1.3.20/bin/suexec

httpd -t: cada vez que se arranca el servidor se ejecuta implícitamente un chequeo de la
configuración. Si se necesita realizar un chequeo completo de los archivos de configuración,
pero no interesa que el servidor arranque, entonces se debe usar httpd -t. Por ejemplo:

# ./httpd -t
[Mon Aug 20 18:00:01 2001] [error] VirtualHost *:80 --
mixing * ports and non-* ports with a NameVirtualHost
address is not supported, proceeding with undefined results
Syntax OK

httpd -S: realiza un volcado de la configuración de los hosts virtuales tal y como Apache
la ha analizado. Por ejemplo:

# httpd -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:* is a NameVirtualHost
default server www.ei.universidad.es
(/usr/local/proyecto/conf/httpd.conf:1174)
port * namevhost www.ei.universidad.es
(/usr/local/proyecto/conf/httpd.conf:1174)
port 80 namevhost informatica.ei.universidad.es
(/usr/local/proyecto/conf/httpd.conf:1186)
port 80 namevhost matematicas.ei.universidad.es
(/usr/local/proyecto/conf/httpd.conf:1208)

10.6.6 El script apachectl

Agiliza las acciones de control del servicio Web, se puede “levantar” o “tirar” el servidor,
comprobar el estado de ejecución o los archivos de configuración, etc. Un listado completo de
sus funcionalidades se obtiene al ejecutarlo con el parámetro (help).

# /usr/local/proyecto/apache1.3.20/bin/apachectl help
usage: /usr/local/proyecto/apache1.3.20/bin/apachectl (start|stop
|restart|fullstatus|status|graceful|configtest|help)
148 CAPÍTULO 10. INSTALANDO APACHE PARA LINUX/UNIX

start - start httpd

stop - stop httpd
restart - restart httpd if running by sending a SIGHUP or
start if not running
fullstatus - dump a full status screen; requires lynx and
mod_status enabled
status - dump a short status screen; requires lynx and
mod_status enabled
graceful - do a graceful restart by sending a SIGUSR1 or
start if not running
configtest - do a configuration syntax test
help - this screen

Listado 10.2 Opciones de apachectl.

Capítulo 11

Configuración básica del servidor

Contenidos de este capítulo

11.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

11.2 Ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
11.3 Módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
11.4 Directivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
11.4.1 Definición de una directiva . . . . . . . . . . . . . . . . . . . . . . . . 152
11.4.2 Una posible clasificación de las directivas . . . . . . . . . . . . . . . . 155
11.5 Definición del entorno del servidor principal . . . . . . . . . . . . . . . . . 155
11.5.1 Identificación del servidor . . . . . . . . . . . . . . . . . . . . . . . . 155
11.5.2 Localización de ficheros o módulos . . . . . . . . . . . . . . . . . . . 158
11.5.3 Creación de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
11.5.4 Configuración de la red . . . . . . . . . . . . . . . . . . . . . . . . . . 169
11.6 Indexación de directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
11.6.1 AddIcon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
11.6.2 AddIconByEncoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
11.6.3 AddIconByType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
11.6.4 DefaultIcon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
11.6.5 DirectoryIndex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
11.6.6 HeaderName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
11.6.7 IndexIgnore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
11.6.8 IndexOptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
11.6.9 ReadmeName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
11.7 Directivas contenedoras y alias . . . . . . . . . . . . . . . . . . . . . . . . . 181
11.7.1 Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
11.7.2 <Directory> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
11.7.3 <Files> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

149
150 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

11.7.4 <Limit> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

11.7.5 <Location> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
11.7.6 ScriptAlias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
11.7.7 <VirtualHost> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
11.8 Tipos MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
11.8.1 AddCharset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
11.8.2 AddEncoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
11.8.3 AddLanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
11.8.4 AddType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
11.8.5 DefaultType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
11.8.6 LanguagePriority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
11.8.7 MIMEMagicFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
11.9 Utilidades de log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
11.9.1 CustomLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
11.9.2 LogFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
11.9.3 LogLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
11.9.4 TransferLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
11.10Control de secciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
11.10.1 Allow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
11.10.2 AllowOverride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
11.10.3 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
11.10.4 Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
11.11Configuración de hosts virtuales . . . . . . . . . . . . . . . . . . . . . . . . 205
11.11.1 NameVirtualHost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
11.11.2 ServerAlias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
11.12Otras directivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
11.12.1 BrowserMatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
11.12.2 UserDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
11.13Consideraciones de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 210
11.13.1 Ficheros srm.conf y access.conf . . . . . . . . . . . . . . . . . . . . . 210
11.13.2 Permisos en ficheros de Apache . . . . . . . . . . . . . . . . . . . . . 211
11.13.3 Directiva UserDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
11.13.4 Accesos a páginas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
11.13.5 Sobreescritura de configuración . . . . . . . . . . . . . . . . . . . . . 212
11.13.6 Identidad del servidor. User y Group . . . . . . . . . . . . . . . . . . . 213
11.13.7 Problemas de Apache relacionados con DNS . . . . . . . . . . . . . . 213
11.13.8 Option Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
11.14Comprobaciones de la configuración del servidor . . . . . . . . . . . . . . . 213
11.14.1 mod_status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
11.1. INTRODUCCIÓN 151

11.14.2 mod_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

11.1 Introducción

Apache se configura mediante directivas que se escriben como texto plano y se pueden almacenar
en varios ficheros que generalmente residen en el directorio conf. El servidor se construye de
manera modular, cada nuevo módulo proporciona sus propias directivas de configuración.

En este capítulo se muestran cuales son los ficheros, directivas y módulos utilizados en una
configuración básica, además se comentan ciertos aspectos de seguridad relacionados y algunas
herramientas típicas de chequeo de la configuración.

11.2 Ficheros

Las directivas de configuración residen en ficheros de texto plano. Actualmente los desarrolladores
de Apache recomiendan centralizar todas las directivas en httpd.conf, aunque también es posible
distribuirlas entre una serie de ficheros estándar:

httpd.conf: es el fichero principal, donde se deben incluir todas las directivas. Tradicionalmente
en este fichero sólo se incluía la configuración del servidor principal y existían otros
dos ficheros (srm.conf y access.conf) donde se incluían otros tipos de directivas.
httpd.conf es analizado por Apache antes de cualquier otro archivo de configuración.

srm.conf: puede utilizarse para definir los recursos del servidor (como las asignaciones de
directorios o los iconos). En las distribuciones actuales todavía se incluye una copia de
este fichero, aunque el Apache Group recomienda que no se utilice. Si a pesar de ello se
opta por utilizarlo, debe indicarse su localización mediante la directiva ResourceConfig en
el fichero principal httpd.conf.

access.conf: puede utilizarse para definir los permisos de acceso a directorios y localizaciones.
Al igual que el caso anterior, en las distribuciones actuales todavía aparece una copia del
fichero, aunque el Apache Group recomienda que no se utilice. Si se quisiese utilizar debería
incluirse la directiva AccessConfig en el fichero principal httpd.conf.

otros ficheros globales: existen varios módulos que requieren ficheros de configuración
adicionales, por ejemplo, el módulo mod_mime_magic necesita un fichero llamado magic.
Y el módulo mod_mime utiliza un fichero llamado mime.types.
AccessFileName, directiva Apache

.htaccess: son unos ficheros especiales que permiten la gestión descentralizada de Apache.
El nombre .htaccess se ha elegido por convenio y puede modificarse con la directiva
152 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

AccessFileName. El administrador del sitio puede determinar que directivas permite

poner en estos ficheros mediante AllowOverride en el fichero principal httpd.conf.
Las directivas que aparecen en estos ficheros .htaccess se aplican al directorio que los
contienen y a todos sus subdirectorios. Los cambios de configuración en .htaccess toman
efecto automáticamente, ya que se leen en cada petición1 .

11.3 Módulos

Apache es un programa modular, esto quiere decir que sólo la funcionalidad más básica se incluye
en el núcleo2 del servidor. El resto de características pueden ser cargadas como módulos. Por
defecto se incluyen un conjunto básico de ellos cuando se compila el servidor. Si se ha compilado
con soporte a DSO (vea el apéndice B en la página 367), los módulos serán ficheros separados que
pueden ser añadidos en cualquier momento mediante la directiva LoadModule. Incluso puede
utilizarse una configuración con directivas condicionales, de manera que se pueda detectar la
presencia o no de los módulos mediante un bloque <IfModule>.

11.4 Directivas

Apache es configurado mediante directivas. Cada módulo ofrece las suyas, esto hace que exista
una gran cantidad. Actualmente se enumeran en la documentación de Apache 210 directivas (sin
contar las de muchos módulos de terceras partes). El número de directivas no debe asustar, en
realidad la configuración de un servidor básico puede realizarse sólo con unas pocas.

11.4.1 Definición de una directiva

En el resto de este capítulo se van a hacer un repaso de las directivas más básicas. Pero, ¿cómo
se define una directiva? En la documentación de Apache se muestra cuál es el formato común de
descripción que todas las directivas de cualquier módulo deben seguir. La “ficha” de una directiva
típica incluye:

Syntax: nombre_de_directiva argumentos.



Default: nombre_de_directiva valor_por_defecto.



Context: lista_de_contextos.


Override: característica_sobreescritura.


Status: estado.
1 Esto puede ser un poco ineficiente en directorio muy visitados.
2 Traducción libre del inglés core.
11.4. DIRECTIVAS 153

Module: nombre_del_módulo.


Compatibility: notas_de_compatibilidad.


Finalmente se incluye una descripción textual de la directiva.

Para algunas directivas no es necesario incluir todos estos campos, de todas formas, es conveniente
conocer cuál es significado de cada uno. Para ello pueden consultarse los siguientes apartados.

Syntax (sintaxis)

Syntax: nombre_de_directiva argumentos

Indica el formato de la directiva tal y como debe aparecer en el fichero de configuración. El

nombre_de_directiva no es sensible a mayúsculas ni minúsculas3 y generalmente aparece
seguido de uno o más argumentos.

Default (valor por defecto)

Default: nombre_de_directiva valor_por_defecto

Hay directivas que tienen un valor por defecto, es decir, que si no aparecen en el fichero de
configuración, el servidor Web procede considerando un valor predeterminado.

Context (contexto)

Context: lista_de_contextos

El contexto indica donde es válido aplicar una directiva. Si se intenta colocar una directiva fuera de
su contexto se obtiene un error de configuración y el servidor no arrancará. Si es correcto aplicar
la directiva en varios sitios, estos aparecen como una lista separada por comas. Los posibles
contextos son los siguientes:


server config: indica que la directiva puede ser utilizada en los ficheros de configuración
del servidor (httpd.conf, srm.conf y access.conf), pero no dentro de un host virtual
<VirtualHost>, directorio <Directory> o fichero .htaccess.


virtual host: indica que la directiva puede ser utilizada dentro del contenedor
<VirtualHost>.


directory: indica que la directiva puede ser utilizada dentro de los contenedores
<Directory>, <Location> y <Files>.


.htaccess: si una directiva es válida en este contexto, podrá aparecer en ficheros de

configuración basados en directorios .htaccess.
3 Aunque por convenio las directivas comienzan por mayúsculas.
154 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Override (sobreescribe)

Override: característica_sobreescritura

Este atributo indica que configuración de sobreescritura debe estar activa para que la directiva
sea procesada cuando aparece en un fichero .htaccess. La sobreescritura la maneja la directiva
AllowOverride, esta puede establecer distintos valores que indican el grado de sobreescritura
permitido.

Status (status)

Status: estado

El estado indica el grado de integración entre el módulo que contiene a la directiva y el servidor
Web Apache.

Core: la directiva forma parte del núcleo de Apache, y por tanto estará siempre disponible.


Base: la directiva es soportada por uno de los módulos estándar. Estos módulos se compilan
por defecto con el servidor, por tanto, si se ha hecho una instalación típica la directiva
debería estar disponible.


Extension: la directiva la proporciona un módulo que se distribuye con Apache, pero que
no es compilado por defecto. Para poder utilizar la funcionalidad de esta directiva se debe
recompilar el servidor habilitando el módulo en cuestión.


Experimental: la directiva se incluye en un módulo de Apache que no ha sido todavía lo

suficientemente probado ni documentado. Todos los módulos de terceros se consideran
experimentales. Un módulo experimental puede o no compilarse por defecto.

Module (módulo)

Module: nombre_del_módulo

Simplemente indica el nombre del módulo que proporciona la directiva.

Compatibility (compatibilidad)

Compatibility: notas_de_compatibilidad

Aparecen datos como la versión de Apache en la que se incorporó la directiva, posibles

inconsistencias de comportamiento entre versiones, ...
11.5. DEFINICIÓN DEL ENTORNO DEL SERVIDOR PRINCIPAL 155

11.4.2 Una posible clasificación de las directivas

Con objeto de proporcionar una visión global se presentarán en la siguiente sección algunas de
las directivas más importantes. Para cada una de ellas se incluye un ejemplo que no es más que
el “pedazo” de fichero httpd.conf por defecto donde aparece4 . Mostrar todas las directivas una
tras otra es poco didáctico (y además ya está hecho en la documentación on-line de Apache [16])
por ello se ha decidido presentarlas atendiendo a esta clasificación:

1. Directivas del entorno del servidor principal.

2. Directivas para indexación de directorios y “fancyindexing”.

3. Directivas de definición de contenedores y alias.

4. Directivas de establecimiento de tipos MIME.

5. Directivas de configuración del log.

6. Directivas para el control (acceso, ejecución, etc.) de secciones.

7. Directivas específicas para configurar hosts virtuales.

8. Otras directivas habituales.

11.5 Definición del entorno del servidor principal

Estas directivas se usan para configurar el servidor en sí mismo (son válidas en el contexto server
config, y en algunos casos también en virtual host). Los valores de configuración a este nivel
son heredados por los hosts virtuales a no ser que sean específicamente sobreescritos. Al afectar al
servidor de manera global es muy importante establecer estas directivas con sus valores adecuados,
aunque en la mayoría de los casos la configuración por defecto de Apache puede ser capaz de
determinarlos por si mismo. Se puede hacer una subclasificación:

11.5.1 Identificación del servidor

ServerAdmin

Sintaxis: ServerAdmin dirección-correo

Contexto: server config, virtual host

Estado: core
4 Si los hay, se incluyen los comentarios originales.
156 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Configura la dirección de correo que incluye el servidor en cualquier mensaje de error enviado al
cliente.

Un ejemplo sería:

# ServerAdmin: Your address, where problems with the server

# should be e-mailed. This address appears on some
# server-generated pages, such as error documents.

ServerAdmin txapi@montsfortis.micasa.es

Listado 11.1 Directiva ServerAdmin.

ServerName

Sintaxis: ServerName nombre-de-dominio-completamente-cualificado



Contexto: server config, virtual host



Estado: core

Establece el nombre y dominio del host del servidor, que se utilizará para crear URLs absolutas.
Si no se incluye esta directiva, Apache intenta determinar este valor por si mismo. Es posible que
el nombre determinado no sea el adecuado5 y a veces simplemente no puede encontrar el nombre
porque no está disponible la resolución inversa de nombres. En estos casos, cuando se ejecuta el
servidor Web la primera vez, se obtiene un error:

httpd: cannot determine local host name

Puede corregirse editando el fichero de configuración y estableciendo el valor correcto para esta
directiva. También se puede usar ServerName dentro de hosts virtuales, especificando el nombre
completamente cualificado de cada uno de ellos.

Un ejemplo sería:

# ServerName allows you to set a host name which is sent back to

# clients for your server if it’s different than the one the
# program would get (i.e., use "www" instead of the host’s name).
#
# Note: You cannot just invent host names and hope they work. The
# name you define here must be a valid DNS name for your host. If
5 Sobre todo si el equipo maneja distintas direcciones IP, bien por alias, o bien por tener distintas interfaces físicas.
11.5. DEFINICIÓN DEL ENTORNO DEL SERVIDOR PRINCIPAL 157

# you don’t understand this, ask your network administrator.

# If your host doesn’t have a registered DNS name, enter its IP
# address here. You will have to access it by its address (e.g.,
# http://123.45.67.89/) anyway, and this will make redirections
# work in a sensible way.
#
# 127.0.0.1 is the TCP/IP local loop-back address, often named
# localhost. Your machine always knows itself by this address. If
# you use Apache strictly for local testing and development, you
# may use 127.0.0.1 as the server name.
#
ServerName montsfortis.micasa.es

Listado 11.2 Directiva ServerName.

ServerSignature

Sintaxis: ServerSignature On|Off|EMail



Defecto: ServerSignature Off



Contexto: server config, virtual host, directory, .htaccess



Estado: core


Compatibilidad: desde Apache 1.3.

Permite la configuración del pie de página que aparece en ciertos mensajes generados por el
servidor (mensajes de error, salida de mod_info, etc.).

Si se utiliza ServerSignature On, se añade una línea con el número de versión de Apache, el
nombre del servidor ServerName, y el email del responsable ServerAdmin. Un ejemplo sería:

# Optionally add a line containing the server version and virtual

# host name to server-generated pages (error documents, FTP
# directory listings, mod_status and mod_info output etc., but not
# CGI generated documents).
# Set to one of: On | Off | EMail
ServerSignature On

Listado 11.3 Directiva ServerSignature.

158 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

11.5.2 Localización de ficheros o módulos

AccessFileName

Sintaxis: AccessFileName nombre-fichero [nombre-fichero] ...



Defecto: AccessFileName .htaccess



Contexto: server config, virtual host



Estado: core


Compatibilidad: Puede aceptar más de un nombre-fichero desde Apache 1.3.

Establece el nombre del fichero, que contenido en un directorio, obliga al servidor a buscar
en él posibles restricciones de acceso. Este comportamiento es regulado por la directiva
AllowOverride.

Por razones de eficiencia, se recomienda la siguiente configuración por defecto:

<Directory />
AllowOverride None
</Directory>

ya que sin ella, si se supone que el DocumentRoot es /usr/local/apache/htdocs, Apache

buscaría posibles .htaccess6 en:

/.htaccess
/usr/.htaccess
/usr/local/.htaccess
/usr/local/apache/.htaccess
/usr/local/apache/htdocs/.htaccess

y esto generalmente provoca un retardo innecesario en la velocidad de respuesta del servidor.

Un ejemplo sería:

# AccessFileName: The name of the file to look for in each directory

# for access control information.
#
AccessFileName .htaccess

Listado 11.4 Directiva AccessFileName.

6O cualquiera que fuese el nombre especificado en AccessFileName.

11.5. DEFINICIÓN DEL ENTORNO DEL SERVIDOR PRINCIPAL 159

AddModule

Sintaxis: AddModule módulo [módulo] ...

Contexto: server config

Estado: core

Compatibilidad: disponible desde Apache 1.2.

El servidor puede tener módulos compilados, pero no en uso. Con esta directiva poden habilitarse.

Un ejemplo sería:

AddModule mod_vhost_alias.c
AddModule mod_env.c
---- Omitimos varias líneas ----

Listado 11.5 Directiva AddModule.

ClearModuleList

Sintaxis: ClearModuleList

Contexto: server config

Estado: core

Compatibilidad: disponible desde Apache 1.2.

El servidor trae una lista preconstruida de módulos activos. Esta directiva limpia la lista. Se asume
que luego la lista de módulos va a ser reconstruída usando directivas AddModule.

Un ejemplo sería:

# Reconstruction of the complete module list from all available modules

# (static and shared ones) to achieve correct module execution order.
# [WHENEVER YOU CHANGE THE LOADMODULE SECTION ABOVE UPDATE THIS, TOO]
ClearModuleList

Listado 11.6 Directiva ClearModuleList.

160 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

DocumentRoot

Sintaxis: DocumentRoot directorio-fichero



Defecto: DocumentRoot /usr/local/apache/htdocs



Contexto: server config, virtual host



Estado: core

Establece el directorio desde el que se sirven los ficheros. A menos que la petición corresponda a
un Alias, el servidor usa esta directiva para determinar la ubicación absoluta del fichero solicitado.

Un ejemplo sería:

# DocumentRoot: directory out of which you will serve your documents.

# By default, all requests are taken from this directory, but
# symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/usr/local/apache/htdocs"

Listado 11.7 Directiva DocumentRoot.

<IfModule>

Sintaxis: <IfModule [!]nombre-módulo7 > ... </IfModule>



Defecto: None


Contexto: all


Estado: core


Compatibilidad: desde la versión 1.2.

La directiva <IfModule test>...</IfModule> define una sección que se usa para marcar una serie
de directivas condicionales. Dentro de esta sección las directivas sólo se procesan si el test
devuelve verdadero. Esta directiva en anidable, dando lugar a comprobaciones complejas.

Los test tienen dos posibles formatos:

1. nombre-módulo: las directivas en el bloque se procesan si el módulo de nombre

nombre-módulo fue compilado con Apache.
7 Este es un nombre de módulo en tiempo de compilación, por ejemplo, mod_cgi.c
11.5. DEFINICIÓN DEL ENTORNO DEL SERVIDOR PRINCIPAL 161

2. !nombre-módulo: las directivas en el bloque se procesan si el módulo de nombre

nombre-módulo no fue compilado con Apache.

Un ejemplo sería:

# UserDir: The name of the directory which is appended onto

# a user’s home directory if a ~user request is received.
#
<IfModule mod_userdir.c>
UserDir disabled root public_html
</IfModule>

Listado 11.8 Directiva <IfModule>.

LoadModule

Sintaxis: LoadModule módulo nombre-fichero



Contexto: server config



Estado: base


Módulo: mod_so.

Esta directiva enlaza la biblioteca contenida en nombre-fichero y añade la estructura del módulo
con el nombre módulo a la lista de módulos. El argumento módulo es el nombre de la variable
externa (de tipo módulo). El listado de las disponibles se lista como identificador de módulo en la
documentación sobre módulos de Apache.

Un ejemplo sería:

# Dynamic Shared Object (DSO) Support

#
# To be able to use the functionality of a module which was built as
# a DSO you have to place corresponding ‘LoadModule’ lines at this
# location so the directives contained in it are actually available
# _before_ they are used.
# Please read the file README.DSO in the Apache 1.3 distribution for
# more details about the DSO mechanism and run ‘httpd -l’ for the
# list of already built-in (statically linked and thus always
# available) modules in your httpd binary.
#
162 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

# Note: The order in which modules are loaded is important. Don’t

# change the order below without expert advice.
#
# Example:
# LoadModule foo_module libexec/mod_foo.so
LoadModule vhost_alias_module libexec/mod_vhost_alias.so
LoadModule env_module libexec/mod_env.so

---- Omitimos varias líneas ----

Listado 11.9 Directiva LoadModule.

PidFile

Sintaxis: PidFile nombre-de-fichero



Defecto: PidFile logs/httpd.pid



Contexto: server config



Estado: core

Establece el fichero en el que se almacena el identificador de proceso para el servidor Web. Esta
directiva sólo se usa en el modo de ejecución standalone y se suele utilizar en los scripts que paran
o rearrancan el servidor (vea la sección 10.6 en la página 144):

Un ejemplo sería:

# PidFile: The file in which the server should record its process
# identification number when it starts.
#
PidFile /usr/local/apache/logs/httpd.pid

Listado 11.10 Directiva PidFile.

ScoreBoardFile

Sintaxis: ScoreBoardFile nombre-de-fichero



Defecto: ScoreBoardFile logs/apache_status



Contexto: server config

11.5. DEFINICIÓN DEL ENTORNO DEL SERVIDOR PRINCIPAL 163

Estado: core

Esta directiva se usa en algunas arquitecturas como un fichero de comunicación entre procesos
hijos y padre. En Linux no es necesario. Para saber si nuestro sistema necesita de un
ScoreBoardFile o no, la mejor forma es ejecutar Apache y controlar si el fichero es creado.

Un ejemplo sería:

# ScoreBoardFile: File used to store internal server process

# information. Not all architectures require this. But if
# yours does (you’ll know because this file will be created
# when you run Apache) then you *must* ensure that no two
# invocations of Apache share the same scoreboard file.
#
ScoreBoardFile /usr/local/apache/logs/httpd.scoreboard

Listado 11.11 Directiva ScoreBoardFile.

ServerRoot

Sintaxis: ServerRoot directorio



Defecto: ServerRoot /usr/local/apache



Contexto: server config



Estado: core

Establece el directorio donde reside el servidor. En los ficheros de configuración, todas las rutas
relativas lo serán respecto a este directorio. En una instalación típica bajo el directorio que se
establece en ServerRoot aparecerán directorios como conf o logs.

Se puede especificar el valor de esta directiva al ejecutar el servidor desde la línea de comandos.
Esto permite, poder lanzar distintos servidores con sólo un ejecutable y distintas configuraciones.
Por ejemplo:

/usr/local/apache/bin/httpd -d /usr/local/proyecto/apache1

Un ejemplo sería:

# ServerRoot: The top of the directory tree under which the server’s
# configuration, error, and log files are kept.
#
164 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

# NOTE! If you intend to place this on an NFS (or otherwise network)

# mounted filesystem then please read the LockFile documentation
# (<URL:http://www.apache.org/docs/mod/core.html#lockfile>)
# you will save yourself a lot of trouble.
#
ServerRoot "/usr/local/apache"

Listado 11.12 Directiva ServerRoot.

11.5.3 Creación de procesos

Group

Sintaxis: Group grupo-unix (nombre o número)



Defecto: Group #-1



Contexto: server config, virtual host



Estado: core

Establece el grupo bajo el que el servidor responde las peticiones. Al igual que con User, para
ejecutar esta directiva se debe estar ejecutando el servidor en modo standalone.

Un ejemplo sería:

Group nobody

Listado 11.13 Directiva Group.

MaxClients

Sintaxis: MaxClients número



Defecto: MaxClients 256



Contexto: server config



Estado: core

Establece el límite en el número de peticiones simultáneas que el servidor puede soportar. No

se podrán crear más de este número de procesos hijo. Para superar el número de 256 se debe
recompilar tras modificar el valor de HARD_SERVER_LIMIT en el fichero httpd.h .
11.5. DEFINICIÓN DEL ENTORNO DEL SERVIDOR PRINCIPAL 165

Si se tienen más peticiones simultáneas que las que permite esta directiva, serán introducidas en
una cola hasta que un proceso hijo quede libre.

Un ejemplo sería:

# Limit on total number of servers running, i.e., limit on the number

# of clients who can simultaneously connect --- if this limit is ever
# reached, clients will be LOCKED OUT, so it should NOT BE SET TOO LOW.
# It is intended mainly as a brake to keep a runaway server from taking
# the system with it as it spirals down...
#
MaxClients 150

Listado 11.14 Directiva MaxClients.

MaxRequestsPerChild

Sintaxis: MaxRequestsPerChild número



Defecto: MaxRequestsPerChild 0


Contexto: server config



Estado: core

Establece el límite en el número de peticiones que puede manejar un proceso hijo. Si el valor es
“0” el proceso hijo puede manejar un número ilimitado de peticiones. Un valor distinto de “0”
tiene efectos beneficiosos:

1. Limita la cantidad de memoria que el proceso consume. Esta es una buena medida de
protección anre un problema de memoria accidental.

2. Dando a los procesos un tiempo finito, se reduce el número de procesos cuando la carga
baja.

Un ejemplo sería:

# MaxRequestsPerChild: the number of requests each child process is

# allowed to process before the child dies. The child will exit so
# as to avoid problems after prolonged use when Apache (and maybe the
# libraries it uses) leak memory or other resources. On most systems,
# this isn’t really needed, but a few (such as Solaris) do have notable
# leaks in the libraries. For these platforms, set to something like
166 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

# 10000 or so; a setting of 0 means unlimited.

#
# NOTE: This value does not include keepalive requests after the initial
# request per connection. For example, if a child process handles
# an initial request and 10 subsequent "keptalive" requests, it
# would only count as 1 request towards this limit.
#
MaxRequestsPerChild 0

Listado 11.15 Directiva MaxRequestsPerChild.

MaxSpareServers

Sintaxis: MaxSpareServers número



Defecto: MaxSpareServers 10


Contexto: server config



Estado: core

Establece el número máximo de procesos hijos inactivos. El proceso padre se encarga de matar
algún proceso hijo cuando se supera el valor establecido en esta directiva.

El ajuste de esta directiva es necesario en sitios con mucha carga. Establecer un valor alto no suele
ser buena idea.

Un ejemplo sería:

MaxSpareServers 10

Listado 11.16 Directiva MaxSpareServers.

MinSpareServers

Sintaxis: MinSpareServers número



Defecto: MinSpareServers 5


Contexto: server config



Estado: core
11.5. DEFINICIÓN DEL ENTORNO DEL SERVIDOR PRINCIPAL 167

Establece el número mínimo de procesos hijos inactivos. Un proceso inactivo es aquel que no
está manejando una conexión. El proceso padre puede crear nuevos procesos hijos a un ritmo
máximo de uno por segundo. Las consideraciones de uso de esta directiva son las mismas que
para MaxSpareServers.
Un ejemplo sería:

#
# Server-pool size regulation. Rather than making you guess how many
# server processes you need, Apache dynamically adapts to the load it
# sees --- that is, it tries to maintain enough server processes to
# handle the current load, plus a few spare servers to handle transient
# load spikes (e.g., multiple simultaneous requests from a single
# Netscape browser).
#
# It does this by periodically checking how many servers are waiting
# for a request. If there are fewer than MinSpareServers, it creates
# a new spare. If there are more than MaxSpareServers, some of the
# spares die off. The default values are probably OK for most sites.
#
MinSpareServers 5

Listado 11.17 Directiva MinSpareServers.

ServerType

Sintaxis: ServerType tipo



Defecto: ServerType standalone



Contexto: server config



Estado: core

Determina el modo de ejecución del servidor, puede elegirse entre dos:

1. inetd: El servidor arranca bajo el control de inetd. Esta opción no se recomienda, y de

hecho los miembros del Apache Group ni siquiera garantizan que funcione adecuadamente,
de todas formas algunos administradores lo siguen utilizando porque lo consideran más
seguro.
El modo de trabajar de inetd provoca una alta sobrecarga. Por cada conexión recibida el
proceso es el siguiente: se arranca una nueva copia del servidor, se atiende la conexión y
luego el servidor termina.
168 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

2. standalone: El servidor funciona como un demonio independiente. Esta es la forma de

ejecución más eficiente. El servidor es arrancado y sirve todas las conexiones recibidas.

Un ejemplo sería:

# ServerType is either inetd, or standalone. Inetd mode is

# only supported on Unix platforms.
#
ServerType standalone

Listado 11.18 Directiva ServerType.

StartServers

Sintaxis: StartServers número



Defecto: StartServers 5


Contexto: server config



Estado: core

Estable el número de procesos hijos creados en el arranque de servidor. Este parámetro

no tiene mucha importancia ya que se controla dinámicamente con las directivas anteriores
MinSpareServers, MaxSpareServers.

Un ejemplo sería:

# Number of servers to start initially --- should be a reasonable

# ballpark figure.
#
StartServers 5

Listado 11.19 Directiva StartServers.

User

Sintaxis: User identificador-unix (nombre o número)



Defecto: User #-1



Contexto: server config, virtual host

11.5. DEFINICIÓN DEL ENTORNO DEL SERVIDOR PRINCIPAL 169

Estado: core

Configura el identificador de usuario con el que el servidor responderá las peticiones. Para usar
esta directiva se debe estar ejecutando el servidor en modo standalone.

Un ejemplo sería:

#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# . On SCO (ODT 3) use "User nouser" and "Group nogroup".
# . On HPUX you may not be able to use shared memory as nobody, and the
# suggested workaround is to create a user www and use that user.
# NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
# when the value of (unsigned)Group is above 60000;
# don’t use Group nobody on these systems!
#
User nobody

Listado 11.20 Directiva User.

11.5.4 Configuración de la red

KeepAlive

Esta directiva tiene ligeros cambios de sintaxis y uso dependiendo de las versiones de Apache,
aquí sólo se indica el formato válido para las últimas versiones.

Sintaxis: KeepAlive on|off



Defecto: KeepAlive on


Contexto: server config



Estado: core


Compatibilidad: Disponible desde Apache 1.1.

Esta directiva habilita o deshabilita la característica KeepAlive de HTTP (vea la sección 2.3.2 en
la página 31).

Un ejemplo sería:
170 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

Listado 11.21 Directiva KeepAlive.

KeepAliveTimeout

Sintaxis: KeepAliveTimeout segundos



Defecto: KeepAliveTimeout 15


Contexto: server config



Estado: core


Compatibilidad: Disponible desde Apache 1.1.

Número de segundos que Apache esperará por la siguiente petición antes de cerrar la conexión.
Un valor alto de KeepAliveTimeout puede causar problemas de rendimiento en servidores con
mucha carga, ya que obliga al servidor a mantener más conexiones inactivas esperando por los
clientes.

Un ejemplo sería:

# KeepAliveTimeout: Number of seconds to wait for the next

# request from the same client on the same connection.
#
KeepAliveTimeout 15

Listado 11.22 Directiva KeepAliveTimeout

Listen

Sintaxis: Listen [dirección-IP:]puerto



Contexto: server config



Estado: core


Compatibilidad: desde Apache 1.1.

11.5. DEFINICIÓN DEL ENTORNO DEL SERVIDOR PRINCIPAL 171

Le dice a Apache que escuche en más de una dirección IP o puerto; por defecto Apache escucha
en todas las IP, pero sólo en el puerto indicado por Port.

Un número de puerto sin dirección IP hace que Apache escuche esos puertos para todas las
interfaces. Por ejemplo, se pueden especificar los siguiente puertos:

Listen 80
Listen 8080

Una dirección IP y número de puerto hace que Apache escuche exactamente esa dirección y puerto.

Listen 193.147.87.2:80
Listen 193.147.87.2:8080

Por ejemplo en la configuración por defecto de Apache aparece:

#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, in addition to the default. See also the <VirtualHost>
# directive.
#
#Listen 3000
#Listen 12.34.56.78:80

Listado 11.23 Directiva Listen.

MaxKeepAliveRequests

Sintaxis: MaxKeepAliveRequests número

Defecto: MaxKeepAliveRequests 100

Contexto: server config

Estado: core

Limita el número de peticiones permitidas por conexión cuando KeepAlive está “on”. Si se le da
el valor “0”, se permite un número ilimitado de peticiones.

Un ejemplo sería:
172 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 100

Listado 11.24 Directiva MaxKeepAliveRequests.

Port

Sintaxis: Port número



Defecto: Port 80


Contexto: server config



Estado: core

El número se refiere a un puerto y estará en un rango entre 0 y 65535. Los números menores a
1024 están reservados para servidores bien conocidos. El puerto estándar de http es el 80.

Port tiene dos funciones:

1. Especifica el número de puerto en el que escucha el servidor, en ausencia de las directivas

Listen y BindAddress. Caso de que estas directivas sí que existan, Port no tiene efecto8 .

2. Establece la variable de entorno SERVER_PORT que se puede utilizar en CGI y SSI.

Esta directiva no afecta a la configuración de host virtuales, que tienen su propia forma de
especificar el puerto en el que escuchan.

El puerto 80 es un puerto reservado (<1024), en el que sólo pueden escuchar demonios arrancados
por el root. Una vez iniciado el servidor este trabajará con los permisos de usuario y grupo
especificados en las directivas User, Group. Un ejemplo sería:

# Port: The port to which the standalone server listens. For

# ports < 1023, you will need httpd to be run as root initially.
Port 80

Listado 11.25 Directiva Port.

8 Este comportamiento un poco extraño, se mantiene por compatibilidad con el servidor de NCSA
11.5. DEFINICIÓN DEL ENTORNO DEL SERVIDOR PRINCIPAL 173

TimeOut

Sintaxis: TimeOut número



Defecto: TimeOut 300



Contexto: server config



Estado: core

Define una cantidad de tiempo en segundos. Esta cantidad será el tiempo máximo que Apache
espera a recibir:

1. Una petición GET después de que el cliente realice la conexión.

2. Dos paquetes TCP consecutivos para peticiones PUT o POST.

3. ACKs en transmisiones de respuestas de paquetes TCP.

En un futuro cada uno de estos apartados será configurable por separado.

Un ejemplo sería:

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300

Listado 11.26 Directiva TimeOut.

UseCanonicalName

Sintaxis: UseCanonicalName on|off|dns



Defecto: UseCanonicalName on


Contexto: server config, virtual host, directory



Sobreescibe: Options


Compatibilidad: desde Apache 1.3.

Con UseCanonicalName on, el servidor es capaz de construir una URL de referencia al mismo
servidor usando los valores de las directivas ServerName y Port. En versiones anteriores de
Apache se lograba el mismo resultado combinando las variables de entorno SERVER_NAME y
SERVER_PORT .
174 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Con UseCanonicalName off, el servidor es capaz de construir una URL de referencia, con los
datos que el cliente proporciona. Si tales datos no existen se usará el nombre canónico.

UseCanonicalName DNS, está pensado para su uso en servidores que alojan múltiples host
virtuales basados en IP y clientes que no proporcionan el nombre del servidor. Apache realiza
una resolución inversa de la IP solicitada para construir referencias URL al propio servidor.

Un ejemplo sería:

# UseCanonicalName: (new for 1.3) With this setting turned on,

# whenever Apache needs to construct a self-referencing URL (a
# URL that refers back to the server the response is coming from)
# it will use ServerName and Port to form a "canonical" name.
# With this setting off, Apache will use the hostname:port that
# the client supplied, when possible. This also affects
# SERVER_NAME and SERVER_PORT in CGI scripts.
#
UseCanonicalName On

Listado 11.27 Directiva UseCanonicalName.

11.6 Indexación de directorios

11.6.1 AddIcon

Sintaxis: AddIcon icono nombre [nombre]



Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: Indexes


Estado: base


Módulo: mod_autoindex.

Cuando se usa FancyIndexing en los listados de directorio se asignan iconos a cada tipo de
fichero. Esta directiva indica el icono a usar para un determinado fichero. El Apache Group
recomienda usar AddIconByType en vez de AddIcon, cuando sea posible.

El icono puede tener las mismas apariencias que en la directiva anterior. El nombre puede tener
como valores:

^^DIRECTORY^^: para directorios.

11.6. INDEXACIÓN DE DIRECTORIOS 175

^^BLANKICON^^: para líneas en blanco (por cuestiones de apariencia).



Expresión con comodines.



Extensión.


Nombre completo de fichero.

Un ejemplo sería:

AddIcon /icons/binary.gif .bin .exe

---- Omitimos varias líneas ----

Listado 11.28 Directiva AddIcon.

11.6.2 AddIconByEncoding

Sintaxis: AddIconByEncoding icono codificación-MIME [codificación-MIME] ...



Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: Indexes


Estado: base


Módulo: mod_autoindex.

Cuando se usa FancyIndexing en los listados de directorio se asignan iconos a cada tipo
de fichero. Configura el icono a mostrar junto a los ficheros con una codificación-MIME
determinada. El icono puede ser:

1. url: por supuesto URL encoded.

2. (alttext,url): para especificar además de la url un texto alternativo.

La codificación-MIME es una patrón con comodines que concuerda con la codificación del
contenido.

Un ejemplo sería:

#
# AddIcon* directives tell the server which icon to show
# for different files or filename extensions.
# These are only displayed for
176 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

# FancyIndexed directories.

AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

Listado 11.29 Directiva AddIconByEncoding.

11.6.3 AddIconByType

Sintaxis: AddIconByType icono tipo-MIME [tipo-MIME] ...



Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: Indexes


Estado: base


mod_autoindex.

Cuando se usa FancyIndexing en los listados de directorio se asignan iconos a cada tipo de
fichero. Configura el icono a mostrar junto a los ficheros de un tipo-MIME determinado. El
icono puede ser:

1. url: por supuesto URL encoded.

2. (alttext,url): para especificar además de la url un texto alternativo.

El tipo-MIME es una patrón con comodines que concuerda con los tipos Mime.

Un ejemplo sería:

AddIconByType (TXT,/icons/text.gif) text/*

---- Omitimos varias líneas ----

Listado 11.30 Directiva AddIconByType.

11.6.4 DefaultIcon

Sintaxis: DefaultIcon path-URL



Defecto: DefaultIcon
11.6. INDEXACIÓN DE DIRECTORIOS 177

Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: Indexes


Estado: base


Módulo: mod_autoindex.

Cuando se usa FancyIndexing en los listados de directorio se asignan iconos a cada tipo de
fichero. DefaultIcon establece el icono a mostrar para ficheros que no tienen asignado ningún
otro icono. path-URLindica la URL url encoded hasta el icono.
Un ejemplo sería:

# DefaultIcon is which icon to show for files which do not have

# an icon explicitly set.
#
DefaultIcon /icons/unknown.gif

Listado 11.31 Directiva DefaultIcon.

11.6.5 DirectoryIndex


Sintaxis: DirectoryIndex URL-local [URL-local] ...



Defecto: DirectoryIndex index.html



Contexto: server config, virtual host, directory, .htaccess



Estado: base


Módulo: mod_dir.

Establece la lista de recursos a buscar cuando un cliente realiza una petición de un directorio.
URL-locales la codificación-URL del documento relativo al directorio dado, generalmente es una
página Web de índice. Si no existe en el directorio ninguno de los recursos indicados, y la opción
Indexes está activada, se muestra el listado del directorio.
Un ejemplo sería:

# DirectoryIndex: Name of the file or files to use as a pre-written

# HTML directory index. Separate multiple entries with spaces.
#
<IfModule mod_dir.c>
DirectoryIndex index.html
</IfModule>
178 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Listado 11.32 Directiva DirectoryIndex.

11.6.6 HeaderName

Sintaxis: HeaderName nombre-fichero

Contexto: server config, virtual host, directory, .htaccess

Sobreescribe: Indexes

Estado: base

Módulo: mod_autoindex.

Compatibilidad: algunas características sólo desde la versión 1.3.6.

Establece el nombre-fichero que se añade al principio de un listado de directorio, este

nombre es relativo al directorio listado, y puede proporcionar algún tipo de información útil
relativa al contenido del directorio. Esta directiva está sujeta a las mismas consideraciones que
ReadmeName.

Un ejemplo sería:

# HeaderName is the name of a file which should be prepended to

# directory indexes.
#
HeaderName HEADER

Listado 11.33 Directiva HeaderName.

11.6.7 IndexIgnore

Sintaxis: IndexIgnore fichero [fichero]

Defecto: .

Contexto: server config, virtual host, directory, .htaccess

Sobreescribe: Indexes

Estado: base

Módulo: mod_autoindex.
11.6. INDEXACIÓN DE DIRECTORIOS 179

Añade ficheros a la lista de ficheros que deben ser ocultados en los listados de directorio. fichero
puede ser una extensión, una nombre parcial, una expresión con comodines, o el nombre completo
del fichero a ignorar.

Un ejemplo sería:

# IndexIgnore is a set of filenames which directory indexing should

# ignore and not include in the listing. Shell-style wildcarding is
# permitted.
#
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

Listado 11.34 Directiva IndexIgnore

11.6.8 IndexOptions

Sintaxis: IndexOptions opción [opción] ...

Sintaxis: IndexOptions [+|-]opción [+|-][opción] ...


Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: Indexes


Estado: base


Módulo: mod_autoindex.


Compatibilidad: Sintaxis ’+/-’ desde Apache 1.3.3.

Opciones FoldersFirst y DescriptionWidthdesde versión 1.3.10.
Opción TrackModified desde Apache 1.3.15.

Especifica el comportamiento de el listado automático de directorios. Permite las siguientes

opciones:

DescriptionWidth=[n | *]: permite determinar el ancho en caracteres de la columna de

descripción. Un valor de ’*’ indica que el tamaño será el del tamaño del campo mayor.

FancyIndexing: habilita el listado “mejorado” de directorios.

FoldersFirst: ordena la salida del FancyIndexed , presentando los directorios primero.

IconHeight[=pixels]: establece el atributo HEIGHT en la imagen icono.

IconsAreLinks: hace que los iconos formen parte del enlace del fichero al que representan.

IconWidth[=pixels]: establece el atributo WIDTH en la imagen icono.

180 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

NameWidth=[n | *]: permite determinar el ancho en caracteres de la columna de nombre. Un

valor de ’*’ indica que el tamaño será el del tamaño del campo mayor.

ScanHTMLTitles: extrae información del título de los documentos HTML para presentar en el
listado mejorado.

SuppressColumnSorting: hace que las columnas de la cabecera no sean enlaces que ordenan el
listado.

SuppressDescription: elimina la columna de descripción del listado.

SuppressHTMLPreamble: si el directorio contiene un fichero especificado en la directiva

HeaderName, se incluye su contenido al principio del documento pero después de un
preámbulo en HTML. Con SuppressHTMLPreamble se suprime este preámbulo.

SuppressLastModified: no muestra la columna con la fecha de última modificación.

SuppressSize: no muestra la columna con los tamaños de los ficheros.

TrackModified: devuelve datos sobre los ficheros como parte de las cabeceras HTTP. El cliente
puede darse cuenta de los cambios cuando ejecuta una petición HEAD.

Un ejemplo sería:

# FancyIndexing: you want fancy directory indexing or standard?

#
IndexOptions FancyIndexing

Listado 11.35 Directiva IndexOptions

11.6.9 ReadmeName

Sintaxis: ReadmeName nombre-fichero

Contexto: server config, virtual host, directory, .htaccess

Sobreescribe: Indexes

Estado: base

Módulo: mod_autoindex.

Compatibilidad: algunas características sólo desde la versión 1.3.6.

11.7. DIRECTIVAS CONTENEDORAS Y ALIAS 181

Establece el nombre-fichero que se añade al final de un listado de directorio. Este nombre

es relativo al directorio listado y puede proporcionar algún tipo de información útil relativa al
contenido del directorio.
Existen ciertas consideraciones9 en como se interpreta el nombre-fichero. El servidor busca en
primer lugar nombre-fichero .html, si no lo encuentra busca sólo nombre-fichero y si no lo
encuentra no muestra nada.
Un ejemplo sería:

# ReadmeName is the name of the README file the server will look for by
# default, and append to directory listings.
# If MultiViews are amongst the Options in effect, the server will
# first look for name.html and include it if found. If name.html
# doesn’t exist, the server will then look for name.txt and include
# it as plaintext if found.
#
ReadmeName README

Listado 11.36 Directiva ReadmeName.

11.7 Directivas contenedoras y alias

Generalmente el ámbito de una directiva Apache es restringido usando directivas especiales

llamadas contenedoras. Estas directivas especiales se identifican fácilmente por estar encerradas
entre los símbolos <...> . Los alias permiten hacer referencias a localizaciones que pueden no
estar bajo el directorio raíz del Web.

11.7.1 Alias

Sintaxis: Alias path-URL directorio-fichero



Contexto: server config, virtual host



Estado: base


Módulo: mod_alias.

Esta directiva permite que documentos sean almacenados en partes del sistema local de ficheros
que no están bajo el DocumentRoot.
El path-URL es una ruta codificada como URL (vea la sección A.3 en la página 362) que es
mapeada al directorio-fichero. Por ejemplo:
9 Algunas consideraciones más complejas pueden encontrarse en la documentación de Apache [16]
182 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Alias /download /ftp/pub/

Una petición a http://miservidor/download/archivo1.tgz hace que el servidor devuelva el

archivo /ftp/pub/archivo1.tgz.

Deberían utilizarse las directivas <Directory> o <Location> para configurar adecuadamente las
localizaciones a las que se refieren los alias.

Una cosa a tener en cuenta es que si el path-URL incluye una barra “/” al final, esta deberá formar
parte obligatoriamente del URL. Por ejemplo con:

Alias /download/ /ftp/pub/

una petición a http://miservidor/download no funcionaría, en cambio http://miservidor/

download/ si lo haría.

Un ejemplo:

# Aliases: Add here as many aliases as you need (with no limit).

# The format is Alias fakename realname
#
<IfModule mod_alias.c>
#
# Note that if you include a trailing / on fakename then the
# server will require it to be present in the URL. So
# "/icons" isn’t aliased in this example, only "/icons/". If
# the fakename is slash-terminated, then the realname must
# also be slash terminated, and if the fakename omits the
# trailing slash, the realname must also omit it.
#
Alias /icons/ "/usr/local/apache/icons/"

<Directory "/usr/local/apache/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<\IfModule>

Listado 11.37 Directiva Alias.

11.7. DIRECTIVAS CONTENEDORAS Y ALIAS 183

11.7.2 <Directory>

Sintaxis: <Directory directorio>...</Directory>



Contexto: server config, virtual host



Estado: core

Encierra un grupo de directivas que se aplicarán sólo en el directorio (y subdirectorios) que se

especifica. Se puede utilizar cualquier directiva que esté permitida en el contexto directorio.

directorio puede ser:

1. Un path completo.

2. Una cadena con comodines (?, *, []).

3. Desde Apache 1.2 también se permiten expresiones regulares extendidas (vea el apéndice C
en la página 373), para ello se indica en primer lugar el carácter ~.

Existen abundantes ejemplos de esta directiva en la documentación de Apache [16]. Un ejemplo

sería:

# Each directory to which Apache has access, can be configured with

# respect to which services and features are allowed and/or disabled
# in that directory (and its subdirectories).
#
# First, we configure the "default" to be a very restrictive set of
# permissions.
#
<Directory />
Options FollowSymLinks
AllowOverride None
<\Directory>

Listado 11.38 Directiva <Directory>.

La directiva <DirectoryMatch> funciona de manera muy parecida pero incorporando la

posibilidad de especificar directorios por medio de expresiones regulares.

11.7.3 <Files>

Sintaxis: <Files nombre-fichero> ... </Files>

184 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Contexto: server config, virtual host, .htaccess



Estado: core


Compatibilidad: desde Apache 1.2.

Proporciona una sección para el control de acceso por fichero. Permite un grano más fino que
con <Directory> o Location. Las directivas dentro de la sección se aplicarán a los ficheros que
emparejen con el patrón especificado.

Las secciones <Files> se procesan según su orden de aparición en el fichero de configuración,

después de <Directory y .htaccess, pero antes de <Location>.

El argumento nombre-fichero puede incluir:

1. Un nombre de fichero completo.

2. Una cadena con comodines (?, *, []).

3. Desde Apache 1.2 también se permiten expresiones regulares extendidas (vea el apéndice C
en la página 373), para ello se indica en primer lugar el carácter ~.

Un ejemplo sería:

#
# The following lines prevent .htaccess files from being viewed by
# Web clients. Since .htaccess files often contain authorization
# information, access is disallowed for security reasons. Comment
# these lines out if you want Web visitors to see the contents of
# .htaccess files. If you change the AccessFileName directive above,
# be sure to make the corresponding changes here.
#
# Also, folks tend to use names such as .htpasswd for password
# files, so this will protect those as well.
#
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>

Listado 11.39 Directiva <Files>.

La directiva <FilesMatch> funciona de manera muy parecida pero incorporando la posibilidad de

especificar los ficheros a los que afecta por medio de expresiones regulares.
11.7. DIRECTIVAS CONTENEDORAS Y ALIAS 185

11.7.4 <Limit>

Sintaxis: <Limit método [método] ...> ... </Limit>

Contexto: any

Estado: core

Controla el acceso dependiendo del método HTTP solicitado. Las directivas dentro de <Limit>
sólo se aplicarán a las peticiones HTTP realizadas con el método de acceso especificado. La
directiva <LimitExcept> funciona como la negación de la directiva Limit.

Por ejemplo, las siguientes directivas indican que para los métodos POST, PUT y DELETE se
requiere un usuario válido (usuario1) y que también se requerirá un usuario válido (usuario2)
cuando la petición se realiza con cualquier método que no sea GET:

Un ejemplo sería:

<Limit POST PUT DELETE>

Require valid-user usuario1
</Limit>

<LimitExcept GET>
Require valid-user usuario2
</Limit>

Listado 11.40 Directiva <Limit>.

11.7.5 <Location>

Sintaxis: <Location URL> ... </Location>

Contexto: server config, virtual host

Estado: core

Compatibilidad: desde Apache 1.1.

Esta directiva proporciona control de acceso mediante URLs. En cierto modo su funcionamiento
es muy similar al de <Directory>. Las secciones definidas por <Location> se procesan en el
orden en que aparecen en el fichero de configuración, después de que hayan sido procesadas las
secciones definidas por <Directory>, los ficheros .htaccess y las secciones <Files>.
186 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Lo que diferencia a <Location> es que no se refiere a ningún punto específico del sistema de
ficheros, sino a una URL. La URL a ser emparejada es de la forma /ruta/ y no deben incluirse
prefijos como http://nombredelservidor10 .

Un buen ejemplo es el siguiente:

<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>

Listado 11.41 Directiva <Location>.

<Location> permite incluir caracteres comodín (* ?) para determinar las URLs a las que afecta,
de todas formas, para utilizar versiones más potentes de expresiones regulares se puede usar la
directiva <LocationMatch>.

11.7.6 ScriptAlias

Sintaxis: ScriptAlias path-URL directorio-fichero

Contexto: server config, virtual host

Estado: base

Módulo: mod_alias.

Al igual que Alias, define un path-URL que es mapeado a un directorio-fichero. Este

directorio no tiene que estar necesariamente bajo el directorio raíz del sitio Web DocumentRoot.
El servidor considera que todo el contenido del directorio-fichero es ejecutable por medio de
CGI. La sintaxis de la directiva es:

ScriptAlias /cgi-bin/ /home/httpd/cgi-bin/

Por ejemplo si las páginas Web residen en el directorio /usr/local/apache/htdocs/ y nuestro

servidor se llama http://www.ejemplo.com, cuando se realice una petición de la URL:

http://www.ejemplo.com/cgi-bin/test-cgi
10 Este comportamiento cambia si nuestro servidor funciona como un proxy.
11.7. DIRECTIVAS CONTENEDORAS Y ALIAS 187

El servidor Web se da cuenta de que está en un directorio ScriptAlias, e intenta tratarlo como
un programa, y no solamente devolver su contenido. Comenzará la ejecución CGI del siguiente
fichero:

/home/httpd/cgi-bin/test-cgi

Un ejemplo de configuración sería:

# ScriptAlias: This controls which directories contain server scripts.

# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to
# the client. The same rules about trailing "/" apply to ScriptAlias
# directives as to Alias.
#
ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"

# "/usr/local/apache/cgi-bin" should be changed to whatever your

# ScriptAliased CGI directory exists, if you have that configured.
#
<Directory "/usr/local/apache/cgi-bin">
AllowOverride None
Options None ExecCGI
Order allow,deny
Allow from all
</Directory>

Listado 11.42 Directiva ScriptAlias.

Existe también la directiva ScriptAliasMatch, que funciona de manera parecida pero utilizando
expresiones regulares estándar en vez de rutas. La expresión regular, si empareja con la URL es
mapeada a un directorio-fichero.

11.7.7 <VirtualHost>

Sintaxis: <VirtualHost dirección-IP[:puerto] [dirección-IP[:puerto]] ...> ...

</VirtualHost>

Contexto: server config

Estado: core
188 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Compatibilidad: desde Apache 1.1 para host virtuales no basados en IP.

Desde Apache 1.2 para el soporte de múltiples direcciones.

<VirtualHost> ... </VirtualHost> se usan para crear una sección de directivas que se aplicarán
a un host virtual. Obviamente las directivas incluidas en la sección deben estar permitidas en el
contexto “server config”.
La dirección-IP puede ser una IP o un nombre de dominio completamente cualificado. Como
dirección-IP también puede usarse el nombre especial _default_ , utilizado en un host virtual,
hace que este responda a cualquier IP no configurada explícitamente en otro grupo <VirtualHost>.
Cada host virtual debe corresponderse con una dirección IP, un número de puerto o un nombre para
el servidor.
Es posible especificar varias direcciones IP, esto en útil para una máquina que responde a dos
interfaces distintas con el mismo nombre. Puede indicarse también un número de puerto específico
en cada <VirtualHost>. Si no es así, por defecto, el host virtual escucha el puerto especificado en
la directiva Port. También se puede referir a todos los números de puerto con el carácter comodín
“*”.
El uso de una dirección-IP en <VirtualHost> no asegura que Apache escuche en esa dirección.
Se necesita la directiva Listen para hacerlo.
Un ejemplo:

<VirtualHost 10.1.2.3>
ServerAdmin webmaster@miequipo.com
DocumentRoot /usr/local/htdocs/miequipo.com
ServerName www.miequipo.com
</VirtualHost>

<VirtualHost 192.168.1.2 193.147.87.211>

ServerAdmin webmaster1@miequipo.com
DocumentRoot /usr/local/htdocs/miequipo1.com
ServerName www.miequipo1.com
</VirtualHost>

Listado 11.43 Directiva <VirtualHost>.

11.8 Tipos MIME

11.8.1 AddCharset


Sintaxis: AddCharset conjunto-caracteres extensión (vea la nota al pie 11 en la página 189)

[extensión] ...
11.8. TIPOS MIME 189

Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: FileInfo


Estado: base


Módulo: mod_mime.


Compatibilidad: desde Apache 1.3.10.

Establece la correspondencia entre cada extensión de fichero y el conjunto-caracteres que

puede contener. Las última asignación de esta directiva sobreescribe cualquier correspondencia
anterior. Un ejemplo:

AddLanguage ja .ja
AddCharset ISO-2022-JP .jis

Un documento de nombre xxx.html.ja.jis será tratado como un documento html escrito en

idioma japonés con un conjunto de caracteres válidos definido por ISO-2022-JP. La directiva
AddCharsert es útil para informar al cliente sobre el conjunto de caracteres en que se codifica el
documento y que pueda interpretarlo de una manera adecuada. También es útil en la negociación
de contenido, cuando el servidor devuelve distintos documentos en función del conjunto de
caracteres preferido por el cliente.

Un ejemplo sería:

AddCharset ISO-8859-8 .iso8859-8

---- Omitimos varias líneas ----

Listado 11.44 Directiva AddCharset.

11.8.2 AddEncoding

Sintaxis: AddEncoding codificación-MIME extensión11 [extensión] ...



Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: FileInfo


Estado: base


Módulo: mod_mime.
11 El argumento extensión no es sensible a las mayúsculas y puede llevar punto o no.
190 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Mapea cada extensión de fichero a un determinado tipo de codificación-MIME. Las asignaciones

de codificación MIME con esta directiva sobreescriben cualquier correspondencia anterior. Un
ejemplo:

AddEncoding x-gzip .gz

Esto indica que los ficheros de extensión .gz han sido codificados son x-gzip12 .

Un ejemplo sería:

# AddEncoding allows you to have certain browsers (Mosaic/X 2.1+)

# uncompress information on the fly. Note: Not all browsers support
# this. Despite the name similarity, the following Add* directives
# have nothing to do with the FancyIndexing customization directives.
#
AddEncoding x-compress Z
AddEncoding x-gzip gz tgz

Listado 11.45 Directiva AddEncoding.

11.8.3 AddLanguage

Sintaxis: AddLanguage lenguaje-MIME extensión (vea la nota al pie 11 en la página 189)



Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: FileInfo


Estado: base


Módulo: mod_mime.

Mapea cada extensión de fichero a un determinado tipo de lenguaje-MIME. Las asignaciones de

tipo MIME con esta directiva sobreescriben cualquier correspondencia anterior. Un ejemplo:

AddLanguage es .es

Un documento de nombre xxx.html.es será tratado como un documento html escrito en idioma
español. La directiva AddLanguage es útil para que el servidor haga negociación de contenido,
devolviendo documentos en función de las preferencias de idioma del cliente.

Un ejemplo sería:
12 El estándar dice que esto es equivalente a gzip.
11.8. TIPOS MIME 191

# AddLanguage allows you to specify the language of a document. You

# can then use content negotiation to give a browser a file in a
# language it can understand.
#
# Note 1: The suffix does not have to be the same as the language
# keyword --- those with documents in Polish (whose net-standard
# language code is pl) may wish to use "AddLanguage pl .po" to
# avoid the ambiguity with the common suffix for perl scripts.
#
# Note 2: The example entries below illustrate that in quite
# some cases the two character ’Language’ abbreviation is not
# identical to the two character ’Country’ code for its country,
# E.g. ’Danmark/dk’ versus ’Danish/da’.
#
# Note 3: In the case of ’ltz’ we violate the RFC by using a three char
# specifier. But there is ’work in progress’ to fix this and get
# the reference data for rfc1766 cleaned up.
#
# Danish (da) - Dutch (nl) - English (en) - Estonian (ee)
# French (fr) - German (de) - Greek-Modern (el)
# Italian (it) - Korean (kr) - Norwegian (no)
# Portugese (pt) - Luxembourgeois* (ltz)
# Spanish (es) - Swedish (sv) - Catalan (ca) - Czech(cz)
# Polish (pl) - Brazilian Portuguese (pt-br) - Japanese (ja)
# Russian (ru)
#
AddLanguage da .dk

---- Omitimos varias líneas ----

Listado 11.46 Directiva AddLanguage.

11.8.4 AddType

Sintaxis: AddType tipo-MIME extensión (vea la nota al pie 11 en la página 189) [extensión]
...


Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: FileInfo


Estado: Base
192 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Módulo: mod_mime.

La directiva AddType hace corresponder un tipo de contenido especificado tipo-MIME con las
extensiones13 de fichero dadas extensión . Esta correspondencia es añadida sobreescribiendo
cualquier otra que ya exista para la misma extensión. Se suele usar esta directiva para
correspondencias que no existen en el fichero de tipos MIME, indicado con la directiva
TypesConfig.

El Apache Group recomienda añadir nuevos tipos usando esta directiva, mejor que cambiar el
contenido del fichero definido por TypesConfig.

Un ejemplo sería:

# AddType allows you to tweak mime.types without actually editing it,

# or to make certain files to be certain types.
#
# For example, the PHP 3.x module (not part of the Apache distribution
# - see http://www.php.net) will typically use:
#
#AddType application/x-httpd-php3 .php3
#AddType application/x-httpd-php3-source .phps
#
# And for PHP 4.x, use:
#
#AddType application/x-httpd-php .php
#AddType application/x-httpd-php-source .phps

AddType application/x-tar .tgz

Listado 11.47 Directiva AddType.

11.8.5 DefaultType

Sintaxis: DefaultType MIME-type

Defecto: DefaultType text/html

Contexto: server config, virtual host, directory, .htaccess

Sobreescribe: FileInfo
13 En el servidor de NCSA httpd también se permitía asignar tipos MIME a nombres de fichero. Apache no lo permite.

Las extensiones no son “case sensitive” y pueden o no llevar punto.

11.8. TIPOS MIME 193

Estado: core

En ocasiones el servidor recibe peticiones de documentos de tipos que no puede determinar con la
información que conoce sobre tipos MIME. Para estas ocasiones se define un tipo por defecto.

Un ejemplo sería:

# DefaultType is the default MIME type the server will use for a
# document if it cannot otherwise determine one, such as from
# filename extensions.
# If your server contains mostly text or HTML documents,
# "text/plain" is a good value. If most of your content is binary,
# such as applications# or images, you may want to use
# "application/octet-stream" instead to keep browsers from trying
# to display binary files as though they are text.
#
DefaultType text/plain

Listado 11.48 Directiva DefaultType.

11.8.6 LanguagePriority

Sintaxis: LanguagePriority lenguaje-MIME lenguaje-MIME



Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: FileInfo


Estado: base


Módulo: mod_negotiation.

Esta directiva establece la precedencia entre los posibles idiomas, caso de que el cliente no indique
una y sestén manejando Multiviews.

Esta directiva sólo tiene efecto si el servidor no tiene ninguna forma mejor de determinar el
idioma14 .

Un ejemplo sería:

# LanguagePriority allows you to give precedence to some languages

# in case of a tie during content negotiation.
#
14 Por tanto si el cliente implementa adecuadamente el protocolo HTTP/1.1, esta directiva no tiene efecto
194 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

# Just list the languages in decreasing order of preference. We have

# more or less alphabetized them here. You probably want to change
# this.
<IfModule mod_negotiation.c>
LanguagePriority en da nl et fr de el it ja kr no pl pt pt-br ru
ltz ca es sv tw
</IfModule>

Listado 11.49 Directiva LanguagePriority.

11.8.7 MIMEMagicFile

Sintaxis: MIMEMagicFile nombre-fichero-magic



Defecto: None


Contexto: server config, virtual host



Estado: extensión


Módulo: mod_mime_magic.

Con esta directiva se habilita el módulo que controla el tipo MIME de los ficheros atendiendo a su
número mágico. Este número no es más que un patrón que se repite en el contenido de todos los
ficheros con el mismo tipo, identificándolos.

Un ejemplo sería:

# The mod_mime_magic module allows the server to use various hints

# from the contents of the file itself to determine its type. The
# MIMEMagicFile directive tells the module where the hint
# definitions are located. mod_mime_magic is not part of the default
# server (you have to add it yourself with a LoadModule [see the DSO
# paragraph in the ’Global Environment’ section], or recompile the
# server and include mod_mime_magic as part of the configuration),
# so it’s enclosed in an <IfModule> container.

<IfModule mod_mime_magic.c>
MIMEMagicFile /usr/local/apache/conf/magic
</IfModule>

Listado 11.50 Directiva MIMEMagicFile.

11.9. UTILIDADES DE LOG 195

11.9 Utilidades de log

11.9.1 CustomLog

Sintaxis: CustomLog fichero|pipe formato|nickname [env=[!]variable-de-entorno]



Contexto: server config, virtual host



Estado: Base


Módulo: mod_log_config.


Compatibilidad: nickname fue incorporado con la versión Apache 1.3.

El logging condicional se incorporó en la versión 1.3.5.

Se utiliza para configurar el log de Apache a nuestra medida. El logging puede hacerse incluso
condicional en función de variables de entorno. El primer argumento especifica la localización en
donde deben ser escritos los logs. Puede elegirse una de las siguientes:

file: Un nombre de fichero relativo a ServerRoot o absoluto.

pipe: El carácter de tubería (pipe) seguido de la ruta hasta un programa que sepa manejar la
información de log.

El segundo argumento indica que va a ser escrito en el fichero de log. Se puede usar un “nickname”
definido en una directiva LogFormat o una cadena de formato de log.

El tercer argumento es opcional y permite el “logging” de manera condicional dependiendo de la

presencia o ausencia de una variable en el entorno. Pueden establecerse variables de entorno de
varias formas:

1. Según la petición realizada. Usando el módulo mod_setenvif. Por ejemplo:

SetEnvIf Request_URI \.gif imagengif

CustomLog gif-requests.log common env=imagengif
CustomLog nongif-requests.log common env=!imagengif

2. Mediante el módulo mod_rewrite.

Un ejemplo sería:

# The location and format of the access logfile (Common Logfile

# Format). If you do not define any access logfiles within a
# <VirtualHost> container, they will be logged here.
# Contrariwise, if you *do* define per-<VirtualHost> access
196 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

# logfiles, transactions will be logged therein and *not* in this

# file.
CustomLog /usr/local/apache/logs/access_log common

# If you would like to have agent and referer logfiles, uncomment

# the following directives.
#
#CustomLog /usr/local/apache/logs/referer_log referer
#CustomLog /usr/local/apache/logs/agent_log agent

# If you prefer a single logfile with access, agent, and referer

# information (Combined Logfile Format) you can use the following
# directive.
#CustomLog /usr/local/apache/logs/access_log combined

Listado 11.51 Directiva CustomLog.

ErrorLog

Sintaxis: ErrorLog nombre-fichero|syslog[:facilidad]



Defecto: ErrorLog logs/error_log



Contexto: server config, virtual host



Estado: core

Establece el nombre-fichero en el que se almacena el log de los errores del servidor. Si el nombre
comienza por una barra vertical (pipe), lo que le sigue es el nombre del proceso que maneja los
logs. Por ejemplo, puede utilizarse una herramienta como cronolog (vea la sección 19.3.5 en la
página 283) para dividir nuestros logs de manera temporal. En vez de nombre-fichero también
se puede usar syslog.

Un ejemplo sería:

#
# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a <VirtualHost>
# container, error messages relating to that virtual host will be
# logged here. If you *do* define an error logfile for a <VirtualHost>
# container, that host’s errors will be logged there and not here.
11.9. UTILIDADES DE LOG 197

ErrorLog /usr/local/apache/logs/error_log

Listado 11.52 Directiva ErrorLog.

HostNameLookups

Sintaxis: HostNameLookups on|off|double

Defecto: HostNameLookups off

Contexto: server config, virtual host, directory

Estado: core

Compatibilidad: las características básicas están disponibles en todas las versiones, double
sólo desde Apache 1.3.

HostNameLookups on, habilita búsquedas DNS para que los nombres de los host del cliente
puedan guardarse en el log.

HostNameLookups double, habilita búsquedas inversas dobles15 en el DNS para que los nombres
de los host del cliente puedan guardarse en el log. Este tipo de búsqueda en el DNS hace primero
una búsqueda inversa, y luego una búsqueda normal con el valor obtenido. Al menos uno de los
resultados debe coincidir con el inicial.

HostNameLookups off, lo que mejora el rendimiento al evitar las costosa latencia de las
búsquedas en el DNS. De todas formas siempre se pueden usar herramientas offline como
logresolve, o analog para obtener los nombres de dominio desde las IPs almacenadas en el log.

Un ejemplo sería:

# HostnameLookups: Log the names of clients or just their IP

# addresses e.g., www.apache.org (on) or 204.62.129.132 (off).
# The default is off

HostnameLookups Off

Listado 11.53 Directiva HostNameLookups.

15 Para gente realmente preocupada por saber de verdad el host del cliente.
198 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

11.9.2 LogFormat

Sintaxis: LogFormat format|nickname [nickname]



Defecto: LogFormat "%h %l %u %t \"%r\"%>s %b"



Contexto: server config, virtual host



Estado: base


Módulo: mod_log_config.


Compatibilidad: nickname fue incorporado con la versión Apache 1.3.

Especifica el formato de el fichero de log de accesos. Los argumentos pueden tomar dos formas:

Un argumento simple indica el formato por medio de una cadena con símbolos especiales.
Este formato será el que se aplica luego en la directiva TransferLog.


Dos argumentos se usan para asociar un formato con un nickname que servirá luego para
ser referenciado en otras directivas LogFormat o CustomLog, sin tener que repetir toda la
cadena. Con dos argumentos la directiva no tiene ningún efecto sobre TransferLog.

Un ejemplo sería:

#
# The following directives define some format nicknames for use with
# a CustomLog directive (see below).
#
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

Listado 11.54 Directiva LogFormat.

11.9.3 LogLevel

Sintaxis: LogLevel nivel



Defecto: LogLevel error



Contexto: server config, virtual host

11.9. UTILIDADES DE LOG 199

Estado: core


Módulo: mod_log_config.


Compatibilidad: desde versión 1.3.

Ajusta el nivel de explicación para los mensajes almacenados en el log. Existen varios niveles
posibles:

emerg: emergencias, el sistema no se puede utilizar.

alert: alertas, exigen que una acción se lleve a cabo inmediatamente.

crit: indican que el sistema está ante una condición crítica.

error: se ha producido un error.

warn: condiciones de aviso.

notice: condiciones normales pero significantes que deben ser anotadas.

info: información adicional.

debug: mensajes útiles en depuración.

Se recomienda el uso de un nivel mínimo de crit. Cuando se elige un nivel, todos los mensajes
de niveles superiores son mostrados también.

Un ejemplo sería:

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn

Listado 11.55 Directiva LogLevel.

11.9.4 TransferLog

Sintaxis: TransferLog fichero|pipe



Defecto: none


Contexto: server config, virtual host

200 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Estado: base

Módulo: mod_log_config.

Compatibilidad: desde versión 1.3.

Tiene los mismos argumentos y efectos que CustomLog, con la excepción de que no admite que
el formato de log se indique explícitamente. En vez de ello el formato de log se determina por la
directiva LogFormat más reciente. Se utiliza el common log si no existe una directiva LogFormat
específica.

Un ejemplo sería:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""

TransferLog logs/access_log

Listado 11.56 Directiva TransferLog.

11.10 Control de secciones

11.10.1 Allow

Sintaxis: Allow from all|host|env=nombre-variable [host|env=nombre-variable] ...

Contexto: directorio, .htaccess

Sobreescribe: Limit

Estado: base

Módulo: mod_access.

Afecta a los host que en principio pueden acceder16 a un área del servidor. El acceso puede
ser controlado por nombre, IP, rango de IPs, o por otras características de la petición del cliente
capturadas como variables de entorno.

Los argumentos pueden ser de tres tipos:

all: especifica que en principio todos los host tienen acceso.

host: especifica que host o rango de ellos tienen acceso.

16 Depende de la configuración de la directiva Order
11.10. CONTROL DE SECCIONES 201

nombre-parcial-de-dominio: Se permite el acceso a cualquier host que pertenezca al

dominio. Si un cliente no proporciona su nombre de dominio obliga al servidor a
lanzar una resolución DNS inversa17 .


dirección IP: el host con la dirección IP tiene acceso permitido.



dirección IP parcial: permite el acceso a subredes, indicando para ello uno, dos o tres
bytes de la dirección de red. Por ejemplo:

Allow from 192.168.87



red/máscara: define los host que tienen acceso a través de un número de red y su
máscara. Por ejemplo:

Allow from 192.168.87.0/255.255.255.0



red/nnn: se especifica el acceso a través de un número de red y un número entre 0 y

32 que actúa de máscara. Por ejemplo:

Allow from 192.168.87.0/8

env=nombre-variable: la petición se acepta si la variable de entorno requerida existe. Esta

directiva puede permitir el acceso atendiendo a cosas como el tipo de navegador (User-
Agent), el lugar de donde parte la petición (Referer), etc. La variable puede existir ya en el
entorno, por ejemplo, cuando se hace una petición CGI (vea la sección 3.2.2 en la página
39), o pueden crearse otras nuevas usando el módulo mod_setenvif .

Un ejemplo sería:

<Directory />
AllowOverride None
Order allow,deny
Allow from all
</Directory>

Listado 11.57 Directiva Allow.

Existe una directiva deny que funciona justo al contrario y sirve para marcar a que hosts no se
puede acceder.

11.10.2 AllowOverride

Sintaxis: AllowOverride All|None|tipo-de-directiva [tipo-de-directiva] ...

17 Esto sobrecarga al servidor, puede evitarse este comportamiento usando la directiva HostNameLookups.
202 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

Defecto: AllowOverride All



Contexto: directory


Estado: core

Cuando el servidor encuentra un fichero .htaccess necesita saber que directivas declaradas en el
mismo pueden sobreescribir directivas de acceso previas. Si AllowOverrride se establece a None,
entonces los ficheros .htaccessse ignoran por completo. Si AllowOverrride se establece a All,
entonces los cualquier directiva dentro de los ficheros .htaccess serán permitidas.

El tipo-de-directiva puede tomar varios valores:

AuthConfig: Permite el uso de directivas de autorización, como por ejemplo

AuthDBMGroupFile.

FileInfo: Permite el uso de directivas de control de tipos de documentos, como por ejemplo
AddEncoding.

Indexes: Permite el uso de directivas de control de indexado de directorios, como por ejemplo
AddDescription.

Limit: Permite el uso de directivas de control de acceso al host (Allow, Deny y Order).

Options: Permite el uso de directivas de control de características específicas de directorio

(Options y XBitHack).

Un ejemplo sería:

# This controls which options the .htaccess files in directories can

# override. Can also be "All", or any combination of "Options",
# "FileInfo", "AuthConfig", and "Limit"
#
AllowOverride None

Listado 11.58 Directiva AllowOverride.

11.10.3 Options

Sintaxis: Options [+|-]option [[+|-]option] ...



Contexto: server config, virtual host, directory, .htaccess



Defecto: Options All

11.10. CONTROL DE SECCIONES 203

Sobreescribe: Options

Estado: core

La directiva Options controla que características del servidor están disponibles en un directorio
particular.

El valor asignado puede ser None , en cuyo caso ninguna característica extra es activada, o bien al
menos una de las siguientes:

All: Todas las opciones excepto Multiviews.

ExecCGI: Permite la ejecución de programas CGI.

FollowSymLinks: El servidor sigue los enlaces simbólicos dentro del directorio. Si se sigue un
enlace simbólico, el pathname que emparejó con la directiva Directory no cambia. Esta
opción no tiene efecto dentro de la directiva Location.

Includes: Permite la utilización de Server Side Includes.

IncludesNOEXEC: Permite la utilización de Server Side Includes, excepto las directivas:

<!--#exec ... -->

<!--#include ... --> (para scripts CGI)

Indexes: Si una URL referencia un directorio en el que no existe un fichero considerado como
índice (directiva DirectoryIndex), entonces el servidor devuelve un listado formateado del
contenido del directorio.

MultiViews: Permite múltiples vistas de un contenido a través de la negociación.

SymLinksIfOwnerMatch: El servidor sigue los enlaces simbólicos sólo si el propietario del

destino es el mismo que el del enlace. Esta opción no tiene efecto dentro de la directiva
Location.

En general las opciones no se mezclan, si no que se escoge la más específica. Si se pretende que
se mezclen pueden utilizarse los modificadores [+|-].

Las opciones precedidas por + se añaden a las opciones actuales.

Las opciones precedidas por - se quitan de las opciones actuales.

Un ejemplo sería:
204 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

# This may also be "None", "All", or any combination of "Indexes",

# "Includes", "FollowSymLinks", "ExecCGI", or "MultiViews".
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn’t give it to you.
#
Options Indexes FollowSymLinks MultiViews Includes

Listado 11.59 Directiva Options.

11.10.4 Order

Sintaxis: Order orden18

Defecto: Order Deny, Allow

Contexto: directorio, .htaccess



Sobreescribe: Limit

Estado: base

Módulo: mod_access.

Controla el estado de acceso por defecto en el que las directivas Allow, y Deny son evaluadas. El
valor orden puede ser uno de los siguientes:

Deny,Allow: La directiva Deny se evalúa antes que Allow. Por defecto el acceso estará permitido,
lo que implementa una política de máximo privilegio. El acceso está permitido a cualquier
cliente que no empareja con la directiva Deny o que sí lo hace con Allow.

Allow,Deny: La directiva Allow se evalúa antes que Deny. El acceso está prohibido por defecto
(política de mínimo privilegio). Cualquier cliente que no empareja con la directiva Allow o
empareja con Deny tendrá el acceso prohibido.

Mutual-failure: Sólo los host que aparecen en la lista de Allow y no aparecen en la lista de Deny
tienen acceso garantizado. Esta opción tiene el mismo comportamiento que Allow,Deny y
ha sido marcada como obsoleta (deprecated).

El funcionamiento de la directiva es claro, no deben confundirnos ejemplos como el siguiente:

18 El orden es una lista de palabras claves separadas por coma, y sólo por coma, si por error se introduce un espacio

en blanco se obtiene un error de sintaxis en el arranque.

11.11. CONFIGURACIÓN DE HOSTS VIRTUALES 205

Order Deny,Allow
Allow from ei.uvigo.es
Deny from montsfortis.ei.uvigo.es

Independientemente del orden de las directivas Allow y Deny en el fichero de configuración, la

directiva Order indica que se procesa antes Deny y luego Allow. De esta manera todo el dominio
ei.uvigo.es obtendría acceso, incluso el equipo montsfortis.ei.uvigo.es .

Un ejemplo sería:

# Controls who can get stuff from this server.

#
Order Allow,Deny
Allow from ei.uvigo.es
Deny from montsfortis.ei.uvigo.es

Listado 11.60 Directiva Order.

11.11 Configuración de hosts virtuales

BindAddress

Sintaxis: BindAddress *|dirección-ip|nombre-dominio

Defecto: BindAddress *

Contexto: server config

Estado: core

Un servidor Web Unix puede escuchar conexiones en cada dirección IP de la máquina, o sólo en
alguna dirección IP específica. Si se configura con el valor “*” el servidor escucha en todas las
IPs de la máquina, de otra forma escuchará en el lugar especificado (bien en la IP o servidor con
nombre de dominio completamente cualificado).

Apache provee también la directiva Listen para un mayor control de los puertos en los que se
escucha. Se recomienda el uso de Listen en vez de BindAddress.

BindAddress puede ser usada como un modo alternativo para soportar hosts virtuales con
múltiples servidores independientes.

Un ejemplo sería:
206 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

# BindAddress: You can support virtual hosts with this option.

# This directive is used to tell the server which IP address to
# listen to. It can either contain "*", an IP address, or a fully
# qualified Internet domain name.
# See also the <VirtualHost> and Listen directives.
#
BindAddress *

Listado 11.61 Directiva BindAddress.

11.11.1 NameVirtualHost

Sintaxis: NameVirtualHost dirección-IP[:puerto]



Contexto: server config



Estado: core


Compatibilidad: desde Apache 1.3.

Esta directiva es absolutamente necesaria para configurar hosts virtuales basados en nombre.
Indica la dirección IP sobre la que escuchan los servidores virtuales y opcionalmente puede indicar
también un número de puerto.

El valor puede ser tanto una dirección IP como una expresión con comodines. El carácter comodín
* como dirección IP en NameVirtualHost, será la IP utilizada por los hosts virtuales que no tengan
directiva(s) más especificas. Esto es útil para configurar servidores de los que no se conoce a priori
la dirección IP (por ejemplo porque tenga la dirección IP dinámica).

Un ejemplo:

NameVirtualHost 193.147.87.2

Listado 11.62 Directiva NameVirtualHost.

11.11.2 ServerAlias

Sintaxis: ServerAlias nobre-host [nombre-host] ...



Contexto: virtual host



Estado: core


Compatibilidad: desde Apache 1.1.

11.12. OTRAS DIRECTIVAS 207

Esta directiva establece nombres alternativos para un host. Es utilizada dentro de servidores
virtuales. Por ejemplo puede necesitar ServerAlias en una red local donde los usuarios están
acostumbrados a no utilizar el nombre de dominio completo.

Un ejemplo:

<VirtualHost>
ServerName www.ei.uvigo.es
ServerAlias www
DocumentRoot ...
...
</VirtualHost>

Listado 11.63 Directiva ServerAlias.

11.12 Otras directivas

Existen multitud de otras directivas, por ejemplo, comentar alguna que aparece de manera habitual
en la configuración por defecto de Apache:

11.12.1 BrowserMatch

Sintaxis: BrowserMatch regex envar[=valor] [envar[=valor]] ...



Defecto: none


Contexto: server config, virtual host, directory, .htaccess



Sobreescribe: FileInfo


Estado: base


Módulo: mod_setenvif.


Compatibilidad: desde Apache 1.2.

Define variables de entorno basadas en las cabeceras de petición HTTP (User-Agent). El primer
argumento regex es una expresión regular “case-sensitive”19 . al estilo de las que proporciona el
comando egrep (vea el apéndice C en la página 373). El resto de argumentos dan los nombres de
las variables que deben ser configuradas; el establecimiento de las variables puede hacerse de tres
formas:
19 Existe la directiva BrowserMatchNoCase que actúa igual que esta pero no es “case-sensitive”
208 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

nombre-variable: crea una variable con ese nombre y el valor “1” como contenido.

!nombre-variable: elimina una variable con ese nombre si ya existía.

nombre-variable=valor: establece un valor dado para la variable.

Las directivas BrowserMatch y BrowserMatchNoCase son casos particulares de SetEnvIf y

SetEnvIfNoCase.

Un ejemplo sería:

# Customize behaviour based on the browser

#
<IfModule mod_setenvif.c>
#
# The following directives modify normal HTTP response
# behavior. The first directive disables keepalive for
# Netscape 2.x and browsers that spoof it. There are
# known problems with these browser implementations.
# The second directive is for Microsoft Internet
# Explorer 4.0b2 which has a broken HTTP/1.1
# implementation and does not properly support keepalive
# when it is used on 301 or 302 (redirect) responses.
#
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive
downgrade-1.0 force-response-1.0
#
# The following directive disables HTTP/1.1 responses to
# browsers which are in violation of the HTTP/1.0 spec by
# not being able to grok a basic 1.1 response.
#
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
</IfModule>

Listado 11.64 Directiva BrowserMatch.

11.12.2 UserDir

Sintaxis: UserDir directorio-fichero [enabled|disabled]

11.12. OTRAS DIRECTIVAS 209

Defecto: UserDir public_html



Contexto: server config, virtual host



Estado: base


Módulo: mod_userdir.


Compatibilidad: La versión más básica UserDir public_html está disponible en todas las
versiones.
El uso de otros directorios y URLs desde la versión 1.1.
Las características extendidas enabled y disabled sólo desde Apache 1.3.

Establece el directorio real20 o URL para redirección a usar cuando se recibe una petición de un
documento de usuario. directorio-fichero puede tomar un valor entre los siguientes:

1. La palabra clave disabled, que deshabilita el uso de directorios de usuario. Esta palabra
clave también puede aparecer seguida por una lista separada por espacios en blanco de
nombres de usuario, para deshabilitar las peticiones sólo en los directorios de esos usuarios.

2. La palabra clave enabled, seguida por una lista separada con espacios en blanco de nombres
de usuario, habilita el uso de directorios a los usuarios especificados.

3. Nombre de un directorio o patrón, que será el comportamiento por defecto si no aparecen

las palabras enabled o disabled.

Como ejemplo, se supone que se hace una petición de un documento en un directorio de usuario:

http://www.ei.uvigo.es/~txapi/enlaces.htm

Con la siguiente configuración, se puede indicar que el directorio-fichero real que se corresponde
es /home/txapi/www/enlaces.htm:

UserDir /home/*/www/

O también hacer una redirección a otra URL, por ejemplo http://www.txapi.net/enlaces.

htm, con la siguiente configuración:

UserDir http://www.*.net/

En la configuración por defecto del servidor, se configura de la siguiente forma:

20 Para garantizar el acceso desde el Web al directorio del usuario toda la ruta debe tener permisos de lectura y

ejecución para el propietario del servidor.

210 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

</IfModule mod_user_dir.c>
UserDir public_html
</IfModule>

#
# Control access to UserDir directories. The following is an example
# for a site where these directories are restricted to read-only.
#
#<Directory /home/*/public_html>
# AllowOverride FileInfo AuthConfig Limit
# Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
# <Limit GET POST OPTIONS PROPFIND>
# Order allow,deny
# Allow from all
# </Limit>
# <LimitExcept GET POST OPTIONS PROPFIND>
# Order deny,allow
# Deny from all
# </LimitExcept>
#</Directory>

Listado 11.65 Directiva UserDir.

11.13 Consideraciones de seguridad

11.13.1 Ficheros srm.conf y access.conf

Apache por defecto busca los ficheros tradicionales srm.conf y access.conf cada vez que
arranca, aunque puede funcionar perfectamente sin ellos y ni siquiera da error si no los encuentra.
Esto produce un posible agujero de seguridad si alguien es capaz de modificar estos ficheros
introduciendo directivas peligrosas como Option Includes por ejemplo.

La solución consiste en configurar en el fichero principal http.conf para que no busque estos
ficheros:

AccessConfig /dev/null
ResourceConfig /dev/null
11.13. CONSIDERACIONES DE SEGURIDAD 211

11.13.2 Permisos en ficheros de Apache

Es conveniente revisar de vez en cuando los permisos, para no comprometer la seguridad. Existen
varias formas de ataque si se tienen los permisos mal establecidos. Por ejemplo, si un usuario
no-root puede modificar el ejecutable httpd, el root puede estar ejecutando código arbitrario sin
saberlo. Un error en los permisos permitiría también modificar los ficheros de log de manera que
fuesen enlaces a algún otro fichero del sistema; podrían estarse machacando ficheros vitales del
sistema sin darse cuenta.

Las comprobaciones que se deben realizar en una instalación típica (en /usr/local/apache por
ejemplo) son:

En primer lugar se comprueba que /, /usr y /usr/local son modificables sólo por el root.

Luego los permisos de los subdirectorios principales: bin, conf, logs, que deben
pertenecer al root o al propietario del servidor y no tener permiso de escritura por nadie
más.

# chown 0 . bin conf logs

# chgrp 0 . bin conf logs
# chmod 755 . bin conf logs

Como cualquier comando que ejecuta el root, se debe proteger de modificaciones por parte
de usuarios no-root. Para ello se verifican los permisos del ejecutable, dándole permiso de
ejecución a todo el mundo y de lectura sólo al propietario.

chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd

El directorio htdocs puede tener permisos de escritura para otros usuarios, y esto no causa
problema, mientras el root no ejecute nada (como por ejemplo un CGI) dentro de este
directorio.

11.13.3 Directiva UserDir

Hay que ser cuidadoso con esta directiva, para no permitir accesos a rutas no deseadas. En este
sentido es muy recomendable que se deshabilite al root como usuario válido.

UserDir disabled root

212 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

11.13.4 Accesos a páginas

Por defecto, se permite el acceso a cualquier parte del servidor. Un usuario malintencionado podría
intentar aprovechar estas características (combinada con la mala configuración de UserDir) para
navegar por todo el sistema de ficheros. Por ejemplo:

# cd /; ln -s / public_html
netscape http://localhost/~root/

Las directivas Allow, Deny y Order controlan el acceso desde los clientes a según que partes
del servidor Web. Con ellas se pueden definir bloques como el siguiente, que prohibe el acceso a
cualquier sitio del sistema de ficheros:

<Directory />
Order Deny,Allow
Deny from all
</Directory>

Lo anterior es muy restrictivo, ahora simplemente se deben añadir bloques <Directory> para
proporcionar acceso a las zonas que realmente deben estar disponibles. Por ejemplo:

<Directory /usr/local/apache/htdocs>
Order Deny,Allow
Allow from all
</Directory>

11.13.5 Sobreescritura de configuración

La sobreescritura de los valores globales de configuración por medio de los ficheros .htaccess
también está permitida por defecto. Un usuario malintencionado podría intentar aprovechar
esta característica para ejecutar programas en lugares no permitidos. Por ejemplo, añadiendo
lo siguiente en un fichero .htaccess:

Options +ExecCGI

Las directivas AllowOverride y Options controlan la sobreescritura. Puede ganarse un grado más
de seguridad si se combinan estas directivas con la restricción por defecto en el acceso a páginas
(vea sección anterior). Por ejemplo:

<Directory />
AllowOverride None
Options None
Order Deny,Allow
Deny from all
</Directory>
11.14. COMPROBACIONES DE LA CONFIGURACIÓN DEL SERVIDOR 213

11.13.6 Identidad del servidor. User y Group

Típicamente Apache es arrancado por el root, y luego pasa a la identidad definida en las directivas
User y Group para manejar las peticiones. Para mejorar la seguridad es importante que los valores
de estas directivas no sean root. Por defecto, se utiliza nobody, pero no es mala idea crear un
usuario y grupo nuevos exclusivamente para esto.
El uso de estas directivas en <VirtualHost> requiere de un wrapper suEXEC correctamente
configurado.

11.13.7 Problemas de Apache relacionados con DNS

Se recomienda configurar Apache de forma que no deba usar DNS durante el análisis de los
ficheros de configuración. Si Apache confía en resoluciones DNS, pueden estarse creando
problemas:

de disponibilidad: Apache puede fallar en el arranque si no resuelve el DNS.



de seguridad: Cuando las respuestas de peticiones a un servidor las realiza otro como
consecuencia de un cambio en el DNS.

11.13.8 Option Indexes

En general, no es una buena política activar por defecto la generación de listados automáticos por
directorio, esto puede dar lugar a que cierta información que en principio no se quiere mostrar, sea
accesible. No es tan raro tener usuarios que creen que lo que no se enlaza desde una página no
es accesible. De todas formas la mejor manera de evitar estos accesos no deseados es quitar los
archivos del directorio con acceso desde el Web.

11.14 Comprobaciones de la configuración del servidor

Varias son las herramientas que permiten comprobar la configuración del servidor. Algunas de
las mejores son accesibles desde la línea de comandos como parámetros de los ejecutables httpd
(vea la sección 10.6.5 en la página 145) y apachectl (vea la sección 10.6.6 en la página 147).
También existen un par de módulos de Apache relacionados (mod_status y mod_info), que se
comentan más en profundidad en los siguientes puntos.

11.14.1 mod_status

Cuando mod_status se compila con Apache, se instala un nuevo manejador (handler) llamado
server-status. Este manejador debe ser configurado en Apache dentro de una sección
<Location> con las siguientes directivas:
214 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR

ExtendedStatus On
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>

Figura 11.1: Información proporcionada por Apache server-status.

Al realizar una conexión desde cualquier navegador a la URL http://localhost/

server-status (figura 11.1), el servidor devolverá una gran cantidad de información interesante:
versión, fecha de construcción, fecha de arranque, número de accesos, tráfico gestionado,
información sobre los procesos servidores, etc.

11.14.2 mod_info

mod_info funciona de manera similar a mod_status, cuando se compila con Apache se instala un
nuevo manejador llamado server-info. Este manejador debidamente configurado permite que el
servidor devuelva gran cantidad de información sobre su configuración. Las directivas que deben
aparecer en httpd.conf para habilitar esta característica son:

<Location /server-info>
SetHandler server-info
11.14. COMPROBACIONES DE LA CONFIGURACIÓN DEL SERVIDOR 215

Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>

Figura 11.2: Información proporcionada por Apache server-info.

La información proporcionada por mod_info es leída directamente de los ficheros de

configuración de Apache. Al realizar una conexión desde cualquier navegador a la URL
http://localhost/server-info (figura 11.2), el servidor devolverá información interesante:
configuración por defecto de Apache, módulos habilitados, información de cada módulo, etc.
216 CAPÍTULO 11. CONFIGURACIÓN BÁSICA DEL SERVIDOR
Capítulo 12

Servidores virtuales

Contenidos de este capítulo

12.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

12.2 Host virtuales basados en IP . . . . . . . . . . . . . . . . . . . . . . . . . . 217
12.2.1 Varios demonios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
12.2.2 Un solo demonio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
12.3 Host virtuales basados en nombre . . . . . . . . . . . . . . . . . . . . . . . 219
12.3.1 Problemas con navegadores antiguos . . . . . . . . . . . . . . . . . . . 220
12.4 Host virtuales dinámicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
12.5 Consideraciones finales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
12.5.1 El servidor virtual por defecto . . . . . . . . . . . . . . . . . . . . . . 222
12.5.2 Depurando la configuración . . . . . . . . . . . . . . . . . . . . . . . 223

12.1 Introducción

El término servidor virtual, o en inglés virtual host (vea la sección 2.3.3 en la página 31) hace
referencia al hecho de simular más de un equipo servidor cuando en realidad se dispone de una
sola máquina. Apache fue uno de los primeros servidores Web capaces de soportar hosts virtuales.
En este capítulo se explica como configurar adecuadamente un Apache con servidores virtuales
utilizando las distintas técnicas posibles (según IP o según nombre). Además se comentan algunas
características avanzadas, como el alojamiento dinámico de servidores virtuales.

12.2 Host virtuales basados en IP

La característica fundamental de los servidores virtuales basados en IP (IP-based virtual hosts) es

que el equipo que los aloja debe tener una dirección IP distinta para cada uno de ellos. Esto puede

217
218 CAPÍTULO 12. SERVIDORES VIRTUALES

lograrse en una sola máquina que tiene varias conexiones físicas de red o mediante el uso de alias
o interfaces virtuales.

Con Apache este tipo de funcionamiento puede configurarse de dos maneras:

1. Ejecutando varios demonios HTTP, uno por cada servidor.

2. Ejecutando un solo demonio que soporte todos los hosts virtuales.

12.2.1 Varios demonios

Esta es la forma más antigua de ejecutar varios servidores en un mismo equipo. Es una alternativa
que requiere bastantes recursos adicionales (tiempo de CPU, memoria, varias IPs, etc.), por tanto
tendrían que darse unas condiciones muy particulares para que esta sea la opción elegida en un
servidor actual.

La configuración de varios demonios utilizará tantos ficheros httpd.conf distintos como

instancias de servidores necesarias. En cada uno de ellos aparecerá una directiva Listen (vea
la sección 11.5.4 en la página 170) con el valor de la IP asignada.

También se debe asegurar que los recursos que el servidor utilizará para escritura (como por
ejemplo los ficheros de log) son distintos para cada instancia. Si no se hace esto existirán varios
servidores compitiendo por los mismos recursos, lo que puede dar problemas. En cambio, los
recursos de lectura (como por ejemplo el directorio /icons) pueden compartirse.

Una vez se tienen preparados todos los archivos de configuración se utiliza el ejecutable httpd
para arrancar las distintas instancias. Con la opción -f se le indicará cual es el archivo de
configuración que Apache debe leer para cada servidor virtual. Ejemplo:

# http -f /usr/local/webs/servidor1/conf/httpd.conf
# http -f /usr/local/webs/servidor2/conf/httpd.conf
...

12.2.2 Un solo demonio

Caso de elegir esta opción, una sola instancia del servidor atenderá todas las peticiones, tanto las
del servidor principal como las de los hosts virtuales. Aparecerá una directiva Listen para cada
IP a la que un servidor virtual deba responder. Se utiliza además la directiva <VirtualHost> (vea
la sección 11.7.7 en la página 187) para establecer una sección propia para cada servidor virtual.
Dentro de estas secciones se pueden definir valores para distintas directivas1 :

ServerName (vea la sección 11.5.1 en la página 156)

1 Válidas en el contexto virtual host (vea la sección 11.4.1 en la página 152).
12.3. HOST VIRTUALES BASADOS EN NOMBRE 219

ServerAdmin (vea la sección 11.5.1 en la página 155)



DocumentRoot (vea la sección 11.5.2 en la página 160)



...

Un ejemplo de configuración sería:

<VirtualHost 193.147.87.2>
ServerAdmin webmaster@ei.universidad.es
DocumentRoot /etc/local/virtuales/virtual1
ServerName www.ei.universidad.es
ErrorLog /etc/local/virtuales/virtual1/log/error_log
TransferLog /etc/local/virtuales/virtual1/log/access_log
</VirtualHost>

<VirtualHost 193.147.87.3>
ServerAdmin eseiadmin@ei.universidad.es
DocumentRoot /etc/local/virtuales/virtual2
ServerName esei.ei.universidad.es
ErrorLog /etc/local/virtuales/virtual2/log/error_log
TransferLog /etc/local/virtuales/virtual2/log/access_log
</VirtualHost>

12.3 Host virtuales basados en nombre

Configurar hosts virtuales basados en nombre (Name-based virtual hosts), es muy parecido a
configurar host virtuales basados en IP. La principal diferencia de la directiva NameVirtualHost
(vea la sección 11.11.1 en la página 206) que especifica la dirección IP que deberá usarse como
destino de los hosts virtuales basados en nombre. Un ejemplo simple es:

NameVirtualHost 193.147.87.211

<VirtualHost 193.147.87.211>
ServerName prueba.ei.universidad.es
DocumentRoot /etc/local/virtuales/virtual1
</VirtualHost>

<VirtualHost 193.147.87.211>
ServerName prueba1.ei.universidad.es
DocumentRoot /etc/local/virtuales/virtual2
</VirtualHost>
220 CAPÍTULO 12. SERVIDORES VIRTUALES

El ejemplo funciona adecuadamente siempre que los nombres prueba.ei.universidad.es

y prueba1.ei.universidad.es estén dados de alta en el DNS y apunten a la dirección
193.147.87.211.

Cuando se especifica una dirección IP en una directiva NameVirtualHost sólo se atenderán las
peticiones si existe una sección <VirtualHost> configurada para responder a esa IP. El servidor
principal nunca podrá escuchar esa dirección IP. De hecho, cuando se comienzan a utilizar
servidores virtuales debería deshabilitarse el servidor principal como servidor independiente
y utilizarlo simplemente como un lugar para configurar directivas globales a todos los hosts
virtuales. En otras palabras, si se empiezan a usar hosts virtuales y se pretende que el servidor
principal siga funcionando deberá ser configurado como un host virtual más.

Algunos servidores pueden tener más de un nombre. Apache soporta esta característica mediante
la directiva ServerAlias (vea la sección 11.11.2 en la página 206). Un posible ejemplo es cuando
un servidor tiene uno local (web) y otro público (www.ei.universidad.es):

<VirtualHost 193.147.87.211>
...
ServerAlias web www.ei.universidad.es
...
</VirtualHost>

12.3.1 Problemas con navegadores antiguos

Para poder utilizar los servidores virtuales por nombre, los clientes deben hacer peticiones que
incluyan un campo de encabezado Host. El encabezado Host se define en la especificación
de HTTP/1.1 y aunque algunos navegadores que soportan HTTP/1.0 han sido mejorados con
la capacidad de manejar este encabezado, los más antiguos directamente no lo soportan. Las
peticiones desde estos navegadores antiguos no son bien entendidas por el servidor, que no será
capaz de determinar a que host virtual se pretende acceder y responderá siempre con el servidor
por defecto.

En muchos casos no se desea perder los accesos de estos posibles usuarios. Existe una solución
basada en la directiva ServerPath que designa una manera alternativa de acceder a los datos que
forman parte de servidores virtuales. Mediante ServerPath se define una localización en el host
por defecto que se refiere al servidor virtual. Por ejemplo:

# Se supone que el host por defecto se llama

# www.ejemplo.es
NameVirtualHost 193.147.87.211
<VirtualHost 193.147.87.211>
ServerName virtual1.ejemplo.es
ServerPath /virtual1
12.4. HOST VIRTUALES DINÁMICOS 221

DocumentRoot /usr/local/proyecto/htdocs/virtuales/virtual1
</VirtualHost>

Con estas líneas se consigue que las peticiones de la localización /virtual1 del servidor por
defecto sean servidas desde el raíz del host virtual virtual1.ejemplo.es. De esta forma las
páginas podrán ser accesibles mediante las siguientes URLs:

# Acceso para clientes que no soportan hosts virtuales por nombre

http://www.ejemplo.es/virtual1
# Acceso para clientes que soportan hosts virtuales por nombre
http://virtual1.ejemplo.es

Para asegurar la compatibilidad total se proporcionarán enlaces desde el servidor por defecto a las
páginas alternativas de cada host alojado. Además las páginas no podrán contener referencias al
nombre del servidor virtual.

Como se ve, el uso de esta alternativa exige un poco de disciplina, pero con ello se garantiza el
acceso a los datos independientemente de la versión de navegador que utilicen los usuarios.

12.4 Host virtuales dinámicos

Las dos técnicas anteriores, hosts virtuales basados en nombre y hosts virtuales basados en IP,
son suficientes para la mayoría de los servidores, pero no son muy cómodas cuando se trata de
alojar a cientos o miles de servidores virtuales (caso típico de un ISP). Existe una técnica llamada
configuración masiva y dinámica de hosts virtuales (Dynamically configured mass virtual hosting)
que soluciona este problema. Se implementa en el módulo mod_vhost_aliases (distribuido de
manera estándar con Apache). Este se encarga de determinar las rutas (tradicionalmente indicadas
por DocumentRoot y ScriptAlias) basándose en la URL solicitada. Cuatro son las directivas que
permiten hacerlo:

Dos para hosts virtuales basados en nombre:

VirtualDocumentRoot: indica la manera de construir dinámicamente el DocumentRoot

(ruta de los documentos) a partir del URL.
VirtualScriptAlias: especifica como se construye de manera dinámica el ScriptAlias (ruta
de los scripts CGI) a partir del URL.

Y dos para hosts virtuales basados en IP:

VirtualDocumentRootIP: funciona igual que VirtualDocumentRoot, pero en este caso

obtiene la ruta de los documentos alojados en hosts virtuales basados en IP.
222 CAPÍTULO 12. SERVIDORES VIRTUALES

VirtualScriptAliasIP: funciona igual que VirtualScriptAlias pero en el caso de host

virtuales basados en IP.

Ya no será necesario incluir líneas en httpd.conf para cada nuevo host virtual. En realidad se
tendrán una serie de patrones2 que emparejarán con las URLs generando rutas reales. Simplemente
se deberá asegurar que las rutas generadas existen.
Por ejemplo, la configuración de hosts virtuales puede incluir el patrón %1 que permite asignar
rutas reales en función del nombre de la máquina3 :

...
UseCanonicalName off
VirtualDocumentRoot /usr/local/proyecto/htdocs/%1
...

Ante una solicitud de una URL del estilo:

http://ccia.ei.universidad.es/index.html

Apache consulta sus ficheros de configuración, empareja y determina que la ruta real donde está
alojado el documento seleccionado es:

/usr/local/proyecto/htdocs/ccia/index.html

12.5 Consideraciones finales

12.5.1 El servidor virtual por defecto

Cuando se usan servidores virtuales se está expuesto a que un cliente realice una petición de
acceso a un servidor virtual que no existe, por ejemplo si se accede a la máquina con un nombre
alternativo del DNS. En estos casos Apache responde según las directivas que tenga configuradas
en el servidor principal. Una manera mucho más legible de configurar estas respuestas es usar
un servidor virtual por defecto. El servidor virtual por defecto se establece dentro de una sección
<VirtualHost> propia, con la palabra clave _default_ (para el nombre del servidor) y el comodín
* (para el número de puerto). Todo lo no definido explícitamente en otros servidores virtuales se
atenderá desde aquí. Un ejemplo de configuración del servidor virtual por defecto es el siguiente:

<VirtualHost _default_:*>
DocumentRoot /usr/local/proyecto/htdocs/virtuales/pordefecto
...
</VirtualHost>
2 Para un listado completo de los patrones permitidos puede consultarse la información relativa a mod_vhost_alias
en la documentación que acompaña a Apache.
3 El patrón %1 empareja con el nombre de la máquina, en este ejemplo %1 = ccia.
12.5. CONSIDERACIONES FINALES 223

12.5.2 Depurando la configuración

Para depurar la configuración de los hosts virtuales puede ser útil la opción -S del demonio httpd.
Desde la línea de órdenes puede escribirse:

# httpd -S

Esto realiza un volcado de la configuración de los servidores virtuales tal y como Apache la ha
analizado. Revisar en la salida producida puede ayudar a descubrir errores.
224 CAPÍTULO 12. SERVIDORES VIRTUALES
Capítulo 13

Configurando SSI y CGI

Contenidos de este capítulo

13.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

13.2 SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

13.2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

13.2.2 Instalar el soporte SSI . . . . . . . . . . . . . . . . . . . . . . . . . . 226

13.2.3 Configurar ejecución SSI . . . . . . . . . . . . . . . . . . . . . . . . . 227

13.3 CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

13.3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

13.3.2 Usando suEXEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

13.3.3 Instalar el soporte a CGI . . . . . . . . . . . . . . . . . . . . . . . . . 230

13.3.4 Posibilidades de configuración de scripts CGI . . . . . . . . . . . . . . 232

13.3.5 Errores habituales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

13.3.6 Consideraciones de seguridad . . . . . . . . . . . . . . . . . . . . . . 236

13.1 Introducción

SSI y CGI son las dos tecnologías de generación de contenido dinámico más antiguas, ambas
se incluyen en las distribuciones de Apache. SSI (vea la sección 4.2 en la página 53) es un
sistema de directivas embebidas en el código HTML, mientras CGI (vea la sección 3.2 en la
página 36) permite la ejecución de programas externos. En las siguientes secciones se discute
como se instalan y configuran adecuadamente.

225
226 CAPÍTULO 13. CONFIGURANDO SSI Y CGI

13.2 SSI

13.2.1 Introducción

SSI se compila por defecto y por tanto está disponible en todos los servidores salvo que
explícitamente se indique lo contrario. El módulo mod_include proporciona la implementación
XSSI (vea la sección 4.2.2 en la página 54) que se puede decir que es la implementación estándar
de facto.

13.2.2 Instalar el soporte SSI

Con una instalación básica de Apache (vea el capítulo 10 en la página 133) se incluye el módulo de
XSSI. Un poco más complejo es instalar las extensiones al XSSI de Apache que provee Hotwired
XSSI (vea la sección 4.2.3 en la página 58). Para ello se tiene que partir del código fuente y seguir
los siguientes pasos:

1. Obtener el fichero que implementa las modificaciones desde el sitio Web:

http://hotwired.lycos.com/webmonkey/99/10/stuff0a/mod_include.tar.gz.

2. Sustituir el fichero estándar del módulo XSSI en el árbol de instalación de Apache

/src/modules/standard/mod_include.c.

3. Seguir el proceso normal de instalación desde código fuente (vea la sección 10.4 en la página
136).

Una vez acabada la instalación puede verificarse que efectivamente se incluye el módulo que
soporta SSI:

1. Si Apache fue compilado como un único ejecutable sin módulos, comprobar mediante la
siguiente orden que en efecto se incluyó el módulo mod_include:

APACHE_HOME/bin/httpd -l

2. Si apache se compiló con la posibilidad de utilizar módulos cargables dinámicamente

(DSO), en los ficheros de configuración aparecerán las siguientes líneas1 :

LoadModule include_module libexec/mod_include.so

AddModule mod_include.c

La directiva LoadModule (vea la sección 11.5.2 en la página 161) enlaza el objeto (fichero
o biblioteca) del módulo y lo añade a la estructura de módulos activos. La directiva
AddModule (vea la sección 11.5.2 en la página 159) se utiliza para habilitarlo.
1Y existirá el fichero dentro de /libexec.
13.2. SSI 227

13.2.3 Configurar ejecución SSI

Una vez instalado, SSI debe ser correctamente configurado. Lo primero es indicar que se desea
habilitar el procesamiento de directivas SSI, para ello se añade en algún sitio de los ficheros de
configuración:

Option +Include

Esta forma es válida si ya existe una lista de opciones por defecto (el modificador + significa añadir
a la lista de opciones actual), si no es así, puede usarse simplemente:

Option Include

También se puede usar una versión un poco más segura que impide que se puedan ejecutar scripts
desde directivas SSI2 :

Option +IncludesNOEXEC

Los documentos que incluyen etiquetas SSI deben ser analizados e interpretados por el servidor
antes de ser servidos (server parsed). Por cuestiones de eficiencia no todos los documentos son
server parsed. Aunque parezca más cómodo, se debe tener en cuenta que el servidor deberá
analizar cada fichero en busca de directivas antes de enviarlo al cliente, con la consecuente
sobrecarga. Hay dos formas de indicarle a Apache que archivos debe interpretar y cuales no:

1. La primera solución se basa en utilizar las extensiones de los archivos y asociarlas con un
manejador especial. Para ello:

Usando la directiva AddType (vea la sección 11.8.4 en la página 191) se añade la

extensión .shtml que se quiere utilizar para los documentos SSI y se indica su tipo
MIME:

AddType text/html .shtml

Con la directiva AddHandler se establece un manejador (handler) especial que indica

que todos los documentos de extensión .shtml van a ser server_parsed.

AddHandler server-parsed .shtml

La directiva AddHandler hace corresponder una extensión de fichero con un

manejador. De esta manera el manejador se encargará de procesar las peticiones de
ficheros con la extensión dada.

2 Con la misma consideración respecto a la lista de opciones por defecto que en el caso anterior.
228 CAPÍTULO 13. CONFIGURANDO SSI Y CGI

2. La segunda solución es utilizar los propios permisos de ejecución de los archivos. Mediante
la directiva XBitHack se consigue que el servidor analice todos los archivos con permisos
de ejecución buscando directivas SSI:

XBitHack on

Con esta opción Apache no envía la cabecera HTTP que contiene la fecha de última
modificación y los clientes no pueden efectuar operaciones de caché. Por corregirlo puede
utilizarse:

XBitHack full

Con XBitHack si se quieren añadir directivas a una página concreta no hay que cambiarle
la extensión, sino únicamente los permisos, por ejemplo:3 .

chmod +x pagina.html

13.3 CGI

13.3.1 Introducción

El CGI define una interface para que el servidor Web pueda interactuar con programas externos
que generan contenido (vea la sección 3.2 en la página 36).

Una de las principales preocupaciones de un administrador de un sitio que permite ejecución

de programas externos mediante CGI es la seguridad. Apache proporciona una utilidad llamada
suEXEC que implementa una envoltura CGI (wrapper CGI) para la ejecución “segura” setuid.
Esta característica convenientemente utilizada puede mejorar la seguridad del servidor, pero mal
configurada puede dar lugar a nuevos agujeros de seguridad (por esto no se instala por defecto con
Apache).

13.3.2 Usando suEXEC

Normalmente cuando un script se ejecuta lo hace con los permisos del usuario especificados
mediante las directivas User (vea la sección 11.5.3 en la página 168) y Group (vea la sección
11.5.3 en la página 164). Con suEXEC activado el funcionamiento cambia, el wrapper es llamado
cuando una petición HTTP solicita un programa CGI, Apache le proporciona el nombre del
programa y el identificador de usuario y grupo con el que debe ejecutarse.

Las mayores utilidades de suEXEC son fundamentalmente dos:

3 En Windows no existe un bit de permiso de ejecución, lo que impide que funcione esta opción
13.3. CGI 229

Permiten a los usuarios crear scripts en sus directorios personales y ejecutarlos bajo sus
propios permisos, en vez de ser lanzados con los permisos especificados en el servidor por
las directivas User y Group.
Por ejemplo, el usuario txapi puede tener un script llamado enlaces.pl en su directorio
personal4 . El script se invocaría como http://www.ejemplo.com/~txapi/cgi-bin/
enlaces.pl y sería ejecutado con los permisos del usuario, permitiendo el acceso a ficheros
de datos propiedad del mismo usuario.

Permiten mayor seguridad en los servidores virtuales redefiniendo las directivas User y
Group con valores diferentes a los del servidor principal. Un ejemplo de configuración:

<VirtualHost 10.0.0.1>
ServerName virtual.ejemplo.com
ServerAdmin adminvirtual1@ejemplo.com
DocumentRoot /usr/local/bin/proyecto/htdocs/virtual1
User adminvirtual1
Group adminvirtual1
</VirtualHost>

Todas las peticiones de recursos CGI serán ejecutados como el usuario y grupo definido en
el servidor virtual. De esta manera un administrador de un host virtual puede escribir sus
propios CGIs sin comprometer la seguridad de todo el servidor Web.

Modelo de seguridad de suEXEC

El wrapper emplea un proceso complejo para determinar si se ejecuta un script o no:

1. ¿Se llama al wrapper con el número de argumentos adecuado?

2. ¿El usuario que ejecuta el wrapper es un usuario válido del sistema?

3. ¿Está el usuario autorizado a ejecutar el wrapper? Sólo el dueño de Apache debería poder.

4. ¿Hay referencias jerárquicas inseguras en el programa a ejecutar? Las únicas referencias

permitidas estarán dentro del espacio Web.

5. ¿Es válido el identificador de usuario objetivo?

6. ¿Es válido el grupo objetivo?

7. ¿El objetivo NO es el root? Actualmente suEXEC no permite la ejecución de CGI como

root.
4 Puede modificarse el valor de este directorio durante la instalación de suEXEC, con el modificador –suexec-userdir.
230 CAPÍTULO 13. CONFIGURANDO SSI Y CGI

8. ¿El número de identificador del usuario objetivo está sobre el número mínimo para
identificadores? Este número se configura en la instalación y permite evitar que la cuenta
objetivo sea de sistema.

9. ¿Puede el wrapper convertirse en el objetivo (id. y grupo)? Aquí el wrapper realiza las
llamadas a las funciones del sistema setuid y setgid.

10. ¿Existe el directorio donde reside el programa? Si no existe el directorio, mal puede haber
ficheros.

11. ¿Está el directorio dentro del espacio Web de Apache?

12. ¿El directorio NO tiene permisos de escritura para otros? Sólo el poseedor del directorio
debe poder crear contenido.

13. ¿Existe el programa objetivo? Si no existe no puede ser ejecutado.

14. ¿El programa NO tiene permisos de escritura para otros? Sólo el poseedor del programa
debe poder crear contenido.

15. ¿El programa NO es setuid, setgid? No interesa comenzar la ejecución de un programa que
mediante setuid y/o setgid pueda alterar de nuevo los permisos de usuario.

16. ¿Es el usuario/grupo del objetivo el mismo que el usuario/grupo del programa?

17. ¿Puede limpiarse el entorno del proceso para asegurar una ejecución segura? Antes de la
ejecución se establece un entorno seguro (definido durante la instalación).

18. ¿Puede convertirse el programa objetivo y ejecutar?

13.3.3 Instalar el soporte a CGI

El soporte CGI básico está implementado en el módulo mod_cgi. Además para tareas de
configuración pueden ser necesarios otros módulos mod_mime, mod_alias, mod_actions. Todos
ellos se incluyen por defecto en las instalaciones estándar. Lo que no se incluye es el soporte
a suEXEC, si se necesita de su instalación se deben instalar Apache con algunos parámetros
especiales:

Preparar la instalación de suEXEC usando APACI

suEXEC es fácilmente configurable utilizando APACI, lo único que hay que hacer es añadir
algunos parámetros a la instalación básica desde código fuente (vea la sección 10.4 en la página
136).
El parámetro más importante y el único absolutamente necesario es --enable-suexec(habilita la
instalación de suEXEC), aunque también existen otros que tendrán valores asignados por defecto.
Un script típico de configuración de la instalación podría ser el siguiente:
13.3. CGI 231

./configure --prefix=/usr/local/proyecto/apache1.3.20 \
--enable-module=most \
--enable-shared=max \
--htdocsdir=/usr/local/proyecto/htdocs/ \
--cgidir=/usr/local/proyecto/cgi-bin/ \
--sysconfdir=/usr/local/proyecto/conf/ \
--logfiledir=/usr/local/proyecto/logs/ \
--enable-suexec \
--suexec-caller=apache \
--suexec-logfile=/usr/local/proyecto/logs/suexec_log

Los parámetros relacionados con suEXEC son los tres últimos. Para conocer cuáles son los
posibles parámetros y cual es su función puede observarse la salida del script ./configure -h:

---- Omitimos más datos de salida ----

--enable-suexec enable the suEXEC feature

--suexec-caller=NAME set the suEXEC username of the
allowed caller [www]
--suexec-docroot=DIR set the suEXEC root directory
[PREFIX/share/htdocs]
--suexec-logfile=FILE set the suEXEC logfile
[PREFIX/var/log/suexec_log]
--suexec-userdir=DIR set the suEXEC user subdirectory
[public_html]
--suexec-uidmin=UID set the suEXEC minimal allowed
UID [100]
--suexec-gidmin=GID set the suEXEC minimal allowed
GID [100]
--suexec-safepath=PATH set the suEXEC safe PATH
[/usr/local/bin:/usr/bin:/bin]
--suexec-umask=UMASK set the umask for the suEXEC’d
script [server’s umask]

---- Omitimos más datos de salida ----

Una vez completada la instalación de Apache (vea la sección 10.4.2 en la página 139) puede
verificarse que suEXEC ha quedado correctamente instalado, utilizando el programa httpd:

# ./httpd -l
Compiled-in modules:
http_core.c
232 CAPÍTULO 13. CONFIGURANDO SSI Y CGI

mod_so.c
suexec: enabled;
valid wrapper /usr/local/proyecto/apache1.3.20/bin/suexec

13.3.4 Posibilidades de configuración de scripts CGI

Para que un script CGI funcione no llega con hacer un programa que genere contenido HTML,
Apache debe conocer que los ficheros deben ser ejecutados y no simplemente servidos como
cualquier fichero HTML. Existen varias posibilidades para indicar esto:

ScriptAlias

Alias y SetHandler

AddHandler y Options ExecCGI

mod_actions

ScriptAlias

Esta directiva (vea la sección 11.7.6 en la página 186) le dice a Apache que un directorio particular
y todos sus subdirectorios, van a contener scripts CGI. Si se solicita un fichero dentro de uno de
estos directorios el servidor Web intentará ejecutarlo y no simplemente servirlo:

ScriptAlias /cgi-bin/ /home/httpd/cgi-bin/

Alias y SetHandler

También se tiene otra opción para hacer que todo un directorio pueda ejecutar CGI. Se basa en
usar las directivas Alias (vea la sección 11.7 en la página 181) y SetHandler:

Alias /cgi-bin/ /usr/local/apache/cgi-bin/

<Directory /usr/local/apache/cgi-bin/>
SetHandler cgi-script
</Directory>

Primero debe usarse Alias para realizar el alias del directorio. Luego con SetHandler (parte de
mod_mime) se fuerza a que los ficheros del directorio sean pasados por el manejador indicado.
13.3. CGI 233

Directivas AddHandler, Options ExecCGI

Otra forma de hacer que los scripts funcionen es usar la directiva AddHandler (parte del módulo
mod_mime). Con esta directiva se indica que los archivos de ciertas extensiones van a ser
ejecutables CGI, independientemente de su localización. Esto puede ser apropiado si se quiere
que cada usuario pueda usar scripts situados en su propios directorios y no en una localización
general como /cgi-bin/. La sintaxis es:

AddHandler cgi-script .pl .cgi

Esto hace que los archivos de extensiones .pl y .cgi sean considerados scripts CGI, pero no
habilita la ejecución de los mismos. Para permitir esta ejecución se debe usar la directiva Options
+ExecCGI (vea la sección 11.10.3 en la página 202) en el directorio o localización deseado.

<Directory /usr/local/apache/htdocs/algundirectorio>
Options +ExecCGI
</Directory>

mod_actions

Es un módulo que proporciona la ejecución de scripts CGI basándose en el tipo de medio o método
de petición:

El tipo de medio puede ser un manejador (handler) o un tipo MIME. La ejecución del script
se controla con la directiva Action. Como ejemplo si se quiere que todas las peticiones
de ficheros de extensión .acc sean procesadas por un script de control, se incluirán las
siguientes líneas en la configuración:

AddHandler accion .acc

Action accion /cgi-bin/control.pl

El método de petición puede ser cualquiera de los que especifica el protocolo HTTP (GET,
POST, etc.). La ejecución del script se controla con la directiva Script. Un ejemplo sería
tener un script CGI capaz de monitorizar todas las peticiones (potencialmente peligrosas)
de tipo PUT.

Script PUT /cgi-bin/put.cgi

234 CAPÍTULO 13. CONFIGURANDO SSI Y CGI

Figura 13.1: Error típico provocado por un problema en un script CGI.

13.3.5 Errores habituales

Una vez se ha habilitado el soporte CGI ya se pueden publicar los scripts y estos deberían
funcionar. Pero no siempre es así y resulta bastante frustrante no saber que hacer ante el típico
mensaje de error (figura 13.1).
Para evitar enfados innecesarios siempre que un script no funcione pueden comprobarse varias
cosas:

Fichero de errores del servidor: generalmente error_log, en el se buscará algún mensaje

un poco más explicativo.


Sintaxis: como en cualquier otro programa, se debe conocer la sintaxis del lenguaje que se
está manejando y usarla adecuadamente. Un error de sintaxis hace que el script no funcione.


Encabezados no válidos: antes de cualquier salida, el script debe devolver un encabezado

HTTP válido. El final de este se marca siempre con dos líneas en blanco. Por ejemplo en
Perl sería algo así:

#!/usr/bin/perl
print "Content-type: text/html\n\n";

---- El resto del CGI aquí ----

Problemas con suEXEC: un error muy habitual con suEXEC, se produce cuando se quiere
habilitar la ejecución de CGIs desde directorios de usuario. Un mensaje en el fichero de
13.3. CGI 235

errores del servidor del estilo premature end of script headers indica de manera casi
segura que suEXEC está mal configurado. Se puede encontrar más información en el archivo
de log de suEXEC (generalmente suEXEC_log).


Permisos: si el archivo está en la ubicación correcta pero la ejecución no funciona

presentando un error como el de la figura (figura 13.2), el problema es de permisos. Se
debe tener en cuenta que el usuario propietario del script y el que lo ejecuta5 no suelen ser
el mismo. La más simple de solucionar el problema es añadir permiso de ejecución para
todos.

# chmod a+x nombredelcgi

Pero no sólo el script CGI debe tener permisos adecuados, sino también todos los archivos
que se trate de leer o escribir desde el mismo. Si esto no se verifica el script “romperá”
cuando se produzca un intento de acceso al archivo sin permisos.

Figura 13.2: Error típico provocado por un problema de permisos en un script CGI.

Como encontrar los errores de un script CGI

La forma típica de obtener información sobre los errores es buscar en el log de errores del servidor
(error_log). Pero existe otra forma, que consigue una información más detallada. Se basa en
configurar el servidor añadiendo las directivas de “debug”6 que se incluyen en el mod_cgi.
5 El propietario que ejecuta se especifica en la configuración con las directivas User y Group
6 Por eficiencia, estas características nunca deberían estar presentes en un servidor en producción.
236 CAPÍTULO 13. CONFIGURANDO SSI Y CGI

ScriptLog: indica en que fichero se almacenarán los logs, su presencia activa este método
de búsqueda de errores en CGIs. Por ejemplo:

ScriptLog /usr/local/proyecto/cgi-bin/cgi.log

ScriptLogLength: indica la longitud máxima que puede alcanzar el fichero de log (por
defecto 1 MB). Una vez alcanzada esta longitud el proceso de log es desactivado.


ScriptLogBuffer: indica el límite para las entradas en el log ( por defecto 1K ).

Con estas directivas activadas el resultado obtenido tras un error es bastante descriptivo. Por
ejemplo, este es el error que se obtiene tras la llamada a un script que no tiene bien los permisos:

%% [Fri Jun 29 19:33:12 2001] GET /cgi-bin/ HTTP/1.0

%% 403 /usr/local/proyecto/cgi-bin
%error
attempt to invoke directory as script
%% [Fri Jun 29 19:33:18 2001] GET /cgi-bin/p1.pl HTTP/1.0
%% 403 /usr/local/proyecto/cgi-bin/p1.pl
%error
file permissions deny server execution

13.3.6 Consideraciones de seguridad

Usando CGI el mayor problema es que la flexibilidad que se puede lograr con la directiva Options
+ExecCGI, puede convertirse en peligroso (vea la sección 11.13.5 en la página 212). Ciertos
usuarios en los que no se confía completamente pueden aprovecharse de esto y ejecutar CGIs
arbitrarios o realizar otras acciones malvadas.

La solución más segura consiste en mantener los scripts en un sólo directorio controlado por el
administrador (ScriptAlias), o deshabilitar selectivamente la ejecución CGI para los directorios
de los usuarios en los que no se confía (Options -ExecCGI).
Capítulo 14

Servlets y Jsp con Tomcat. Integración

con Apache

Contenidos de este capítulo

14.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

14.2 Pasos previos: instalar soporte Java . . . . . . . . . . . . . . . . . . . . . . 238
14.2.1 Instalar JSDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
14.2.2 Probar el JSDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
14.3 Tomcat como contenedor Servlet . . . . . . . . . . . . . . . . . . . . . . . . 240
14.3.1 Instalar Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
14.3.2 Ficheros de configuración . . . . . . . . . . . . . . . . . . . . . . . . 241
14.3.3 Probar Tomcat como contenedor Servlet independiente . . . . . . . . . 241
14.3.4 Iniciar con el arranque del sistema . . . . . . . . . . . . . . . . . . . . 242
14.4 Integrando Apache y Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . 242
14.4.1 Obtener adaptador para Apache . . . . . . . . . . . . . . . . . . . . . 243
14.4.2 Habilitar auto-configuración de Tomcat para Apache . . . . . . . . . . 244
14.4.3 Probar Tomcat como contenedor Servlet de Apache . . . . . . . . . . . 245

14.1 Introducción

El mayor crecimiento en tecnologías aplicadas al lado del servidor viene de la mano de Java. La
primera apuesta fueron los Java Servlets, pequeños programas que se ejecutan como respuesta a
una petición HTTP (vea la sección 3.3 en la página 43). Posteriormente apareció JSP (Java Server
Pages), una solución Java embebida en código HTML (vea la sección 4.3 en la página 59).

237
238 CAPÍTULO 14. SERVLETS Y JSP CON TOMCAT. INTEGRACIÓN CON APACHE

Aunque hay varios productos que implementan contenedores de Servlets, el que tiene más
respaldo1 en la actualidad es Jakarta2 Tomcat. Tomcat está siendo desarrollado en un entorno
abierto y participativo bajo la licencia de Apache Software. A fecha actual (junio 2001) existen
varias versiones disponibles para su utilización. En este capítulo se discute como instalar y utilizar
Tomcat 3.2.3 (la última versión binaria disponible del producto) tanto para ser ejecutado de manera
independiente como para integrarlo en Apache como contenedor Servlet externo.

14.2 Pasos previos: instalar soporte Java

Tomcat está escrito en Java y por tanto lo primero que se necesita conseguir (si no la tenemos
ya) es una versión del JDK (Java Development Kit) que estará disponible en la Web de SUN
(http://java.sun.com). Tomcat recomienda utilizar una versión igual o superior a la JDK 1.1.
Actualmente se puede conseguir como versión estable el J2SDK 1.3.13 .

La J2SDK (Java 2 Software Development Kit), es el kit de desarrollo software Java 2, un entorno
de desarrollo para construir aplicaciones, applets, etc, que podrán ser desplegadas en la plataforma
Java 2. Incluye herramientas básicas para desarrollar y probar programas escritos en Java. Entre
ellas la JVM (Java Virtual Machine), el corazón (core) de las librerías de clases, compilador,
debugger, etc.

14.2.1 Instalar JSDK

Desde la zona de download del sitio de SUN (figura 14.1) puede conseguirse una versión
adecuada a nuestra plataforma y modo preferido de instalación del JSDK. Por ejemplo el archivo
j2sdk-1_3_1-linux-i386-rpm.bin es la versión binaria empaquetada como rpm.

Para instalarlo se siguen un par de pasos:

1. Se mueve el archivo a un directorio temporal de instalación y se ejecuta:

# mv j2sdk-1_3_1-linux-i386-rpm.bin /usr/local/proyecto/src
# /usr/local/proyecto/src/j2sdk-1_3_1-linux-i386-rpm.bin

2. Tras leer y aceptar la licencia se obtiene un paquete rpm instalable de la manera habitual
(vea la sección 10.5.2 en la página 142), como root se ejecuta:

# rpm -i jdk-1.3.1.i386.rpm
1 Es la implementación de referencia SUN para las especificaciones de Java Servlets [23] y JSPs [22].
2 Jakarta [53] es el nombre común que engloba un conjunto de proyectos relacionados con Java, desarrollados bajo
el control del Apache Software Foundation.
3 Por motivos de marketing, los nombres de los productos de SUN han sufrido un cambio. Lo que antes era JDK

ahora es J2SDK, y a veces también se le conoce como JSDK. Este baile de nombres puede provocar equívocos, en la
página de SUN puede encontrarse más información sobre las equivalencias.
14.2. PASOS PREVIOS: INSTALAR SOPORTE JAVA 239

Figura 14.1: Página de descarga de J2SDK.

Esto crea el nuevo directorio /usr/java/jdk1.3.1 donde se aloja el conjunto de

programas, librerías, ejemplos y documentación recién instalado.

3. El último paso de la instalación es configurar algunas variables de entorno:

PATH: se añadirá a esta variable la ruta donde residen los ejecutables del JDK
(/usr/java/jdk1.3.1/bin/) y JRE (/usr/java/jdk1.3.1/jre/bin/). Así se
consigue habilitar la ejecución de programas Java desde cualquier lugar del sistema
de ficheros.


JAVA_HOME: contendrá el directorio que raíz que contiene el JSDK, para esta
instalación /usr/java/jdk1.3.1/.


CLASSPATH: contendrá los directorios y/o archivos .jar que contienen las clases
Java. Es importante incluir en la lista el directorio actual (./).

Es habitual que se quiera que estos cambios en las variables sean permanentes y afecten a
todos los usuarios. Para ello se puede modificar el fichero /etc/profile. Como root se
edita este fichero añadiendo las siguientes líneas:

PATH="$PATH:/usr/java/jdk1.3.1/bin/:/usr/java/jdk1.3.1/jre/bin/"
JAVA_HOME="/usr/java/jdk1.3.1/"
CLASSPATH="/usr/java/jdk1.3.1/jre/lib/i18n.jar:...:./"

export PATH JAVA_HOME CLASSPATH

240 CAPÍTULO 14. SERVLETS Y JSP CON TOMCAT. INTEGRACIÓN CON APACHE

14.2.2 Probar el JSDK

Con los pasos previos se ha instalado el soporte para Java en el equipo. Para probar la instalación
se puede utilizar algún pequeño programa. Es ya clásico utilizar el programa Hola Mundo:

public class HolaMundo{

public static void main(String args[])
{
System.out.println("Hola mundo");
}
}

Listado 14.1 El programa Hola Mundo escrito en Java.

Se compila el programa con javac y se ejecuta con java:

# javac HolaMundo.java
# java HolaMundo
Hola Mundo

14.3 Tomcat como contenedor Servlet

14.3.1 Instalar Tomcat

Se puede elegir entre varios formatos de instalación (binarios en diversos formatos de paquete o
código fuente). Para este proyecto se ha decidido4 utilizar la versión binaria (en paquetes RPM).
Desde el sitio del proyecto Jakarta http://jakarta.apache.org/ (figura 14.2) se obtienen un
par de ficheros rpm:

tomcat-3.2.3-1.noarch.rpm: contiene el ejecutable tomcat, ficheros asociados y

documentación.


tomcat-webapps-3.2.3-1.noarch.rpm: contiene un sitio Web de ejemplo con enlaces a

distintos Servlets y JSPs.

Se instala el paquete siguiendo la operativa habitual:

# rpm -i tomcat-3.2.3-1.noarch.rpm
# rpm -i tomcat-webapps-3.2.3-1.noarch.rpm
4 Después de intentarlo con la versión en código fuente y tener más de un problema.
14.3. TOMCAT COMO CONTENEDOR SERVLET 241

Figura 14.2: Página de descarga de Tomcat.

14.3.2 Ficheros de configuración

No es necesario modificar la configuración por defecto para probar si la instalación funciona. De

todas formas y de una manera breve se puede comentar cual es el esquema básico para configurar
Tomcat. Se basa en dos ficheros escritos en XML:

server.xml: fichero global de configuración del contenedor Servlet. Se utiliza para cosas
como ficheros de log (<Logger ... />), el gestor de contexto (<Connector ... />, <Context
.../>, <Host .../>, etc). Más información puede obtenerse en las páginas de documentación
que acompañan al programa.


web.xml: fichero de configuración de diversos aspectos de las aplicaciones que se ejecutan

en el servidor. La estructura de este fichero es perfectamente analizada en la especificación
del API Servlet [23].

14.3.3 Probar Tomcat como contenedor Servlet independiente

Con la instalación realizada hasta ahora Tomcat ya funciona, pero sólo en modo standalone, es
decir, como un demonio independiente que puede servir páginas Web y ejecutar Servlets y JSPs.
Para probar si está funcionando adecuadamente lo primero es arrancar el servidor:

# /usr/bin/tomcat start
Using classpath: /var/tomcat/lib/ant.jar:/var/tomcat/lib/jasper.jar:
/var/tomcat/lib/parser.jar:/var/tomcat/lib/servlet.jar:
/var/tomcat/lib/test:/var/tomcat/lib/webserver.jar:
/var/tomcat/lib/xerces.jar:/usr/java/jdk1.3.1/lib/tools.jar:./
242 CAPÍTULO 14. SERVLETS Y JSP CON TOMCAT. INTEGRACIÓN CON APACHE

Luego se abrirá un navegador que intente conectarse a la URL que el servidor atiende por defecto,
y probar los ejemplos de Servlets y JSPs referenciados desde la misma:

http://localhost:8080/

Si todo va bien el resultado puede ser parecido al de la figura (figura 14.3).

Figura 14.3: Tomcat funcionando.

14.3.4 Iniciar con el arranque del sistema

El fichero que automatiza el arranque en un sistema con RedHat 7 es /etc/rc.d/init.d/tomcat.

Si se pretende que Tomcat se inicie automáticamente con el sistema, debe editarse este fichero y
hacer algunos cambios:

# El directorio raíz donde el paquete rpm ha instalado Tomcat

export TOMCAT_HOME=/var/tomcat

# JAVA_HOME lo hemos definido en /etc/profile, lo comentamos aqui

# export JAVA_HOME=...

# El PATH del JDK/JRE lo hemos definido en /etc/profile, lo comentamos aqui

# export PATH=...

14.4 Integrando Apache y Tomcat

Aunque Tomcat puede servir páginas Web como si fuese un servidor HTTP, en realidad ha sido
optimizado para funcionar como un contenedor Servlet. En sitios reales no es deseable que Tomcat
14.4. INTEGRANDO APACHE Y TOMCAT 243

se encargue de servir las páginas estáticas, por ello se suele optar por una solución integradora más
eficiente. Por un lado se utiliza un servidor Web (como puede ser Apache) para servir las páginas
estáticas y por otro Tomcat (como contenedor Servlet) para ejecutar Servlets y JSPs. Las razones
para seguir esta recomendación son varias:

Velocidad de ejecución: Tomcat no es capaz de servir páginas estáticas tan rápido como
Apache.


Configurabilidad: Apache es extremadamente configurable y ampliable por medio de

nuevos módulos.


Robustez: Apache, desde su creación en 1995, ha demostrado ser un software robusto,

mientras Tomcat aún tiene algunos problemas de estabilidad.


Integración con aplicaciones legacy: existen multitud de sitios que han venido desarrollando
aplicaciones basadas en CGI, PHP, etc, y no se puede asumir que todo se va a tirar a la basura
para instalar Tomcat como servidor Web.

Se necesitará un módulo especial (generalmente mod_jk) que permite la integración de Apache

y Tomcat. Si una petición se refiere a un Servlet o Jsp, el módulo se ocupará de la petición,
estableciendo una comunicación con el contenedor Servlet y cediéndole el control. Existen dos
posibles formas de comunicación:

in-proccess: es la manera más eficiente, se realiza a través de JNI y está disponible para
servidores multihilo (como Apache 2.0).


out-of-proccess: no es tan eficiente, se basa en sockets TCP/IP y es la manera de comunicar

procesos cuando no se puede usar JNI, por ejemplo en las versiones de Apache anteriores a
la 2.0.

14.4.1 Obtener adaptador para Apache

mod_jk frente a mod_jserv

Dos son los adaptadores disponibles en la actualidad jk y JServ. mod_jk es un plugin

completamente nuevo. Soluciona algunos de los problemas que habían aparecido en el “viejo”
mod_jserv:

mod_jserv: es demasiado complejo y soporta requisitos específicos que no afectan a

Tomcat.


mod_jserv: sólo soporta el servidor Web Apache. Con mod_jk, en cambio, varios
servidores Web tendrán la posibilidad de acceder a Tomcat, mediante una capa intermedia
llamada biblioteca jk.
244 CAPÍTULO 14. SERVLETS Y JSP CON TOMCAT. INTEGRACIÓN CON APACHE

Respecto a los métodos de comunicación entre Apache y Tomcat, mod_jserv sólo soporta
AJP v1.25 . mod_jk en cambio soporta :

– AJP v1.3: que mejora el rendimiento de comunicación entre Apache y Tomcat

reutilizando conexiones TCP).

– JNI: el método más rápido en caso de tener servidores multihilo (por ejemplo Apache
2.0).

mod_jk puede obtenerse en varios formatos, la opción más cómoda es conseguir algún tipo de
formato binario (por ejemplo un paquete RPM) adecuado a nuestra plataforma. Puede encontrarse
en la Web del proyecto Jakarta (http://jakarta.apache.org/) dentro del mismo directorio
desde donde se descarga la distribución de Tomcat. Por ejemplo para Tomcat 3.X y plataforma
Linux se pueden conseguir dos versiones del fichero:

1. mod_jk-eapi.so

2. mod_jk-noeapi.so

Los servidores Apache ofrecen por defecto la API estándar, en cambio los que pretenden dar
capacidades de comunicación segura sobre SSL mediante el módulo mod_ssl ofrecen la EAPI.
Según el caso se seleccionará el el fichero adecuado y se moverá a la localización donde se
encuentran los módulos de Apache (generalmente libexec) renombrándolo como mod_jk.so.
Por ejemplo:

# mv mod_jk-noeapi.so /usr/local/proyecto/apache/libexec/mod_jk.so

14.4.2 Habilitar auto-configuración de Tomcat para Apache

Tomcat, cada vez que arranca, es capaz de generar automáticamente la configuración que Apache
necesita y volcarla en un fichero mod_jk.conf-auto. En la versión que se está instalando, el
fichero auto configurado se crea en TOMCAT_HOME/conf/.

Aunque siempre es posible abrir el fichero que contiene la autoconfiguración, copiar las directivas
y pegarlas en el lugar adecuado de httpd.conf, existe otra forma más sencilla de obtener el
mismo resultado. Se trata de utilizar la directiva de Apache Include. Esta directiva permite la
inclusión de otros ficheros de configuración. De esta manera se puede editar httpd.conf e incluir
al final del mismo una línea del estilo de la siguiente:

Include /var/tomcat/conf/mod_jk.conf-auto
5 AJP v1.2 se considera un proyecto acabado y carece de mantenimiento.
14.4. INTEGRANDO APACHE Y TOMCAT 245

14.4.3 Probar Tomcat como contenedor Servlet de Apache

El primer paso es arrancar los demonios en orden, primero Tomcat y luego Apache. Si se hace así
no habrá problemas extraños, recuerde que Tomcat al iniciarse, genera un fichero de configuración
que necesita Apache. Si Apache arranca antes es probable que esté leyendo un fichero no válido.
Un ejemplo de las órdenes de arranque:

# /usr/bin/tomcat start
# /usr/local/proyecto/apache/bin/apachectl start

Una vez arrancados los servicios, se puede probar una petición a Apache de un Servlet o Jsp. Por
ejemplo para acceder a los ejemplos que proporciona Tomcat se utiliza la URL6 :

http://localhost/examples

Si todo va bien el resultado puede ser parecido al que se obtenía en la ejecución independiente de
Tomcat (figura 14.3), pero encapsulando la petición a través de Apache.

6 Esta información la obtenemos en el archivo de autoconfiguración de Apache “mod_jk.conf-auto”.

246 CAPÍTULO 14. SERVLETS Y JSP CON TOMCAT. INTEGRACIÓN CON APACHE
Capítulo 15

Configurando PHP

Contenidos de este capítulo

15.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
15.2 Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
15.2.1 Instalación usando DSO . . . . . . . . . . . . . . . . . . . . . . . . . 248
15.3 Configurar Apache para manejar PHP . . . . . . . . . . . . . . . . . . . . 250
15.3.1 php.ini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
15.3.2 httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
15.4 Probar funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

15.1 Introducción

PHP (PHP: Hypertext Preprocessor) [88] es uno de los lenguajes embebidos en páginas HTML
que más se utiliza en la actualidad, provee numerosas interfaces que le permiten comunicarse
con multitud de bases de datos, protocolos, etc. Además la posibilidad de compilarlo como un
intérprete externo permite que sea utilizable desde CGI en casi cualquier servidor Web. Más
información teórica sobre este tema se ofrece en un capítulo anterior (vea la sección 4.4 en la
página 64).
En este capítulo se explica como instalar y configurar la última versión disponible de PHP (PHP4)
con soporte a MySQL1 en un servidor Web Apache.

15.2 Instalación

Desde el sitio de PHP (http://www.php.net) se obtiene una copia (figura 15.1) de la última
versión disponible del software. A fecha de escritura de este capítulo esta versión es PHP 4.0.6.
En la Web pueden obtenerse distintas distribuciones (binarios, código fuente, etc.).
1 MySQL (vea la sección 8.2.1 en la página 109) es una base de datos de código libre muy utilizada en Internet.

247
248 CAPÍTULO 15. CONFIGURANDO PHP

Figura 15.1: Página de descarga de PHP.

Antes de instalar y para evitar problemas posteriores hay que tener en cuenta las librerías
compartidas que van a ser necesarias para PHP. Debe comprobarse que todas las necesarias
estén listadas en el fichero /etc/ld.so.conf. Si no lo están se incluirán utilizando la
herramienta ldconfig. Por ejemplo, si se desea utilizar MySQL y se tiene la librería compartida
en /usr/lib/mysql/libmysqlclient.so, en el fichero /etc/ld.so.conf aparecerá la ruta
/usr/lib/mysql.

Comprobando lo anterior se puede proceder con la instalación, existen varias posibilidades:

Compilar el servidor Web con el módulo de PHP incluido de forma estática.



Construir PHP como un interprete externo y utilizarlo para crear scripts CGI (al estilo de
Perl). Esta última es la forma de instalación por defecto porque hace posible que PHP pueda
ser utilizado en cualquier servidor Web que soporte CGI.


Construir un módulo DSO, en Apache es el método de instalación más habitual2 . Para

este proyecto se ha elegido la instalación desde código fuente3 , comprimido en el fichero
php-4.0.6.tar.gz.

15.2.1 Instalación usando DSO

Siguiendo la operativa habitual se descomprime el fichero obteniendo el árbol de instalación:

# gunzip -c -d php-4.0.6.tar.gz | tar xf -

# cd php-4.0.6
2Y el que permite la ejecución más eficiente de páginas PHP.
3 Existen también paquetes binarios que contienen una versión precompilada del módulo DSO para PHP. Diversas
distribuciones Linux, como por ejemplo Red Hat (http://www.redhat.com), utilizan este tipo de paquetes.
15.2. INSTALACIÓN 249

Como ya se comenta en un capítulo anterior, para configurar nuevos módulos en Apache se debe
haber compilado el servidor activando el módulo mod_so que es el da soporte a DSO. Si esto es
así se puede instalar el nuevo módulo para PHP:

1. En primer lugar se configura la instalación, utilizando un método muy parecido al de

Apache, mediante un script llamado ./configure que acepta multitud de parámetros4 .
El único absolutamente necesario es --with-apxs=RUTA_DE_apxs, que indica donde está
el programa apxs (vea la sección 10.4.3 en la página 140). Además es bastante habitual
configurar algunos otros parámetros:

--with-mysql=DIR, habilita el soporte para MySQL5 . El parámetro es el directorio de

instalación de MySQL y el valor por defecto es /usr/local. El soporte heterogéneo
de BBDD es una de las características más potentes de PHP. Se ha elegido MySQL
por ser código libre.


--prefix=RUTA indica el directorio base de donde colgarán los archivos necesarios

para PHP.

Como ejemplo para este proyecto se configuró PHP con los siguientes parámetros:

# cd php-4.0.6
# ./configure --prefix=/usr/local/proyecto/php \
--with-apxs=/usr/local/proyecto/apache1.3.20/bin/apxs \
--with-mysql=/usr

2. Luego se construye el paquete:

# make

3. Y por último se instala el módulo y los archivos adicionales necesarios para utilizar PHP:

# make install

4. Se copia el archivo de configuración de PHP a su ubicación adecuada:

# cp php.ini-dist /usr/local/lib/php.ini

/usr/local/lib/php.ini es la ubicación por defecto. Si se prefiere tenerlo en otro sitio

puede utilizarse el parámetro de configuración --with-config-file-path=/path.
4 Puede consultarse la lista completa de parámetros ejecutando ./configure –help. Para más información de lo que
hace cada parámetro consúltese la ayuda on-line en la página http://www.php.net
5 Obviamente necesitamos tener esta base de datos instalada en el mismo servidor.
250 CAPÍTULO 15. CONFIGURANDO PHP

15.3 Configurar Apache para manejar PHP

La configuración para el correcto funcionamiento de PHP utiliza dos ficheros, por un lado el
fichero php.ini y por otro el fichero de configuración de Apache httpd.conf.

15.3.1 php.ini

El archivo de configuración php.ini es leído cuando arranca el intérprete PHP. Para las versiones
en formato módulo de servidor (como el que se ha construido en este capítulo) esto sólo ocurre al
arrancar el servidor Web.

Editando el fichero php.ini pueden realizarse multitud de ajustes, aunque generalmente los
valores por defecto son válidos. Este archivo está perfectamente comentado y permite una
configuración muy detallada de la ejecución del interprete PHP usando una gran cantidad de
directivas. Muchas de ellas permiten cambiar valores que se configuran inicialmente como
parámetros del script ./configure. Por claridad las directivas de php.ini se agrupan en
secciones:

Opciones del lenguaje: diversas directivas para habilitar el motor PHP, permitir etiquetas al
estilo ASP, etc.


Límite de recursos: memoria y tiempo utilizados en una petición.



Manejo de errores y utilidades de log: ficheros donde se almacenan los errores, ...


Manejo de datos: directivas que manejan los datos que PHP recibe de las peticiones HTTP.


Rutas y directorios: raíz del PHP, ...



“Upload” de ficheros: habilita o deshabilita el “upload” de ficheros con HTTP.



“Wrappers” de apertura de ficheros: ¿se permite abrir URLs desde PHP?



Extensiones dinámicas: PHP permite una forma de carga dinámica de librerías compartidas.


Configuración de módulos: donde se establece la configuración para cada uno de los

módulos de PHP que hayamos instalado, por ejemplo el módulo de acceso a MySQL.

15.3.2 httpd.conf

El otro fichero de configuración es httpd.conf y debe ser modificado para indicarle al servidor
donde está el módulo que interpreta código PHP, para ello se utilizan las directivas de Apache
LoadModule (vea la sección 11.5.2 en la página 161) y AddModule (vea la sección 11.5.2 en la
página 159):
15.4. PROBAR FUNCIONAMIENTO 251

LoadModule php4_module libexec/libphp4.so

AddModule mod_php4.c

Y también cuales son los nuevos tipos MIME que indican las extensiones de ficheros asociados al
manejador PHP, utilizando la directiva AddType (vea la sección 11.8.4 en la página 191):

AddType application/x-httpd-php .php

AddType application/x-httpd-php-source .phps

La extensión .php se asocia con archivos que deben ser ejecutados por PHP.


La extensión .phps se asocia con el código fuente que el motor PHP puede interpretar y
presentar en una página Web con la sintaxis coloreada. Esta es una utilidad que puede
ayudar a la corrección de errores.

También se pueden cambiar ciertos ajustes de configuración del intérprete PHP desde el propio
httpd.conf, para ello se utilizan las directivas (tabla 15.1) que incluye el módulo de php
(mod_php4).

Directiva
php_value nombre valor
php_flag nombre on|off
php_admin_value nombre valor
php_admin_flag nombre on|off
Significado
Fija el valor de la variable especificada.
Fija una opción de configuración de tipo Boolean.
Fija el valor de la variable especificada. Los ajustes de
configuración de tipo “Admin” sólo se pueden fijar desde
los archivos principales de configuración del Apache, y
no desde los .htaccess.
Fija una opción de configuración de tipo Boolean. Debe
tenerse en cuenta la misma consideración para los ajustes
de tipo “Admin” que en la directiva anterior.

Tabla 15.1: Directivas de PHP4 dentro de la configuración de Apache.

15.4 Probar funcionamiento

Por último se reinicia el servidor (apachectl graceful) haciendo que se vuelva a leer la
configuración y se active el soporte PHP. Para probar el funcionamiento puede utilizarse una
pequeña página PHP de prueba como la siguiente:

<html>
<title>Primera página de prueba PHP</title>
<body>
<!-- Esta función PHP muestra la configuración actual -->
252 CAPÍTULO 15. CONFIGURANDO PHP

<?
phpinfo();
?>

</body>
</html>

Listado 15.1 phpinfo(). Una página PHP muy simple.

Este sencillo código es muy útil porque muestra los valores actuales de configuración del intérprete
PHP (figura 15.2).

Figura 15.2: Salida de phpinfo().

Capítulo 16

Autenticación, autorización y control de

acceso

Contenidos de este capítulo

16.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
16.2 Autenticación/autorización Basic . . . . . . . . . . . . . . . . . . . . . . . . 254
16.2.1 Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
16.2.2 Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
16.2.3 Posibles problemas y soluciones . . . . . . . . . . . . . . . . . . . . . 256
16.3 Autenticación/autorización Digest . . . . . . . . . . . . . . . . . . . . . . . 258
16.4 Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
16.5 Aspectos de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

16.1 Introducción

La autenticación (o autentificación) es un proceso mediante el que se verifica que alguien es quien

dice ser. Apache provee módulos (mod_auth, mod_digest, etc.) para soportar todos los métodos
definidos en el estándar HTTP/1.1 (vea la sección 2.3.4 en la página 32). Por autorización se
entiende el proceso por el que a alguien se le permite el acceso a los recursos que necesita. Estos
dos términos suelen estar ligados y generalmente si se autentica a un usuario de forma positiva, el
sistema autoriza su acceso.
El control de acceso se refiere a como controlar los recursos accesibles basándose en
características de los paquetes, como la dirección IP o el nombre del equipo. En Apache un
sólo módulo (mod_access) provee toda la funcionalidad.
En este capítulo se comenta como proteger partes de un sitio Web, abordando tanto los métodos
de autenticación definidos en la especificación HTTP (Basic y Digest), como su posible uso
combinado con el control de acceso basado en IPs o nombres de equipos.

253
254 CAPÍTULO 16. AUTENTICACIÓN, AUTORIZACIÓN Y CONTROL DE ACCESO

16.2 Autenticación/autorización Basic

Protege los directorios del servidor utilizando el método clásico de cuentas (login/password).
Apache emula el funcionamiento de los sistemas Linux/Unix, que se basan en los ficheros de
usuarios /etc/passwd y grupos /etc/group.

16.2.1 Usuarios

Lo primero que se necesita es un fichero de passwords de usuarios. Apache proporciona una

utilidad llamada htpasswd1 que permite la gestión de este fichero. Por ejemplo, para crear el
fichero y añadir el primer usuario:

# ./htpasswd -c /usr/local/proyecto/conf/controldeacceso becario1

New password: **
Re-type new password: **
Adding password for user becario1

Nuevos usuarios pueden añadirse en cualquier momento con un comando muy parecido al anterior:

# ./htpasswd /usr/local/proyecto/conf/controldeacceso becario2

Lo siguiente es indicar a Apache que directorio queremos proteger. Para ello se incluyen algunas
directivas en los ficheros adecuados (httpd.conf, access.conf, .htaccess). Quizá la manera
más cómoda sea crear un fichero .htaccess, en el directorio seleccionado y añadir las siguientes
líneas:

AuthType Basic
AuthName "Protegido mediante login/password"
AuthUserFile /usr/local/proyecto/conf/controldeacceso
AuthGroupFile /dev/null
require user usuario

A partir de este momento, cuando desde un navegador se solicite acceso al directorio protegido,
se presentará una ventana de diálogo que pide el login/password (figura 16.1).

16.2.2 Grupos

Con las directivas anteriores se permite el acceso autenticado de una persona. Cuando se pretende
ofrecer acceso a grupos, se debe utilizar la directiva AuthGroupFile. Se asocia esta directiva con
el nombre de un fichero que contenga la descripción de los grupos. El formato de este archivo
es muy sencillo y puede ser creado con cualquier editor de texto. Por ejemplo, se puede crear un
fichero llamado /usr/local/proyecto/conf/gruposdeacceso, con el siguiente contenido:
1 Dentro de “/bin” en la ruta donde se ha instalado el servidor.
16.2. AUTENTICACIÓN/AUTORIZACIÓN BASIC 255

Figura 16.1: Diálogo de petición de login/password en un navegador Opera.

matematicas: becario1 becario2

Cada línea de este fichero se compone de tres partes:

nombre del grupo, en este caso matematicas.



separador (:)


lista de nombres de usuarios válidos (creados con htpasswd) separadas por espacios.

Las directivas de configuración de Apache cambian ligeramente para proporcionar acceso a

grupos, un ejemplo es el siguiente:

AuthType Basic
AuthName "Protegido mediante login/password"
AuthUserFile /usr/local/proyecto/conf/controldeacceso
AuthGroupFile /usr/local/proyecto/conf/gruposdeacceso
Require group matematicas

Existe también otra forma para permitir acceso a grupos de usuarios. Consiste en listar los usuarios
con acceso permitido directamente en la configuración de Apache, y no utilizar ningún fichero de
grupos adicional. Esta forma suele utilizarse cuando se tienen pocos grupos y pocos usuarios en
cada grupo. Un ejemplo:

AuthType Basic
AuthName "Protegido mediante login/password"
256 CAPÍTULO 16. AUTENTICACIÓN, AUTORIZACIÓN Y CONTROL DE ACCESO

AuthUserFile /usr/local/proyecto/conf/controldeacceso
AuthGroupFile /dev/null
Require becario1 becario2

16.2.3 Posibles problemas y soluciones

Aunque en la mayoría de los sitios basta con los métodos explicados en las secciones anteriores, en
ciertos casos, se puede necesitar algo más. Lo más típico es que el servidor maneje un gran número
de cuentas, lo que obliga a recurrir a soluciones más eficientes de gestión y almacenamiento (como
bases de datos o directorios).

También habrá casos en los que se necesitan métodos de administración para los que no se
encuentra ningún módulo disponible en Apache, en esos casos, no queda otro remedio que recurrir
a la programación.

Autenticación/autorización mediante bases de datos y directorios

Varias son las razones para utilizar sistemas avanzados como bases de datos o directorios, frente
al mecanismo estándar basado en ficheros. Entre ellas:

Facilidad de recuperación de información, mediante lenguajes como SQL.



Velocidad de recuperación frente a un fichero de texto.

Integridad de datos. Se manejan automáticamente cosas que en un fichero tenemos que

hacer a mano. Por ejemplo la repetición de claves.

Hay varios módulos de Apache que permiten hacer autenticación de usuarios contra una base de
datos. Alguno de los más conocidos y utilizados se listan a continuación:

mod_auth_db: proporciona autenticación básica sobre HTTP. Es capaz de manejar archivos

de bases de datos con formato Berkeley DB. Es uno de los métodos más utilizados, por ello
Apache proporciona2 dbmmanage, una utilidad que automatiza la creación y gestión de las
cuentas. Un ejemplo de configuración que soporta autentificación contra bases de datos con
este formato podría ser:

AuthName "Acceso restringido"

AuthType Basic
AuthDBUserFile /usr/local/proyecto/conf/passwords.dat
AuthDBGroupFile /usr/local/proyecto/conf/passwords.dat

2 Dentro de “/bin” en la ruta donde hemos instalado el servidor.

16.2. AUTENTICACIÓN/AUTORIZACIÓN BASIC 257

mod_auth_dbm: proporciona una alternativa a la anterior, almacenando las cuentas en bases

de datos de tipo DBM. Este módulo se instala con cualquier Apache estándar.


mod_auth_mysql: provee las directivas necesarias para manejar autenticación contra bases
de datos con formato MySQL.


mod_auth_pgsql: maneja autenticación contra bases de datos con formato PostgresSQL.



mod_auth_oraX: provee autenticación contra bases de datos en formato Oracle X (7, 8,

etc.).


...

También hay soluciones basadas en directorios, a título informativo comentamos algunos:

mod_auth_ldap: proporciona autenticación sobre un servicio de directorio ligero LDAP.



mod_auth_nis: utiliza la información de las páginas amarillas NIS.



mod_auth_smb: capaz de acceder y utilizar información de un servidor de ficheros SMB

(Server Message Block). Este sistema de ficheros se utiliza en las redes Windows.


...

Desde el punto de vista del cliente, estos métodos no suponen ninguna diferencia. Para todos ellos
aparecerá el diálogo estándar pidiendo login/password. Los cambios solamente afectan a como el
servidor chequea la validez de los datos proporcionados por el usuario.

Autenticación/autorización mediante programas auxiliares

Uno de los casos más típicos en el que se usan programas auxiliares es cuando se trata de
automatizar la gestión de las claves de acceso de usuarios.

Generalmente se recurre a un programa CGI (en cualquier lenguaje de programación) o algún tipo
de código embebido en HTML (PHP, etc.). Lo único realmente importante es que el lenguaje
elegido proporcione de manera sencilla facilidades de encriptación de passwords, manejo de
ficheros y si es necesario, acceso a bases de datos o directorios. Un buen ejemplo de un lenguaje
que da soporte a todo esto es Perl. Podría tenerse un código parecido al siguiente:

# Encriptación de datos

$encrypted = crypt ($password, $salt);

...

# Manejo de ficheros de passwords

258 CAPÍTULO 16. AUTENTICACIÓN, AUTORIZACIÓN Y CONTROL DE ACCESO

open PASSWD, ’>>/usr/local/proyecto/conf/controldeacceso’;

print PASSWD "$username:$encrypted\n";
close PASSWD;

...

# Acceso a bases de datos mediante perl DBI

# Un ejemplo sobre MySQL

use DBI;
my $dbh = DBI->connect(’DBI:mysql:database’, ’username’,’clave_db’);
my $sth = $dbh->prepare("update passwords
set passwd = ’$crypt’ where username = ’$username’");
$sth->execute;
$sth->finish;
$dbh->disconnect;

Listado 16.1 Perl para tareas de autenticación.

16.3 Autenticación/autorización Digest

El módulo mod_auth_digest se incorpora como experimental en las distribuciones de Apache3 .

No ha sido ampliamente probado porque no hay muchos clientes con soporte a este tipo de
autenticación4 . La autenticación Digest es un poco más segura que la autenticación básica, aunque
debido a su poco soporte entre los clientes Web, no se recomienda su uso.
De todas maneras, en lo que respecta a Apache, la configuración es sencilla, bastaría con introducir
las siguientes líneas:

<Location /private/>
AuthType Digest
AuthName "Área privada"
AuthDigestDomain /private/
AuthDigestFile /usr/local/proyecto/conf/controldigest
Require valid-user
</Location>

Al igual que para autentificación básica se proporciona la utilidad htpasswd, para autentificación
digest, Apache proporciona htdigest que automatiza la creación de los ficheros con las cuentas.
3 También se proporciona una implementación antigua, que probablemente no funcione con los navegadores actuales,

llamada “mod_digest”.
4 Aunque algunos sí, por ejemplo “Amaya”, un proyecto del W3C.
16.4. CONTROL DE ACCESO 259

16.4 Control de acceso

A veces para mejorar el nivel de protección ofrecido, se combinan sistemas de

autenticación/autorización a nivel usuario (login/password), con sistemas de control de acceso
basados en dirección IP o nombre DNS. El módulo de Apache mod_access provee las directivas5
Allow, Deny y Order que pueden utilizarse para configurar el control de acceso basado en IP o
nombre DNS. Un ejemplo:

Order deny,allow
Deny from all
Allow from ei.universidad.es 193.147.87.211

Existe una directiva Satisfy que tiene especial relevancia cuando en la configuración de un recurso
se mezclan directivas de control de acceso (Allow, Deny, etc.) y la directiva de autenticación
Require. Satisfy puede tener dos valores all o any. El comportamiento por defecto es all e
indica que antes de darle acceso a un cliente, este debe cumplir las restricciones impuestas por las
directivas de control de acceso y también proporcionar un login/password válido. Con el valor
any, bastará con cumplir una de las restricciones. Por ejemplo, se puede proteger un recurso de
forma que se permita el acceso a todos los usuarios de la red local, y a cualquier usuario externo
que conozca el login/password:

AuthName "Acceso restringido"

AuthType Basic
AuthUserFile /usr/local/proyecto/conf/controldeacceso
AuthGroupFile /dev/null
Satisfy any
Allow from ei.universidad.es
Require valid-user usuario

16.5 Aspectos de seguridad

Si se pretende implantar alguno de los métodos explicados en las secciones anteriores, deben
tenerse en cuenta las siguientes consideraciones de seguridad:

Los métodos de autenticación Basic y Digest no pueden considerarse métodos de

transferencia de información seguros. Ninguno de ellos protege (encripta) la información
que se envía por la red. En realidad el método Digest, es un poco más “seguro” ya que
protege la información de autenticación (login/password), pero todo el resto va en claro.
La información verdaderamente importante debería utilizar algún otro método de transporte
“seguro” como HTTP+SSL o SHTTP (vea el capítulo 5 en la página 77).
5 De todas ellas hemos hablado en otro capítulo (vea la sección 11.10 en la página 200).
260 CAPÍTULO 16. AUTENTICACIÓN, AUTORIZACIÓN Y CONTROL DE ACCESO

Ubicación y permisos de los archivos de contraseñas. Deberían ubicarse fuera del

árbol de directorios que contiene la páginas Web, así se evita que accidental (o
intencionadamente) alguien lo lea y comprometa nuestra seguridad. Por ejemplo si tenemos
los documentos en /usr/local/proyecto/htdocs el fichero de passwords podría estar
en /usr/local/proyecto/conf. Los permisos también deben ser chequeados para que el
único usuario y grupo con acceso sean los definidos para ejecutar Apache.


Además debe atenderse a las tres consideraciones típicas sobre cualquier contraseña. Por
un lado se garantizará que la distribución de las contraseñas es segura (PGP, etc.). Por otro,
si un usuario puede cambiar su contraseña, debe hacerlo de manera segura. Por último,
la contraseña debe ser algo lo suficientemente difícil de adivinar, por ejemplo no debería
utilizarse el nombre, dni o fecha de nacimiento.
Capítulo 17

Habilitando la gestión remota de

recursos con WebDAV

Contenidos de este capítulo

17.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

17.2 Obtener el software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
17.3 Instalando como DSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
17.4 Configurando Apache para manejar mod_dav . . . . . . . . . . . . . . . . 263
17.4.1 Habilitando DAV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
17.4.2 Base de datos de bloqueos . . . . . . . . . . . . . . . . . . . . . . . . 263
17.4.3 Estableciendo temporizadores . . . . . . . . . . . . . . . . . . . . . . 264
17.4.4 Consideraciones de seguridad . . . . . . . . . . . . . . . . . . . . . . 264
17.5 Probar configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

17.1 Introducción

mod_dav es un módulo de Apache que proporciona capacidades DAV (vea la sección 7.3 en la
página 102). Actualmente proporciona todas las capacidades básicas para manipular recursos
remotos. Desde la versión 1.0, mod_dav es suficientemente estable, aunque la versión actual
1.0.2 (Octubre 2000) corrige algunos pequeños errores y mejora los procesos de instalación y
configuración.

Aunque mod_dav [70] se incorpora como un módulo más de la distribución estándar de Apache
2.0, en las versiones 1.3.X debe ser instalado como módulo de tercera parte. Realizar la
configuración correctamente es el objetivo de este capítulo.

261
262CAPÍTULO 17. HABILITANDO LA GESTIÓN REMOTA DE RECURSOS CON WEBDAV

17.2 Obtener el software

En el sitio Web oficial de mod_dav (http://www.lyra.org/greg/mod_dav/) se puede

encontrar la última versión actualizada en formato código fuente (figura 17.1) en el fichero
mod_dav-1.0.2-1.3.6.tar.gz 1 .

Figura 17.1: Página de descarga de mod_dav

Se copia el fichero a un directorio temporal de instalación se descomprime y obtiene el árbol de

código fuente:

# mv mod_dav-1.0.2-1.3.6.tar.gz /usr/local/proyecto/src
# cd /usr/local/proyecto/src
# gunzip -c -d mod_dav-1.0.2-1.3.6.tar.gz | tar xf -
# cd mod_dav-1.0.2-1.3.6

17.3 Instalando como DSO

Aprovechando que se dispone de un servidor Apache que soporta DSO, se puede añadir este nuevo
módulo de manera dinámica2 . Se siguen los siguientes pasos:

En primer lugar se configura la instalación, indicando donde se encuentra el programa apxs que
se encargará de compilar este nuevo módulo:

./configure --with-apxs=/usr/local/proyecto/apache/bin/apxs
1 El nombre del módulo es confuso, pero no se necesita instalar un apache 1.3.6 para utilizarlo. Funcionará
correctamente con las versiones de Apache iguales o superiores a 1.3.6.
2 Aunque puede utilizarse cualquier otro tipo de instalación, más información en la Web de “mod_dav”.
17.4. CONFIGURANDO APACHE PARA MANEJAR MOD_DAV 263

Si todo va bien, se sigue con la operativa habitual:

make
su
make install

make construye el código atendiendo a sus reglas internas. Con su se pasa a ser superusuario
de la máquina. Finalmente make install ubica el módulo recién construido libdav.so en la
ubicación adecuada.

17.4 Configurando Apache para manejar mod_dav

Como para cualquier otro módulo DSO, debe informarse a Apache de que el nuevo módulo ha
sido instalado y está disponible. Se añaden las siguientes directivas al fichero de configuración
httpd.conf3 :

Loadmodule dav_module libexec/libdav.so

Addmodule mod_dav.c

17.4.1 Habilitando DAV

Se pueden habilitar las capacidades DAV en secciones específicas del servidor Web. Para ello
dentro de cualquier sección <Directory> o <Location> se inserta la directiva:

DAV On

17.4.2 Base de datos de bloqueos

Una de las características de WebDAV es la protección ante escritura mediante bloqueos. El

módulo mod_dav proporciona la directiva DAVLockDB, por ejemplo:

DAVLockDB /usr/local/apache/var/DAVLock

Esta directiva sólo puede aparecer en los contextos de Apache server config y virtual host (vea la
sección 11.4.1 en la página 152). Llega con que aparezca una vez e indica el nombre de un fichero
especial que mod_dav creará4 para gestionar los bloqueos. Debe garantizarse que sea accesible
por el proceso del servidor Web. Además no estará ubicado en una partición montada por NFS ya
que mod_dav usa llamadas a funciones de sistema no permitidas en volúmenes NFS.
3 Si
se ha utilizado la instalación como módulo dinámico en una plataforma Linux/Unix, este proceso se realiza
automáticamente.
4 En realidad se crean varios ficheros con el nombre especificado y diversas extensiones.
264CAPÍTULO 17. HABILITANDO LA GESTIÓN REMOTA DE RECURSOS CON WEBDAV

17.4.3 Estableciendo temporizadores

La directiva opcional DAVMinTimeout indica el tiempo de vida mínimo de un bloqueo en

segundos. El valor por defecto es 0, y desactiva esta característica. Podemos cambiarlo indicando
el tiempo en segundos, por ejemplo:

DAVMinTimeout 600

Si un cliente solicita un tiempo menor, se ignora, utilizando en cambio el especificado por esta
directiva. Por ejemplo los Web folders de Microsoft establecen un temporizador de 2 minutos (120
segundos), con esta directiva el servidor ignora este valor y utiliza el suyo propio, por ejemplo 10
minutos (600 segundos).

17.4.4 Consideraciones de seguridad

Previniendo la exploración recursiva de propiedades

El estándar WebDAV define una petición llamada PROPFIND que se encarga de solicitar las
propiedades de recursos en un servidor WebDAV. Existe un parámetro para PROPFIND, que
define la profundidad (Depth) hasta la que se buscan las propiedades. Depth acepta el valor
Infinity y esto es potencialmente peligroso. Una búsqueda de este estilo recorre todo el repositorio
devolviendo información de cada recurso. Como mod_dav construye las respuestas en memoria
se puede llegar a consumir una cantidad demasiado grande.

Para prevenir este posible problema se proporciona la directiva DAVDepthInfinity, que permite
habilitar(on) o deshabilitar (off), la exploración recursiva. Puede aplicarse tanto a nivel de servidor
como en secciones <Directory> o <Location>. Un ejemplo que deshabilita esta propiedad en todo
el servidor:

DAVDepthInfinity Off

Limitando tamaño de las peticiones en XML

Las peticiones en formato XML se analizan en memoria, esto puede dar lugar a problemas de
desbordamiento. Alguien con malas intenciones podría realizar un ataque “Denial of Service”5 ,
enviando a nuestro servidor peticiones con grandes cantidades de datos.

La directiva proporcionada por Apache LimitRequestBody evita este tipo de peticiones en los
métodos de uso más habitual con HTTP. Desgraciadamente esta directiva no es aplicable en
mod_dav, donde se deben permitir grandes cantidades de datos enviados a través de PUT.
5 Los ataques de este estilo se basan en enviar a un equipo más peticiones de las que puede atender. Finalmente el

ordenador atacado se queda sin recursos y debe ser reiniciado.

17.5. PROBAR CONFIGURACIÓN 265

Para limitar exactamente los métodos que tengan un cuerpo en XML, mod_dav define la directiva
LimitXMLRequestBody. El valor por defecto es 1000000 de bytes, un valor de 0 deshabilita
esta propiedad. Puede establecerse tanto a nivel de servidor como en secciones <Directory> o
<Location>. Un ejemplo:

LimitXMLRequestBody 2000000

17.5 Probar configuración

En esta sección se establece una sencilla configuración de prueba del servidor WebDAV, se tiene un
directorio en el servidor (/usr/local/proyecto/dav/)6 , que se podrá utilizar como repositorio
a través de la URL http://localhost/dav/. A continuación se muestran las líneas necesarias
en httpd.conf:

DAVLockDB /usr/local/proyecto/dav/DAVLock
DAVMinTimeout 100

Alias /dav/ "/usr/local/proyecto/dav/"

<Directory "/usr/local/proyecto/dav">
DAV On
</Directory>

Tras hacer estos cambios y reiniciar el servidor este ya está configurado, ¿y ahora que? Se
necesita un cliente. Como ya se comenta en una sección anterior (vea la sección 7.3.4 en la
página 104), existen múltiples clientes de WebDAV. Por su sencillez, facilidad de instalación
y disponibilidad para Linux, se ha elegido WebDAV Explorer. Puede descargarse desde la
URL http://www.ics.uci.edu/~webdav/download.html. Se obtiene un programa Java
compactado mediante tar y gzip (DAVExp-0.72.tar.gz). Una vez descomprimido estará listo
para ejecutar7 , mediante un fichero de lotes con un nombre parecido a DAVExplorer.sh .

El programa tiene la típica apariencia de los exploradores de sistemas de ficheros (figura 17.2).
Hay una barra de dirección donde se puede indicar la URL (habilitada para DAV) a la que debe
conectarse, y en los diversos menús pueden realizarse otras operaciones (bloquear, borrar, etc.).

6 El directorio necesita poseer permisos de escritura para el usuario que ejecuta Apache, o no se podrán realizar
operaciones de escritura.
7 Si se tiene instalada la plataforma Java 2. Si ese no es el caso, en una sección anterior (vea la sección 14.2.1 en la

página 238) se explica como hacerlo.

266CAPÍTULO 17. HABILITANDO LA GESTIÓN REMOTA DE RECURSOS CON WEBDAV

Figura 17.2: Un cliente WebDAV para Linux: WebDAV Explorer.

Capítulo 18

Configurar conexiones seguras en

Apache sobre SSL

Contenidos de este capítulo

18.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

18.2 Apache + mod_ssl + OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 268
18.3 Prerrequisito: OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
18.4 Instalación de Apache + mod_ssl . . . . . . . . . . . . . . . . . . . . . . . . 270
18.4.1 Obtener paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
18.4.2 Aplicar parches y configurar instalación de Apache . . . . . . . . . . . 271
18.4.3 Instalar Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
18.5 Revisando la configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
18.6 Probando una conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
18.6.1 Arranque del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 276
18.6.2 Los clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

18.1 Introducción

En un capítulo anterior (vea el capítulo 5 en la página 77) se discuten las distintas posibilidades
para conseguir una transferencia de datos más segura sobre el protocolo HTTP.

En Apache existen dos opciones en código abierto para conseguir un servidor Web “seguro”1 :

Apache-SSL [19] : una implementación de un servidor Web Apache con soporte para SSL.
No se usa un módulo, más bien un parche del core de Apache, junto con una serie de
elementos adicionales que se apoyan en OpenSSL.
1 Muchas soluciones comerciales también se basan en Apache. Por ejemplo Stronghold o IBM HTTP Server.

267
268 CAPÍTULO 18. CONFIGURAR CONEXIONES SEGURAS EN APACHE SOBRE SSL

Apache + mod_ssl [72]: es el servidor Apache con un módulo que sirve de enlace hacia
las funcionalidades proporcionadas por OpenSSL. Es una evolución natural a la alternativa
propuesta por Apache-SSL.

Las dos opciones anteriores son completamente diferentes, una es un módulo y la otra un parche,
aunque existe mucha confusión debido a que ambas se basan en OpenSSL y Apache. En
este capítulo se discute la instalación basada en mod_ssl, entre otras cosas porque está mejor
documentada, y es mantenido con mayor frecuencia.

18.2 Apache + mod_ssl + OpenSSL

La arquitectura (figura 18.1) para el servidor ”seguro” que se va a instalar a continuación se apoya
en tres elementos básicos:


Apache: con su core y su API.



mod_ssl: [72] esencialmente es un módulo adaptador para Apache que proporciona una
fuerte base criptográfica basada en los protocolos SSL v2/v3 y TLS v1 (implementados en
el conjunto de herramientas OpenSSL). El paquete de mod_ssl consiste en el módulo ssl
y en un conjunto de parches para Apache que entre otras cosas añaden el Extended API
(EAPI).


OpenSSL: [84] una implementación en código libre del protocolo SSL (vea la sección 5.2.5
en la página 83). En ciertos paises, para cumplir con la legalidad, OpenSSL debe utilizar un
conjunto de parches (RSAREF) que limitan sus funcionalidades.

Figura 18.1: Arquitectura del módulo mod_ssl.

18.3 Prerrequisito: OpenSSL

OpenSSL debe estar instalado en el equipo. Las plataformas Linux actuales, como por ejemplo
RedHat 7.X, suelen incluir en sus distribuciones alguna versión. Si por cualquier circunstancia no
18.3. PRERREQUISITO: OPENSSL 269

se dispone del programa, el primer paso será conseguir una versión del código fuente2 en la Web
http://www.openssl.org (figura 18.2) e instalarla siguiendo las instrucciones.

Figura 18.2: Página de descarga de OpenSSL.

Por ejemplo, una vez descargada la versión en código fuente contenida en el fichero
open_ssl0.9.6a.tar.gz pueden seguirse los siguientes pasos hasta completar la instalación:

# mv open_ssl0.9.6a.tar.gz /usr/local/proyecto/src
# cd /usr/local/proyecto/src
# gzip -d -c open_ssl0.9.6a.tar.gz | tar xvf -
cd openssl-0.9.6a
sh config
make
make test

Para verificar que la instalación fue correcta se prueba el ejecutable openssl escribiendo en la
línea de órdenes:

# openssl version
OpenSSL 0.9.6a 1 Apr 2001

Si el programa existe y funciona adecuadamente la respuesta será el número de versión y fecha de

construcción. Una vez hecha esta comprobación ya se puede pasar a instalar mod_ssl.

2 Pueden conseguirse también versiones binarias, por ejemplo en http:/www.redhat.com

270 CAPÍTULO 18. CONFIGURAR CONEXIONES SEGURAS EN APACHE SOBRE SSL

18.4 Instalación de Apache + mod_ssl

Para que Apache utilice mod_ssl, es absolutamente necesario que sea construido con soporte
para la EAPI (Extended API). Esta se proporciona en el mismo paquete del módulo ssl (como
un parche del código fuente de Apache). Por tanto, a no ser que se consiga un servidor Web en
formato binario con la EAPI preinstalada, se está obligado a partir del árbol de código fuente de
Apache, aplicarle los parches y a continuación instalar de la manera habitual.

Si por el contrario se dispone de un servidor que ya ofrece la EAPI y soporta DSO, se puede
actualizar actualizar simplemente el módulo ssl (libssl.so) de una manera sencilla utilizando
apxs.

Para este ejemplo se supone que es la primera vez que se va a instalar mod_ssl, y no se ha
conseguido ninguna versión preconfigurada que ofrezca la EAPI. A continuación se describen los
pasos a seguir:

18.4.1 Obtener paquetes

Conseguir una copia en código fuente de Apache desde el sitio http://httpd.apache.org,

también se necesita el paquete con el código de mod_ssl, puede conseguirse en http://www.
modssl.org (figura 18.3).

Figura 18.3: Página de descarga de modSSL.

Siguiendo la operativa habitual para la instalación desde código fuente, se copian los paquetes
necesarios al directorio temporal de instalación y se descomprimen:

# mv apache_1.3.20.tar.gz /usr/local/proyecto/src
# mv mod_ssl-2.8.4-1.3.20.tar.gz /usr/local/proyecto/src
18.4. INSTALACIÓN DE APACHE + MOD_SSL 271

# gzip -d -c apache_1.3.19.tar.gz | tar xvf -

# gzip -d -c mod_ssl-2.8.4-1.3.20.tar.gz | tar -xvf -
# cd /usr/local/proyecto/src

18.4.2 Aplicar parches y configurar instalación de Apache

A continuación se aplican las modificaciones de mod_ssl a Apache, mediante el método APACI.

Lo único realmente necesario es indicar donde está el código fuente de Apache (--with-apache)
y donde se ha instalado el OpenSSL (--with-ssl)3 :

# cd mod_ssl-2.8.4-1.3.20
# ./configure --with-apache=../apache_1.3.20 \
--with-ssl=SYSTEM

Además pueden indicarse desde la misma línea de órdenes otros parámetros de la configuración
de Apache. Un ejemplo completo podría ser:

# cd mod_ssl-2.8.4-1.3.20
# ./configure --with-apache=../apache_1.3.20 \
--with-ssl=SYSTEM \
--prefix=/usr/local/proyecto/apache_ssl \
--enable-module=most \
--enable-shared=max \
--htdocsdir=/usr/local/proyecto/htdocs/ \
--cgidir=/usr/local/proyecto/cgi-bin/ \
--sysconfdir=/usr/local/proyecto/conf_ssl/ \
--logfiledir=/usr/local/proyecto/logs/ \
--enable-suexec \
--suexec-caller=apache \
--suexec-logfile=/usr/local/proyecto/logs/suexec_log

En pantalla irán apareciendo diversos mensajes, entre ellos los que indican que los parches han
sido aplicados y como se debe continuar con la instalación:

Configuring mod_ssl/2.8.4 for Apache/1.3.20

+ Apache location: ../apache_1.3.20 (Version 1.3.20)
+ OpenSSL location: SYSTEM
+ Auxiliary patch tool: ./etc/patch/patch (local)
3 Para este proyecto se utilizó el paquete de OpenSSL que venía instalado por defecto en el sistema, por eso el valor

de este parámetro es SYSTEM.

272 CAPÍTULO 18. CONFIGURAR CONEXIONES SEGURAS EN APACHE SOBRE SSL

+ Applying packages to Apache source tree:

o Extended API (EAPI)
o Distribution Documents
o SSL Module Source
o SSL Support
o SSL Configuration Additions
o SSL Module Documentation
o Addons
Done: source extension and patches successfully applied.

--- Omitimos más líneas ---

Now proceed with the following commands:

$ cd ../apache_1.3.20
$ make
$ make certificate
$ make install

Listado 18.1 Configurando mod_ssl. Resultado de ./configure .

18.4.3 Instalar Apache

Una vez la configuración ha concluido, se cambia al directorio que contiene el código árbol de
instalación de Apache y se construye el software de la manera habitual:

# cd ..
# cd apache_1.3.20
# make
--- Omitimos varias líneas ---
| % make certificate TYPE=dummy (dummy self-signed Snake Oil cert) |
| % make certificate TYPE=test (test cert signed by Snake Oil CA) |
| % make certificate TYPE=custom (custom cert signed by own CA) |
| % make certificate TYPE=existing (existing cert) |
| CRT=/path/to/your.crt [KEY=/path/to/your.key] |
--- Omitimos varias líneas ---

Tras ejecutar make, se informa en pantalla de cual es el siguiente paso a seguir. El objetivo es
construir un certificado para el servidor4 . Con objeto de poder probar el software, mod_ssl permite
4 Una de las características de SSL es la necesidad de certificados para el servidor (vea la sección 5.2.2 en la página
79).
18.5. REVISANDO LA CONFIGURACIÓN 273

firmar el certificado generado mediante una CA (Autoridad Certificadora) ficticia llamada Snake
Oil CA. Para un servidor real en explotación debería reemplazarse este certificado de prueba con
otro expedido (y pagado) en una autoridad certificadora real, como Verisign [125] o Thawte [121].
El certificado se construye de manera sencilla mediante la siguiente orden:

# make certificate TYPE=test

El programa de instalación irá haciendo preguntas y realizará las actuaciones necesarias. A

continuación se resumen los pasos necesarios:

Elegir algoritmo de PKI (clave pública) para uso con los certificados X.509, ¿RSA o DSA?
Por defecto se elige RSA.


Generar claves según algoritmo elegido. server.key será la clave privada.



Introducir datos del servidor (URL, nombre de empresa, etc.) para crear una solicitud de
certificado X.509 que luego podrá ser enviada a una autoridad certificadora real. El archivo
generado se llama server.csr.


Obtener certificado X.509 v3 de prueba (no válido para uso en explotación real), firmado
por la entidad certificadora local. El archivo se llama server.crt.


La clave privada server.key, para mayor seguridad, puede ser encriptada usando triple
DES. Si hacemos esto alguien deberá escribir la frase de paso cada vez que se quiera arrancar
el servidor.

Una vez se dispone de un certificado, sólo queda acabar la instalación de Apache de la manera
habitual. Si todo va bien, el servidor Web Apache estará preparado para servir peticiones sobre
SSL:

# su
# make install

18.5 Revisando la configuración

El método de instalación elegido, modifica el archivo de configuración estándar (httpd.conf),

realizando por nosotros los añadidos necesarios. Además crea varios subdirectorios:

ssl.crl : contiene archivos de lista de revocación de certificados X.509 (CRL, Certificate

Revocation Lists).

ssl.crt : contiene los certificados digitales (servidor, entidad certificadora de prueba, etc.).
274 CAPÍTULO 18. CONFIGURAR CONEXIONES SEGURAS EN APACHE SOBRE SSL

ssl.csr : contiene la petición de firma de certificado X.509 (CSR, Certificate Signing Requests),
listos para ser enviados a una CA real (como Verisign por ejemplo).

ssl.key : contiene las claves privadas RSA (servidor, entidad certificadora de prueba, etc.)
generalmente encriptadas con Triple DES.

ssl.prm : si durante la creación del certificado se ha seleccionado usar el algoritmo DSA, en este
directorio se almacenarán ficheros de parámetros para este algoritmo.

Todas las directivas proporcionadas por mod_ssl se enmarcan en secciones condicionales

<IfDefine>. De esta manera se permite que el mismo fichero httpd.conf se refiera en realidad a
dos configuraciones distintas (una con soporte SSL y otra sin él). Se utilizará una u otra en función
de la orden de arranque.

Algunas de las directivas de Apache relacionadas con SSL más importantes se comentan a
continuación:

Las primeras en aparecer son las que indican a Apache que cargue el módulo necesario para SSL:

<IfDefine SSL>
LoadModule ssl_module libexec/libssl.so
</IfDefine>

<IfDefine SSL>
AddModule mod_ssl.c
</IfDefine>

A continuación se definen los puertos por defecto en los que escuchará el servidor, el puerto 443
es el estándar para recibir peticiones SSL (puerto HTTPS por defecto):

<IfDefine SSL>
Listen 80
Listen 443
</IfDefine>

Finalmente se crea un nuevo servidor virtual que responderá a las peticiones realizadas al puerto
443. En su versión más básica podría tener este aspecto5 :

<IfDefine SSL>

<VirtualHost _default_:443>
DocumentRoot "/usr/local/proyecto/htdocs"
5 Esta parte de la configuración, en realidad, aparece muy documentada e indica exactamente que hace cada directiva.
18.5. REVISANDO LA CONFIGURACIÓN 275

ServerName montsfortis.micasa.es
ServerAdmin txapi@montsfortis.micasa.es
ErrorLog /usr/local/proyecto/logs/error_log
TransferLog /usr/local/proyecto/logs/access_log

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH
:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /usr/local/proyecto/conf_ssl/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/proyecto/conf_ssl/ssl.key/server.key

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/usr/local/proyecto/cgi-bin">
SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent ".*MSIE.*" \

nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog /usr/local/proyecto/logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>

</IfDefine>

Listado 18.2 Configuración de un host virtual para manejar SSL.

Como directivas más interesantes de este listado se pueden enumerar6 :

SSLEngine: habilita el soporte SSL.

SSLCipherSuite: lista de métodos de cifrado que el servidor permite para negociación con
el cliente.

SSLCertificateFile: localización del certificado para este servidor.

6 La documentación completa de las directivas está disponible en http://www.modssl.org/docs/ssl_

reference.html
276 CAPÍTULO 18. CONFIGURAR CONEXIONES SEGURAS EN APACHE SOBRE SSL

SSLCertificateKeyFile: localización de la clave privada del servidor.



SSLOptions: al estilo de la directiva de Apache Options. Establece varias opciones

de funcionamiento del motor SSL (habilita ciertas variables de entorno, posibilidad de
renegociación SSL, etc.).

18.6 Probando una conexión

18.6.1 Arranque del servidor

EL servidor recién instalado puede arrancarse de dos formas:

Modo de ejecución normal: se utiliza la siguiente orden para iniciar un servidor HTTP
estándar (sin soporte SSL) escuchando en el puerto 80:

# /usr/local/proyecto/apache_ssl/bin/apachectl start

Modo de ejecución con SSL: si se quiere que el servidor soporte transacciones “seguras”
tendremos que ser arrancado mediante alguno de las siguientes órdenes (ambas son
equivalentes):

# /usr/local/proyecto/apache_ssl/bin/apachectl startssl
o
# /usr/local/proyecto/apache_ssl/bin/httpd -DSSL

18.6.2 Los clientes

Figura 18.4: Estableciendo una sesión HTTPS.

18.6. PROBANDO UNA CONEXIÓN 277

Varios son los navegadores (clientes) que ofrecen soporte para conexiones SSL (Netscape
Navigator, Microsoft Internet Explorer, Opera, etc.). Desde cualquiera de ellos puede visitarse
un sitio “seguro” notando el usuario sólo un par de diferencias respecto a la navegación habitual:

El formato de la URL comienza por https, de esta manera la petición se envía

automáticamente al puerto 443 del servidor, encargado de atender peticiones sobre SSL.

https://localhost/

Aparecen algunas ventanas de diálogo que advierten de la entrada/salida del sitio “seguro”
y presentan información sobre el certificado del servidor (figura 18.4).
278 CAPÍTULO 18. CONFIGURAR CONEXIONES SEGURAS EN APACHE SOBRE SSL
Capítulo 19

Personalizar el registro y recopilar

estadísticas

Contenidos de este capítulo

19.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
19.2 Configuración estándar para ficheros de log Apache . . . . . . . . . . . . . 280
19.3 Personalizando los métodos de registro de información . . . . . . . . . . . 280
19.3.1 Variables de formato . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
19.3.2 Logging a varios ficheros . . . . . . . . . . . . . . . . . . . . . . . . . 282
19.3.3 Logging condicional . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
19.3.4 Logging con servidores virtuales . . . . . . . . . . . . . . . . . . . . . 282
19.3.5 Logging mediante canalizado. Un ejemplo: Cronolog . . . . . . . . . . 283
19.4 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
19.5 Recopilación de estadísticas. Un ejemplo: Analog . . . . . . . . . . . . . . 286
19.5.1 Instalando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
19.5.2 Configurando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
19.5.3 Ejecutando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

19.1 Introducción

Varios son los métodos que los servidores Web pueden utilizar para llevar un registro las
operaciones que se le solicitan (vea la sección 9 en la página 125). En este capítulo se explica
como configurar adecuadamente el servicio de log de Apache y como personalizarlo según las
necesidades particulares. También se presentan los métodos de instalación, configuración y uso
de un par de herramientas relacionadas:


Cronolog: para rotación de ficheros de registro.



Analog: para recopilar estadísticas.

279
280 CAPÍTULO 19. PERSONALIZAR EL REGISTRO Y RECOPILAR ESTADÍSTICAS

19.2 Configuración estándar para ficheros de log Apache

Apache incluye por defecto un módulo de log bastante potente: config_log_module1 . Este
proporciona varias funcionalidades interesantes:

Soporte básico al registro de peticiones HTTP.



Almacena líneas de información con formato personalizado.



Habilita la escritura tanto a fichero como a programas externos mediante tuberías (pipe).


Logging condicional en función de las características de la conversación HTTP.

En una configuración por defecto de Apache suelen aparecer una serie de líneas que afectan al
registro, todas ellas usan directivas que han sido comentadas en un capítulo anterior (vea la sección
11.9 en la página 195):

# Deshabilitar busqueda DNS

HostNameLookups off

# Indicar localización de fichero de errores

ErrorLog /usr/local/proyecto/apache/logs/error_log

# Indicar nivel de detalle del log

LogLevel warn

# Establecer nombres para distintos formatos de log habituales

LogFormat "%h %l %u %t \"%r\" %>s %b" common

# Indicar localización y formato de fichero de accesos

CustomLog /usr/local/proyecto/apache/logs/access_log common

19.3 Personalizando los métodos de registro de información

19.3.1 Variables de formato

En la tabla (tabla 19.1) se recogen las variables de formato que pueden ser utilizadas con la
directiva LogFormat (vea la sección 11.9.2 en la página 198).

Algunos ejemplos interesantes de configuración utilizando estas variables son:

1 Esteno es el único módulo que ofrece capacidades de registro, hay módulos específicos con características de log
propias (aunque no se comentan en este capítulo). Por ejemplo mod_cgi proporciona soporte extendido al registro de
procesos CGI.
19.3. PERSONALIZANDO LOS MÉTODOS DE REGISTRO DE INFORMACIÓN 281

Variable Significado
%{variable}e Contenido de la variable de entorno especificada.
%{header}i Contenido de la línea de encabezado HTTP de petición “header”.
%{header}o Contenido de la línea de encabezado HTTP de respuesta “header”.
%{nota}n Contenido de la nota “nota” proporcionada por otro módulo de Apache.
%{formato}t Hora especificada en el formato indicado. El formato es el mismo que
utiliza la función strftime 2 .
%a Dirección IP.
%b Número de bytes enviados al cliente (sin encabezados HTTP).
%f Nombre de archivo solicitado por cliente.
%h Dirección IP del cliente o nombre completamente cualificado de la
máquina si HostNameLookups está activado.
%l Nombre de cliente remoto, contendrá valores tal y como se especifica en el
rfc1413 [92].
%p Puerto que escucha el servidor que ha atendido la solicitud. Puede ser útil
en servidores que alojan varios servidores virtuales.
%P Id del proceso secundario que atiende la solicitud.
%r Primera línea de la solicitud. generelmente incluyendo método de acceso,
URL y versión de protocolo.
%s Estado de respuesta. En solicitudes que se han redirigido internamente, por
ejemplo algún estado de la serie 300 (vea la sección 2.2.3 en la página 24),
es el estado de la solicitud original. Si queremos obtener el estado de la
última solicitud (esto es lo más habitual), utilizaremos %>s.
%t Hora en el formato espedificado por el formato común de registro.
%T Tiempo en segundos dedicados a atender la solicitud.
%u Nombre de usuario proporcionado para conseguir acceso a secciones del
Web protegidas con “nombe de usuario - contraseña.”
%U Ruta URL de la petición.
%v Nombre del servidor que atiende la solicutud.

Tabla 19.1: Variables de formato para log.

Registro combinado : añade información sobre el agente de usuario y remitente al formato

común de registro (vea la sección 9.2.1 en la página 126).

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"

\"%{User-Agent}i\"" combined

Registro de remitente : el remitente (referer) es la anterior URL que ha visitado un cliente que en
este momento accede a nuestro servidor. El formato de registro que aparece a continuación
permite almacenar líneas con información del remitente y cual es la URL que está visitando
en nuestro servidor:

LogFormat "%{Referer}i -> %U" referer

Registro de tipos de contenido : este formato permite almacenar información sobre el tipo de
contenido que el servidor envía como respuesta a una petición del cliente:
282 CAPÍTULO 19. PERSONALIZAR EL REGISTRO Y RECOPILAR ESTADÍSTICAS

LogFormat "%{Content-type}o" tiposenviados

19.3.2 Logging a varios ficheros

Añadir campos extra al common log format (como en el caso del formato combined) puede no ser
muy deseable. Un ejemplo es cuando se dispone de un software de análisis de registro que sólo es
capaz de analizar ficheros en formato común. En casos como este, ¿perdemos información? No,
Apache permite crear cualquier número de ficheros de log en formatos diferentes.
Es habitual tener un fichero para el formato común y otros ficheros independientes para otros
datos significativos como por ejemplo el agente de usuario, el remitente y el idioma de elección
del cliente:

LogFormat "%h %l %u %t \"%r\" %>s %b" common

LogFormat "%{accept-language}i" language
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

CustomLog /usr/local/proyecto/apache/logs/access_log common

CustomLog /usr/local/proyecto/apache/logs/agent agent
CustomLog /usr/local/proyecto/apache/logs/referer referer
CustomLog /usr/local/proyecto/apache/logs/language language

19.3.3 Logging condicional

También es posible indicar formatos de log personalizados que dependan de una condición. De
esta forma se registra la información de manera condicional atendiendo al estado de respuesta. Por
ejemplo:

# Registra el idioma solo para peticiones con estado de respuesta 200

LogFormat "%200{accept-language}i" lang
CustomLog /usr/local/proyecto/apache/logs/lang200_log lang

# Registra el agente de usuario si la petición no es respondida con

# estado 200
LogFormat "%!200{User-agent}i" agent
CustomLog /usr/local/proyecto/apache/logs/agent_no_200_log agente

19.3.4 Logging con servidores virtuales

Cuando se alojan varios servidores virtuales resulta interesante poder guardar registro de la
actividad que genera cada uno. Para ello Apache permite utilizar dos técnicas:
19.3. PERSONALIZANDO LOS MÉTODOS DE REGISTRO DE INFORMACIÓN 283

1. Incluir directivas personalizadas (del tipo CustomLog, TransferLog, ErrorLog) dentro de

las secciones <VirtualHost>. Por ejemplo:

<VirtualHost 193.147.87.211>
--- Omitimos varias líneas ---

ErrorLog /usr/local/apache/logs/virtual1/error_log
CustomLog /usr/local/apache/logs/virtual1/combined_log combined
</VirtualHost>

2. No incluir directivas de log en las secciones <VirtualHost>. En este caso el tráfico del
servidor virtual será registrado en el archivo de log del servidor primario. ¿Pero como se
distingue el tráfico de los distintos servidores virtuales? La solución es incluir el modificador
de formato %v (que indica el nombre del servidor) en el formato de log para el servidor
principal. Por ejemplo:

LogFormat "Servidor %v Petición %h %l %u %t \"%r\" %>s %b" hostvirtual

19.3.5 Logging mediante canalizado. Un ejemplo: Cronolog

Con las directivas que especifican la ubicación de registro (CustomLog, TransferLog y

ErrorLog) es posible no indicar un fichero, sino algún proceso al que canalizar (pipe) los datos.
Es muy habitual utilizar esta característica para proporcionar rotación en los logs (vea la sección
9.3.2 en la página 130).

Un ejemplo: Cronolog

Un programa de rotación de logs muy utilizado es cronolog [34]. Se comentará brevemente

como instalarlo y configurarlo para su uso con Apache. En primer lugar se obtiene el fichero
de instalación en el sitio Web http://www.ford-mason.co.uk/resources/cronolog/. En el
momento que se escribe este capítulo el fichero con el código fuente es cronolog-1.6.1.tar.gz.

Instalando

Se copia el fichero comprimido a un directorio temporal de instalación y se descomprime:

# mv cronolog-1.6.1.tar.gz /usr/local/proyecto/src/
# cd /usr/local/proyecto/src/
# gzip -c -d cronolog-1.6.1.tar.gz | tar -xvf -
284 CAPÍTULO 19. PERSONALIZAR EL REGISTRO Y RECOPILAR ESTADÍSTICAS

Se cambia la ubicación hasta el directorio al raíz del árbol de instalación que se ha creado y se
instala siguiendo el método habitual3 :

# cd cronolog-1.6.1
# ./configure --prefix=/usr/local/proyecto/cronolog
# make
# su
# make install

La instalación crea subdirectorios dentro de la ruta indicada por el parámetro --prefix. Hay dos
subdirectorios que contienen la información del paquete instalado (/info y /man) y otro con los
ejecutables (/sbin).

Utilidades proporcionadas

Cronolog proporciona dos programas que se explican brevemente a continuación4 :

cronosplit: es un pequeño programa suplementario que divide grandes ficheros de log

(probablemente generados antes de instalar el paquete cronolog) en partes más pequeñas.
Lee líneas de ficheros en el common log format y las escribe a ficheros distintos según los
datos de fecha y hora emparejen con un patrón5 pasado por parámetro.


cronolog: se encarga de leer mensajes de log generados directamente desde Apache y

escribirlos en los ficheros adecuados según la fecha y hora empareje con un modelo
especificado.

Configurando el log en Apache con cronolog

Cronolog puede configurarse para su uso conjunto con Apache mediante canalizado de registros.
En el fichero httpd.conf deberán aparecer las siguientes directivas6 :

CustomLog "|/usr/local/proyecto/cronolog/sbin/cronolog
--symlink=/usr/local/proyecto/logs/combined_log
/usr/local/proyecto/logs/%Y/%m/combined_log" combined

ErrorLog "|/usr/local/proyecto/cronolog/sbin/cronolog
--symlink=/usr/local/proyecto/logs/error_log
/usr/local/proyecto/logs/%Y/%m/error_log"
3 Más información en la documentación que acompaña la instalación.
4 Sinecesita más información puede leer las página de man.
5 Según el formato especificado por la función date de Unix.
6 Cada directiva debe ocupar exactamente una línea aunque por claridad se presentan en tres.
19.4. COOKIES 285

Con las líneas de configuración anteriores se establece a donde envía Apache los datos de log,
lo que cambia respecto a una configuración basada en ficheros es la orden que aparece entre las
comillas. Su significado es el siguiente:

| : la barra vertical indica que los datos de log no se van a enviar a un fichero, sino a un pipe
hacia un programa.


/usr/local/proyecto/cronolog/sbin/cronolog: es la ruta donde reside el programa

cronolog. A este se le pueden pasar algunos parámetros:

– --symlink: para mantener un enlace simbólico desde la ubicación habitual del fichero
(/usr/local/proyecto/logs/combined_log) al lugar donde reside el fichero
actual que cronolog maneja (/usr/local/proyecto/logs/%Y/%m/combined_log).
– %Y/%m/combined_log: es un patrón que se incluye en el nombre del fichero. Indica
el modelo temporal según el que se particiona el fichero de log. En este caso, se crean
ficheros distintos para cada mes que son almacenados en una estructura de directorios
según el año (%Y) y el mes (%m).

combined: aparece como último parámetro de la directiva CustomLog e indica cuál es el

formato en el que se pasan las líneas de log.

19.4 Cookies

Apache provee por defecto un módulo para la gestión de cookies (mod_usertrack), este permite
manejar los encabezados HTTP relacionados con las cookies, como por ejemplo Set-Cookie:

Set-Cookie: nombre=id_único; expires=fecha;path=URl_origen;

[domain=nombre_de_dominio;] [secure]

La utilización es fácil, basta con añadir la directiva CookieTracking On para que se generen
cookies en cada nueva petición en el ámbito de visibilidad de la directiva. Un ejemplo completo
sería:

CookieTracking On
CookieName cookieejemplo
CookieExpires "2 weeks"

Y el encabezado generado incluiría una línea del estilo:

Set-Cookie: cookieejemplo=127.0.0.1.2423995998374189; path=/;

expires=Tue, 07-Aug-01 18:12:53 GMT
286 CAPÍTULO 19. PERSONALIZAR EL REGISTRO Y RECOPILAR ESTADÍSTICAS

Aunque Apache permite el manejo de cookies, suele ser más cómodo utilizarlas desde el propio
código HTML utilizando alguna tecnología añadida. Un buen ejemplo es Client side JavaScript7 ,
un lenguaje de script que puede ser utilizado desde dentro de un documento HTML y es
interpretado en el cliente. Un código típico para el manejo de cookies desde JavaScript es el
siguiente:

//Establecer una cookie

function setCookie(name, value, expire) {
document.cookie = name + "=" + escape(value)
+((expire == null) ? "" : ("; expires="
+ expire.toGMTString()))
}

//Recuperar una cookie

function getCookie(Name) {
var search = Name + "="
if (document.cookie.length > 0) {
offset = document.cookie.indexOf(search)
if (offset != -1) {
offset += search.length
end = document.cookie.indexOf(";", offset)
if (end == -1)
end = document.cookie.length
return unescape(document.cookie.substring(offset, end))
}
}
}

Listado 19.1 Crear una cookie con JavaScript.

19.5 Recopilación de estadísticas. Un ejemplo: Analog

En este apartado se explica brevemente como instalar y configurar Analog (vea la sección
9.3.1 en la página 128), una herramienta de análisis de log muy extendida. Se obtiene
el fichero de instalación en el sitio http://www.analog.cx/, existen diversos formatos de
paquete y código fuente. Para este proyecto se utilizará el código fuente incluido en el fichero
analog-5.03.tar.gz.
7 Una explicación completa de Javascript del lado cliente puede encontrarse en la Web de Netscape [80].
19.5. RECOPILACIÓN DE ESTADÍSTICAS. UN EJEMPLO: ANALOG 287

19.5.1 Instalando

Se copia el fichero comprimido a un directorio temporal de instalación y se descomprime:

# mv analog-5.03.tar.gz /usr/local/proyecto/src/
# cd /usr/local/proyecto/src/
# gzip -c -d analog-5.03.tar.gz | tar -xvf -

Antes de ejecutar make se puede editar el fichero src/anlghead.h para modificar algunas
opciones por defecto, aunque no es necesario ya que una vez instalado el programa también
pueden ser modificadas en el fichero de configuración estándar analog.cfg8 . Para continuar
con la instalación se ejecuta:

# cd analog-5.03
# make
# make clean

Para acabar solo queda mover todo el árbol de instalación (que contendrá el ejecutable analog,
fichero de configuración básico analog.cfg, y archivos auxiliares para presentación de resultados
vía Web) a la localización final del programa:

# cd ..
# mv analog-5.03 /usr/local/proyecto/analog
# cd /usr/local/proyecto/analog

19.5.2 Configurando

Analog es muy configurable, de hecho esta es una de sus mayores virtudes. Ejecutando ./analog
-settings se obtiene un listado completo de las opciones de configuración.

Configuración estándar

La manera más simple de configurar Analog es editar a mano el fichero analog.cfg. La sintaxis
y significado de todas las directivas está bien explicado tanto en los comentarios del propio
fichero, como en la documentación que acompaña al programa (directorio /docs). Algunas de
las directivas más importantes se muestran en la tabla (tabla 19.2).
8 Más información en la documentación que acompaña la instalación, en el directorio /docs.
288 CAPÍTULO 19. PERSONALIZAR EL REGISTRO Y RECOPILAR ESTADÍSTICAS

Directiva Significado
HOSTNAME Nombre del host que se analiza.
HOSTURL URL del host que se analiza.
LOGFILE Fichero de log que contiene los datos a analizar.
OUTFILE Nombre de fichero donde se volcarán los resultados.
LANGUAGE Idioma de presentación.
OUTPUT Formato de salida (ascii o html).
CONFIGFILE Fichero de configuración a incluir.

Tabla 19.2: Algunas directivas de configuración de Analog.

Un ejemplo de configuración adecuada para servidores virtuales

El uso adecuado de la directiva CONFIGFILE permite realizar una configuración muy flexible y
adecuada para su uso con múltiples servidores virtuales. Una posibilidad es dividir el fichero de
configuración estándar en tres:

SearchQuery.cfg: utilizado en los informes que recopilan información de los remitentes. Los
remitentes generalmente son buscadores, este fichero contiene líneas que permiten extraer
la información relevante de las cadenas de búsqueda:

#Search Engine Configuration list for Analog

# Page last modified: 06-March-2001
# This list is maintained for Analog Log File Analyzer by
# Dr. Stephen Turner (http://www.analog.cx/)
# These REFALIAS lines assign a standard name to related
# search engine URLs
#===========================================================
REFALIAS http://*alltheweb.com/* http://www.alltheweb.com/$2
REFALIAS http://204.152.166.43/* http://www.mamma.com/*
--- Omitimos muchas líneas ---

# Search engine query terms

#===========================================================
SEARCHENGINE http://*.about.com/* terms
SEARCHENGINE http://*.dogpile.com/* q
--- Omitimos muchas líneas ---

Listado 19.2 Ejemplo de configuración de Analog con 3 ficheros. SearchQuery.cfg.

analoggeneral.cfg: contendrá directivas generales para todos los servidores virtuales (por
ejemplo la directiva LANGUAGE):
19.5. RECOPILACIÓN DE ESTADÍSTICAS. UN EJEMPLO: ANALOG 289

# Configuration file for analog

# See http://www.analog.cx/

# Habilita todos los informes

# ===========================================
ALL ON
WARNINGS OFF

# Lenguage por defecto

# ===========================================
LANGUAGE SPANISH

# Parametros de formateo de la salida html

# ===========================================
# Podemos añadir un fichero de cabecera
#HEADERFILE /usr/local/proyecto/analog/images/cabecera.htm

# Podemos añadir un fichero de pie

#FOOTERFILE /usr/local/proyecto/analog/images/pie.htm

# Podemos añadir una hoja de estilo

#STYLESHEET /analogwww/analog.css

IMAGEDIR /analogwww/
LOGO none

# ¿Resuelve? nombres con nslookup (esto es muy lento)

# ===========================================
DNS none

# Si ponemos lo siguiente si se usa nslookup

#DNS write
#DNSFILE /usr/local/proyecto/analog/dnsfile.dat

# Incluye: Enlaces en paginas, ...

# ===========================================
LINKINCLUDE pages
REFLINKINCLUDE *

# Si el log esta comprimido lo descomprime

# ===========================================
290 CAPÍTULO 19. PERSONALIZAR EL REGISTRO Y RECOPILAR ESTADÍSTICAS

UNCOMPRESS *.gz,*.Z "gzip -cd"

# Permite informes jerarquicos por organizaciones a varios niveles

# ===========================================
SUBBROW */*.*
SUBTYPE *.gz,*.Z

# Parametros en busquedas que traen a nuestro sitio

# ===========================================
CONFIGFILE SearchQuery.cfg

# Alias de salidas de extensiones

# ===========================================
TYPEOUTPUTALIAS .html ".html [Hypertext Markup Language]"
TYPEOUTPUTALIAS .htm ".htm [Hypertext Markup Language]"
--- Omitimos muchas líneas ---

Listado 19.3 Ejemplo de configuración de Analog con 3 ficheros. analoggeneral.cfg.

analog.cfg: sustituye al fichero de configuración por defecto, habrá uno distinto con
directivas específicas para cada servidor virtual (por ejemplo HOSTNAME).

# Configuration file for analog

# See http://www.analog.cx/

CONFIGFILE /usr/local/proyecto/analog/analoggeneral.cfg

# Parametros del servidor

#========================
HOSTNAME "[Esc. Sup. Enxeñería Informática]"
HOSTURL http://www.ei.uvigo.es

# Ficheros de log de lectura y de informe de resultado

#=====================================================
LOGFILE /usr/local/proyecto/logs/combined_log
LOGFILE /usr/local/proyecto/logs/error_log
OUTFILE /usr/local/proyecto/htdocs/analog/actual_esei.html

Listado 19.4 Ejemplo de configuración de Analog con 3 ficheros. analog.cfg.

19.5. RECOPILACIÓN DE ESTADÍSTICAS. UN EJEMPLO: ANALOG 291

19.5.3 Ejecutando

Para proceder al análisis simplemente se ejecuta el programa ./analog, este lee los ficheros de
configuración preparados en la sección anterior y recorre los logs generando informes. Tras un
tiempo, que dependerá del tamaño de los ficheros a analizar, se obtiene el resultado (en formato
HTML o ASCII, dependiendo de la directiva OUTPUT). La ubicación de los informes será la
indicada por la directiva OUTFILE. Caso de haber generado la salida HTML el resultado podría
ser visualizado desde cualquier navegador (figura 19.1).

Figura 19.1: Salida generada por Analog.

292 CAPÍTULO 19. PERSONALIZAR EL REGISTRO Y RECOPILAR ESTADÍSTICAS
Capítulo 20

Otros módulos y tecnologías

relacionadas

Contenidos de este capítulo

20.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

20.2 Balanceo de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
20.3 Control de ancho de banda . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
20.4 Detección de intrusos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
20.5 Integración con Corba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
20.6 Proxy / caché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
20.7 Redundancia y tolerancia a fallos . . . . . . . . . . . . . . . . . . . . . . . 296
20.8 Reescritura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
20.9 Soporte a pago electrónico . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
20.10Interfaces de administración gráfica . . . . . . . . . . . . . . . . . . . . . . 297
20.11Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

20.1 Introducción

Apache, gracias a su construcción basada en módulos, es extremadamente extensible. Las

características pueden ser añadidas o eliminadas sin la necesidad de recompilar el servidor. En los
capítulos anteriores se han comentado algunas de las funcionalidades más importantes: ejecución
de programas (CGI, etc.), lenguajes embebidos (PHP, JSP, etc.), log, autenticación, etc.

Pero existen otros módulos [17] que le permiten al servidor realizar las más variadas tareas, una
lista bastante completa puede obtenerse en http://modules.apache.org. En este capítulo no se
describirán todos en profundidad1 , sino que sólo se hará un breve comentario de algunos módulos
1 Describir todos los módulos de Apache podría ser objeto por si sólo de un libro de bastantes hojas. A fecha de

escritura de este capítulo había más de 175 módulos en el listado de http://modules.apache.org.

293
294 CAPÍTULO 20. OTROS MÓDULOS Y TECNOLOGÍAS RELACIONADAS

interesantes que le permitirán al lector hacerse una idea más clara de la potencia de Apache.
Asimismo también se dedica un punto a las interfaces gráficas de administración, que aunque no
son módulos de Apache propiamente dichos, se consideran lo suficientemente importantes como
para mencionarlas.

20.2 Balanceo de carga

mod_backhand [69] es un módulo que proporciona una solución para realizar redirecciones HTTP
dentro de un cluster de servidores Web, basándose en las peticiones. Esta utilidad permite
construir políticas de balanceo de carga entre máquinas, consiguiendo un mejor aprovechamiento
de los recursos infrautilizados.

La redirección se basa en los recursos disponibles dentro del cluster, el propio módulo se encarga
de anunciarlos mediante difusiones ethernet. Una vez conocidos los recursos, se puede activar
la redirección en base a directorios o localizaciones de Apache. El módulo será capaz de
preservar de manera transparente la información del host remoto para acceso y autenticación,
independientemente del equipo del cluster que responda. Hay más información disponible es
http://www.backhand.org/.

20.3 Control de ancho de banda

Actualmente en http://modules.apache.org existen varios módulos que permiten controlar

que el ancho de banda consumido por un cliente. Cada uno tiene sus particularidades, pero en
general todos controlan el número de conexiones establecidas desde una IP, verificando que no sea
exagerado.

mod_throttle [73] es el módulo que parece ofrecer un conjunto de funcionalidades más completo
(está disponible en http://www.snert.com/Software/mod_throttle/). Para conseguir
controlar el ancho de banda consumido, este módulo monitoriza la dirección IP del cliente y
el nombre de usuario remoto. Además permite implantar limitaciones atendiendo a distintas
políticas. De esta manera se puede limitar el ancho de banda consumido en cada sección de
Apache (<VirtualHost>, <Directory>, <Location>), o en las peticiones de acceso de distintos
usuarios.

20.4 Detección de intrusos

Varias son las opciones que se encargan de detectar y/o corregir la actuación de intrusos en el
servidor:
20.5. INTEGRACIÓN CON CORBA 295

Intrusion Detection Module: [52] es una herramienta sencilla que analiza en tiempo real las
peticiones de clientes e intenta determinar los intentos de intrusión. Más información en
http://yunus.hacettepe.edu.tr/~burak/mod_id/


Covalent Intrusion Detector: [33] es otra aproximación a la detección de intrusos, se basa en

intentar evitar la mala imagen que da una página hackeada. Intrusion Detector monitoriza
todos los datos que van a ser servidos y reemplaza cualquier contenido que aparente haber
sido modificado sin permiso, notificando la situación al administrador del Web. Más
información en http://www.covalent.net/products/intrusiondetector/.

20.5 Integración con Corba

ModCBroker [74] es un módulo de Apache que permite la construcción de interfaces Web para
aplicaciones CORBA. Implementa una traducción transparente de peticiones HTTP, de esta forma,
las interfaces Web se integran fácilmente con los sistemas de información empresariales basados
en CORBA.

Varios son los beneficios de este enfoque:

Reducción del tiempo de administración.



Manejo de peticiones HTTP relacionadas sin la sobrecarga de CGIs.



...

ModCBroker está escrito en C/C++, las aplicaciones CORBA pueden estar escritas en cualquier
lenguaje con soporte CORBA. El software está disponible en http://www.gradsoft.com.ua/
eng/Products/cbroker/cbroker.html

20.6 Proxy / caché

Apache proporciona mod_proxy que incluye la funcionalidad necesaria para que el servidor
funcione como un proxy/caché2 . Soporta la funcionalidad necesaria para HTTP/0.9, HTTP/1.0
y FTP. Además usando el método CONNECT también se pueden implantar operaciones de proxy
mediante tuneling de otros puertos (443 para SSL, 563 para Snews, etc.). Este módulo se distribuye
con Apache, aunque no se habilita por defecto.

mod_proxy es válido para la mayoría de los administradores debido a su eficiencia y robustez, pero
es básicamente un proxy HTTP. Para aquellos que necesitan implantar un servicio proxy/caché
más general, es recomendable utilizar un servidor específico para estas tareas. Una buena solución
en Squid (http://www.squid-cache.org) un servidor proxy Open-Source muy extendido.
2 En un capítulo anterior (vea la sección 2.3.5 en la página 32) se comenta algo más de lo que es un proxy/caché.
296 CAPÍTULO 20. OTROS MÓDULOS Y TECNOLOGÍAS RELACIONADAS

20.7 Redundancia y tolerancia a fallos

El módulo mod_redundancy [71] implementa la tolerancia a fallos y consigue que Apache

tenga una alta disponibilidad. Utiliza un esquema maestro/esclavo de manera que los esclavos
monitorizan el servidor principal y son capaces de asumir las funciones del mismo en caso de
fallos. Actualmente este proyecto está detenido a la espera de algún patrocinador, de todas maneras
existen versiones disponibles en http://www.ask-the-guru.com/.

20.8 Reescritura

Apache sirve los recursos considerando que la URL de la petición representa un path relativo a
DocumentRoot. Pero esta suposición no siempre es cierta, hay ocasiones en las que los recursos
de almacenan en ubicaciones no estándar. Para ello Apache ofrece dos funcionalidades básicas:

mod_alias: es un módulo relativamente simple y de pequeño tamaño. Se encarga de

hacer una correspondencia entre las URLs que se le solicitan al servidor y la ubicación del
recurso relacionada. Las operaciones de alias son completamente transparentes y permiten
referenciar cualquier recurso dentro del mismo servidor. mod_alias se distribuye con
Apache, se instala por defecto y sus características son suficientes para la mayoría de los
servidores. Las directivas de este módulo han sido analizadas en un capítulo anterior (vea la
sección 11.7 en la página 181).


mod_rewrite: implementa métodos de reescritura y redirección de URLs “al vuelo”:

– La reescritura se basa en reglas (expresiones regulares). La flexibilidad de las reglas

(condicionales, múltiples reglas para una operación simple, acceso a variables de
entorno) hacen de este módulo una herramienta muy poderosa.
– mod_rewrite es un módulo complejo que permite también la redirección. Redirección
es el proceso de responder a una petición con una nueva URL y un mensaje para que
el navegador se redirija a ella. Todas las redirecciones implican que el cliente debe
hacer una segunda solicitud para alcanzar el recurso. Existe una categoría completa de
códigos HTTP (3XX) que indican redirección.

mod_rewrite se distribuye con Apache pero no se instala por defecto ya que sus
características no suelen ser necesarias a la mayoría de los usuarios.

20.9 Soporte a pago electrónico

Una de las necesidades más demandadas por los usuarios del comercio electrónico es la posibilidad
de realizar pagos seguros a través de la red. Al menos un módulo de Apache CyPay [35], se encarga
de la gestión de transacciones monetarias.
20.10. INTERFACES DE ADMINISTRACIÓN GRÁFICA 297

CyPay, Inc., es una compañía que desarrolla software para comercio electrónico. En febrero de
2000 anunció que había desarrollado un módulo de comercio electrónico para Apache. El módulo
es capaz de manejar transacciones sobre SSL e incluye acceso integrado a los servicios de pago
electrónico que proporciona la empresa CyberSource (http://www.cybersource.com/, entre
ellos:

Autorización en tiempo real de las tarjetas de crédito.

Chequeo electrónico de pago.

Cálculos de tasas.

...

20.10 Interfaces de administración gráfica

Aunque cualquier buen administrador del sistema debe conocer las directivas de Apache y como
utilizarlas, esta no es razón para tener que realizar la configuración directamente editando archivos
de texto. El sitio Web http://gui.apache.org [15] centraliza los proyectos relacionados con
los GUIs para administración de Apache. Se comentan brevemente a continuación cuatro opciones
disponibles públicamente:

Comanche: COnfiguration MANager for apaCHE es una herramienta que funciona sobre el
sistema de ventanas X-Window y utiliza funciones Tcl/Tk. Existen versiones tanto
para Unix/Linux como NT. Más información es el sitio http://www.covalent.net/
projects/comanche/.

Mohawk: también funciona bajo X-Window, está escrito en C y se basa en las librerías gráficas
de GTK/Gnome. Más información es el sitio http://eunuchs.org/linux/Tkapache/.

Webmin: es una herramienta de administración de carácter general propiedad de Caldera. En

las distribuciones Linux de esta empresa es la herramienta de administración por defecto.
Webmin funciona sobre una interface Web y se basa en un sistema de módulos, cualquier
servidor puede ser administrado si se dispone del módulo correspondiente. Más información
es el sitio http://www.webmin.com/webmin/.

Linuxconf: es una herramienta de carácter general que se incluye en las distribuciones Linux de
Red Hat. Puede ser utilizado bajo distintos entornos: desde una consola en modo texto,
como una aplicación propia en una ventana X-Window o desde una interface Web. Esta
escrito en C y no necesita librerías especiales (salvo para la versión que funciona en X-
Window). Más información es el sitio http://www.solucorp.qc.ca/linuxconf/
298 CAPÍTULO 20. OTROS MÓDULOS Y TECNOLOGÍAS RELACIONADAS

20.11 Conclusión

Apache es el servidor Web más usado, quizá por ello muchas empresas y desarrolladores
particulares dedican sus esfuerzos a la creación de módulos que lo toman como base. Estos
módulos añaden prácticamente todas las funcionalidades imaginables, haciendo de Apache un
servidor Web aún mejor. La mayoría de los productos son software libre, aunque también hay
algunos de pago o incluso soluciones a medio camino donde se paga cierta cantidad en concepto
de soporte a la instalación.
 Parte III

Aplicación práctica 2:
Desplegando soluciones reales basadas
en Web

299
Una posible situación real

Hasta ahora hemos configurado un servidor con los servicios básicos y ciertas extensiones que
potencian su utilidad. Aunque seguro que hay personas3 a las que les llegue con tener un
“super servidor” con todo lo último funcionando para ser feliz, lo interesante es poder desplegar
aplicaciones reales. Actualmente existen multitud de aplicaciones que funcionan sobre la base
de servidores Web, y cada día aparecen más (debido a fenómenos como el boom del comercio
electrónico o la proliferación de las Intranets empresariales).

En esta parte se supone un caso práctico, el servidor Web de una Escuela de Informática
donde el lector es el administrador Web. Concretamente estamos en la Escuela de Informática
de la universidad llamada Universidad. El centro configura un “ecosistema” medianamente
complejo (profesores, alumnos, personal de administración y servicios, diversos departamentos
con docencia, áreas de conocimiento, administración, etc.), y como no, todo el mundo quiere
tener su información en Internet. Supondremos que se parte de “la nada”, es decir, que nadie
tiene ni siquiera una página Web, y que se va a crear un servidor en el que se gestionará toda la
información. A partir de aquí, y con el supuesto paso del tiempo van a surgir necesidades, tanto
de los usuarios como del propio administrador, que llevarán a reconfiguraciones en el servidor,
búsqueda e instalación de nuevos servicios4 , etc.

Sobre este ejemplo, y en lenguaje coloquial, en los siguientes capítulos se narrará la historia de la
evolución del servidor Web.

3 Quizá todo el gremio de administradores de sistemas.

4 Hay varias páginas es Internet que contienen múltiples aplicaciones Web open-source que podremos descargar y
utilizar en nuestro servidor [42] [119].

301
302
Capítulo 21

Primeros pasos

Contenidos de este capítulo

21.1 Definición del ejemplo: una Escuela de Informática . . . . . . . . . . . . . 303

21.2 Instalar y arrancar un servidor actualizado . . . . . . . . . . . . . . . . . . 304
21.3 Publicar la primera Web de la Escuela . . . . . . . . . . . . . . . . . . . . . 304
21.3.1 Hosts Virtuales por departamento . . . . . . . . . . . . . . . . . . . . 305
21.3.2 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
21.3.3 Definiendo los nuevos servidores virtuales . . . . . . . . . . . . . . . . 306
21.3.4 Chequeando la configuración . . . . . . . . . . . . . . . . . . . . . . . 308

21.1 Definición del ejemplo: una Escuela de Informática

Tras las repetidas solicitudes a la Universidad (y el correspondiente tiempo de espera)1 una

empresa especializada en telecomunicaciones, ha cableado nuestro edificio y nos ha dado acceso
a Internet, instalándonos un gran servidor de tres millones de pesetas2 . El servidor trae un sistema
operativo Windows 2000 perfectamente configurado y posee una IP real. Por cierto, el nombre en
el DNS del equipo en muy prometedor www.ei.universidad.es.

Toda la Escuela de Informática está ilusionada, ¡ya eran horas de estar presentes en Internet! Se
hacen multitud de solicitudes a la dirección para crear un sitio Web. Una comisión especial se
reúne y acuerda nombrar un administrador que se encargará del estudio e implantación de las
soluciones necesarias (y a poder ser lo antes posible).

El administrador revisa el equipo y comienza su trabajo, en primer lugar, y atendiendo a sus

razones3 , formatea el disco duro e instala un Linux Red Hat 7.0 utilizando el método estándar
1 Tenga en cuenta que esto es un ejemplo.
2 Aproximadamente 18030 euros.
3 En el anteproyecto presentado en junio del 2001, se indica que se instalará un servidor Web Apache basado en

Linux.

303
304 CAPÍTULO 21. PRIMEROS PASOS

pero sin incluir el servidor HTTP por defecto, ya que sabe que no está muy actualizado (apache
1.3.12).

Nos encontramos por tanto ante un equipo completamente configurado pero sin servidor Web.
Aquí comienza nuestro trabajo.

21.2 Instalar y arrancar un servidor actualizado

Decidimos instalar un servidor Web Apache desde código fuente, utilizando APACI y habilitando
todos los módulos estándar como DSO. Una vez instalado, y con la configuración por defecto,
arrancamos el servidor que se pondrá a la escucha en el puerto 80.

Puede encontrar más información sobre este tema en la anterior parte de este proyecto, donde se
dedica un capítulo completo a los diversos métodos de instalación del servidor Web Apache bajo
Linux/Unix (vea el capítulo 10 en la página 133).

21.3 Publicar la primera Web de la Escuela

Por fin tenemos la infraestructura, hemos instalado el servidor Web y parece que funciona. Ahora
podemos publicar el primer sitio Web de nuestra Escuela. A la página le llamamos index.html y
la ubicamos en el directorio htdocs que se crea durante la instalación de Apache para ubicar los
contenidos HTML. A continuación presentamos el código de esta primera página y la apariencia
(figura 21.1) que ofrece en un navegador que se conecte a ella (http://www.ei.universidad.
es/index.html):

<html>
<title>EUEIE</title>
<body>
<h1 align=center>
Escuela Universitaria de Informática de <b>Ejemplo</b>
</h1>

<p>Bienvenido, esta es nuestra primera página Web,

en breve irán apareciendo contenidos.</p>

<br><br>

<hr>
<p>Para dudas o comentarios envie un mail al
<a href="mailto:webmaster@ei.universidad.es">administrador</a>
</p>
21.3. PUBLICAR LA PRIMERA WEB DE LA ESCUELA 305

<hr>
</body>
</html>

Listado 21.1 Una primera página Web en HTML.

Figura 21.1: Apariencia de una primera página Web en HTML.

21.3.1 Hosts Virtuales por departamento

21.3.2 Nueva necesidad

El sitio Web de nuestra Escuela comienza a crecer, se incluye distinta información (calendario
de exámenes, normativa, horarios de clase, etc, y también información muy básica sobre los
departamentos con docencia). Con el paso del tiempo, algunos departamentos empiezan a barajar
la idea de poseer su propio servidor, entre otras cosas porque no les gusta su URL actual:

http://www.ei.universidad.es/deptos/<NOMBRE_DEPTO>/index.html

Prefieren algo más fácil de recordar, por ejemplo:

http://<NOMBRE_DEPTO>.ei.universidad.es/

Tras la correspondiente reunión se da el visto bueno a esta propuesta, y se aprueba que todos los
departamentos tengan su propio servidor, al que se podrá acceder con una URL adecuada. Se pone
el asunto en manos del responsable del servidor Web para que estudie las posibilidades.
El administrador desea seguir teniendo el control de todos los sitios Web relacionadas con la
Escuela de Informática, además no hay presupuesto para comprar nuevas máquinas, contratar
personas para que las administren o incluso para conseguir nuevas IPs. La solución parece clara,
necesitamos servidores virtuales.
306 CAPÍTULO 21. PRIMEROS PASOS

21.3.3 Definiendo los nuevos servidores virtuales

La imposibilidad de conseguir nuevas IPs, sólo nos deja una solución, utilizar hosts virtuales
basados en nombre. Como no vamos a alojar un número extremadamente grande de hosts
(supongamos que puede haber 15 departamentos con docencia), no utilizaremos la configuración
dinámica que provee el módulo mod_vhost_alias4 .

Varios son los cambios a realizar en el fichero httpd.conf. En primer lugar y para evitar
posibles olvidos, indicamos nuestra intención de usar hosts virtuales basados en nombre mediante
la directiva NameVirtualHost y definimos el host virtual por defecto (vea la sección 12.5.1 en la
página 222) que atenderá las peticiones que no se dirijan explícitamente a ninguno de los otros
servidores alojados:

NameVirtualHost *:*

<VirtualHost _default_:*>
#Datos generales del servidor por defecto.
ServerAdmin webmaster@ei.universidad.es
DocumentRoot "/usr/local/proyecto/htdocs"
ServerName www.ei.universidad.es

# Definiendo el log.
CustomLog "|/usr/local/proyecto/cronolog/sbin/cronolog
--symlink=/usr/local/proyecto/logs/combined_log
/usr/local/proyecto/logs/%Y/%m/combined_log" combined

ErrorLog "|/usr/local/proyecto/cronolog/sbin/cronolog
--symlink=/usr/local/proyecto/logs/error_log
/usr/local/proyecto/logs/%Y/%m/error_log"

</VirtualHost>

Listado 21.2 Servidor virtual por defecto.

Muchas de las directivas no se incluyen explícitamente, si no que heredan su valor del host
principal. Observe que el host virtual por defecto hace más legible la configuración.

El siguiente paso es incluir una nueva sección <VirtualHost> para cada departamento.
Presentamos aquí la configuración de uno de ellos, los demás se construyen de manera análoga:

#Host virtual del departamento de matematicas

4 Si le interesa este tema (vea la sección 12.4 en la página 221)
21.3. PUBLICAR LA PRIMERA WEB DE LA ESCUELA 307

<VirtualHost *>

# Cuestiones generales
ServerName matematicas.ei.universidad.es
DocumentRoot /usr/local/proyecto/htdocs/virtual/matematicas/
ScriptAlias /cgi-bin/
/usr/local/proyecto/cgi-bin/virtual/matematicas/

# Compatibilidad con navegadores antiguos

ServerPath /matematicas

# Log de accesos
CustomLog "|/usr/local/www/cronolog/sbin/cronolog
--symlink=/usr/local/proyecto/logs/matematicas/combined_log
/usr/local/proyecto/logs/matematicas/%Y/%m/combined_log" combined

</VirtualHost>

Listado 21.3 Un servidor virtual.

Si observa el listado, verá que hemos usado la directiva ServerPath que garantiza la
compatibilidad con navegadores que no soportan hosts virtuales5 . Además también se ha
habilitado el registro de accesos6 mediante un fichero propio manipulado por el programa
cronolog7 .

Figura 21.2: Host virtual del departamento de matemáticas.

5 (vea la sección 12.3.1 en la página 220)
6 (vea la sección 19.3.4 en la página 282)
7 (vea la sección 19.3.5 en la página 283)
308 CAPÍTULO 21. PRIMEROS PASOS

En un navegador compatible con hosts virtuales, obtendremos el resultado que se observa en la

figura (figura 21.2).

En un navegador antiguo, podremos usar la URL alternativa definida por ServerPath. Para probar
que Apache responde correctamente utilizaremos cualquier navegador antiguo, o en su defecto el
telnet8 :

# telnet www.ei.universidad.es 80
Escape character is ’^]’.
GET /matematicas/ HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 29 Jul 2001 21:51:09 GMT
Server: Apache/1.3.20 (Unix) mod_jk DAV/1.0.2 PHP/4.0.6
Last-Modified: Sun, 29 Jul 2001 21:46:31 GMT
ETag: "494eb-7a-3b648437"
Accept-Ranges: bytes
Content-Length: 122
Connection: close
Content-Type: text/html

<html>
<body>
<h1>Departamento de matemáticas</h1>
Bienvenido a la página del departamento de matemáticas
</body>
</html>

21.3.4 Chequeando la configuración

Por último recuerde que puede chequear la configuración mediante el comando ./httpd -S. En
nuestra configuración obtenemos el siguiente resultado:

VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
_default_:* www.ei.universidad.es
(/usr/local/proyecto/conf/httpd.conf:1182)
*:80 is a NameVirtualHost
default server informatica.ei.universidad.es
(/usr/local/proyecto/conf/httpd.conf:1194)
8 Con telnet, enviaremos a mano los encabezados necesarios pare hacerle creer al servidor que somos un cliente

compatible con HTTP/1.0 que no soporta servidores virtuales.

21.3. PUBLICAR LA PRIMERA WEB DE LA ESCUELA 309

port 80 namevhost informatica.ei.universidad.es

(/usr/local/proyecto/conf/httpd.conf:1194)
port 80 namevhost matematicas.ei.universidad.es
(/usr/local/proyecto/conf/httpd.conf:1206)
310 CAPÍTULO 21. PRIMEROS PASOS
Capítulo 22

Zona de download de mantenimiento

automático

Contenidos de este capítulo

22.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

22.2 Configuración básica del servicio . . . . . . . . . . . . . . . . . . . . . . . . 312

22.2.1 FancyIndexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

22.2.2 SSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

22.3 El resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

22.1 Nueva necesidad

Actualmente en el centro universitario hay una serie de archivos que están enlazados desde una
página Web, y que varían con el tiempo (horarios, fechas de exámenes, etc.). Estos documentos
pueden estar en varios formatos distintos (HTML, PDF, PS, DOC) dándole al usuario la posibilidad
de elegir el que más le interese. Además para cada archivo se ofrece información relevante del
mismo (fecha de modificación y tamaño).

Nos encontramos con el problema del mantenimiento, cada nuevo cambio en un archivo que
afecte al tamaño o fecha de modificación, debe reflejarse en la página Web correspondiente.
Buscamos alguna solución sencilla que permita remediar este problema. No queremos utilizar
recursos avanzados como lenguajes de programación externos o complicados lenguajes de código
embebido.

311
312 CAPÍTULO 22. ZONA DE DOWNLOAD DE MANTENIMIENTO AUTOMÁTICO

22.2 Configuración básica del servicio

22.2.1 FancyIndexing

Probablemente la solución más sencilla sea colocar todos los ficheros a los que queremos dar
acceso en un directorio y emular un FTP utilizando la característica FancyIndexing (vea la
sección 11.6 en la página 174) de Apache. De esta manera podemos colocar un enlace desde
nuestra Web al directorio, y aparecerá un listado de su contenido formateado de la manera
adecuada.

Para obtener una configuración adecuada necesitamos, en primer lugar, configurar el directorio de
download con las siguientes directivas:

<Directory "/usr/local/proyecto/htdocs/p_ssi/download1">

# Habilitamos la posibilidad de generar listados automáticos

# para el directorio donde residen los ficheros para download

Options +Indexes

# Habilitamos el modo FancyIndexing y eliminamos la descripción

# de ficheros del listado obtenido, ( sólo saldrán el nombre del
# fichero, su tamaño y fecha de modificación ).

IndexOptions FancyIndexing SuppressDescription

# Otras directivas de acceso

AllowOverride None
Order allow,deny
Allow from all

</Directory>

Listado 22.1 Configuración de una página de download con FancyIndexing.

Podemos dar cierta información adicional creando en el directorio los ficheros especiales de
encabezado (HEADER) e información (README). Como ejemplos:

BIENVENIDO AL ÁREA DE DOWNLOAD

22.2. CONFIGURACIÓN BÁSICA DEL SERVICIO 313

------------------------------
Revise las fechas de actualización y los tamaños de los ficheros
antes de proceder a su descarga.

Listado 22.2 Configuración de una página de download. Fichero HEADER.

Si tiene problemas contacte con el administrador.

Listado 22.3 Configuración de una página de download. Fichero README.

Por seguridad, es conveniente habilitar el FancyIndexing sólo en los directorios donde sea
absolutamente necesario.

22.2.2 SSI

Una solución un poco más elaborada y aparente consiste en utilizar una página con directivas SSI.
Si recordamos SSI (vea la sección 4.2 en la página 53) se habilita por defecto con Apache y sus
directivas no son extremadamente difíciles de entender o utilizar.
Con esta opción podemos dar un paso más en el diseño de la página de download, integrándola en
la apariencia general del sitio Web, pasando de ser un simple listado a por ejemplo, un conjunto
de tablas HTML.
Partiremos de una configuración básica de SSI (vea la sección 13.2 en la página 226) y habilitamos
el parsing sólo en el directorio de download mediante las siguientes directivas:

<Directory "/usr/local/proyecto/htdocs/p_ssi/download2">
# Habilitamos la posibilidad de ejecutar directivas SSI
# dentro de este directorio

Options +IncludesNOEXEC

# Otras directivas de acceso

AllowOverride None
Order allow,deny
Allow from all
</Directory>

En este directorio residirán los ficheros que están accesibles a la descarga, y una página con
directivas SSI, que ofrece información sobre los mismos. Mostramos a continuación una parte
significativa del código de esta página:
314 CAPÍTULO 22. ZONA DE DOWNLOAD DE MANTENIMIENTO AUTOMÁTICO

Listado 22.4 Configuración de una página de download con SSI.

<html>
<head><title>EUEE</title></head>
<body>
<!--#config errmsg="" -->
<!--#config sizefmt="Kb" -->
<!--#config timefmt="%d/%m/%y - %H:%M:%S" -->

<br><H1>Calendario de examenes</h1>
<table border=1 cellpadding="1" cellspacing="0" width="100%">
<tr>
<td></td>
<td class=encabezado colspan=2>HTML
<!--#set var="html" value=".htm" --></td>
<td class=encabezado colspan=2>PDF
<!--#set var="pdf" value=".pdf" --></td>
<td class=encabezado colspan=2>PS
<!--#set var="ps" value=".ps" --></td>
<td class=encabezado colspan=2>DOC
<!--#set var="doc" value=".doc" --></td>
</tr>
...
<tr>
<!-- formato HTML -->
<td class=nombrecampo>Febrero
<!--#set var="fichero" value="./examenes/feb" -->
</td>
<td align=center>
<!--#set var="ficherov" value="$fichero$html" -->
<a href="<!--#echo var="ficherov" -->">
<!--#fsize virtual="$ficherov" -->&nbsp;</a>
</td>
<td align=center>
<!--#flastmod virtual="$ficherov" -->
</td>
...
</tr>
</table>
</body>
22.3. EL RESULTADO 315

</html>

Listado 22.5 Página de download con SSI.

22.3 El resultado

De cualquiera de las dos formas propuestas, obtenemos una asociación automática de un archivo
con su información relevante. Esta metainformación sobre el archivo nos ayudará a tomar la
decisión de “bajarlo” o no.

Con la solución basada en FancyIndexes el resultado será parecido a la figura (figura 22.1),
mientras con la solución basada en SSI el resultado sería parecido al de la figura (figura 22.2).

Figura 22.1: Apariencia de una página Web de download basada en FancyIndexes.

316 CAPÍTULO 22. ZONA DE DOWNLOAD DE MANTENIMIENTO AUTOMÁTICO

Figura 22.2: Apariencia de una página Web de download basada en SSI.

Capítulo 23

Negociación de contenido para

personalizar el idioma

Contenidos de este capítulo

23.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

23.2 Configurando la negociación de contenido . . . . . . . . . . . . . . . . . . . 318
23.3 Personalizar los mensajes de error . . . . . . . . . . . . . . . . . . . . . . . 318

23.1 Nueva necesidad

Pasa el tiempo, el sitio Web crece, cada vez hay más documentos HTML estáticos dentro del
directorio htdocs. Un buen día se aprueba en comisión que el sitio Web debe estar en tres idiomas
(gallego, español e inglés) para facilitar la difusión del mismo entre comunidades de hablantes
diferentes.

Al día siguiente por la mañana el administrador tiene el buzón de correo lleno de preguntas
respecto a como abordar esta gran cantidad de trabajo1 . Desafortunadamente no conocemos
ninguna buena herramienta que provea la traducción automática entre los tres idiomas
seleccionados, por tanto cada página deberá ser traducida a mano por sus creadores.

Pero aunque nuestro trabajo no es traducir, si que podemos estudiar cuál es la mejor manera de
ofrecer el servicio en varios idiomas. Se nos ocurren dos soluciones:

Poner enlaces a la versión en cada idioma dentro de la página de entrada al sitio Web. Es una
solución sencilla que no obliga a ningún trabajo por nuestra parte, pero suele ser engorrosa
para el usuario, al que obligamos a elegir su idioma de preferencia.
1 Versiones en tres idiomas implican tres veces más trabajo

317
318CAPÍTULO 23. NEGOCIACIÓN DE CONTENIDO PARA PERSONALIZAR EL IDIOMA

Utilizar la negociación de contenidos (vea la sección 2.3.1 en la página 30), que entre
otras cosas permite conocer la preferencia de idiomas del usuario sin la necesidad de
preguntárselo explícitamente. De esta manera puede presentársele automáticamente la
información en el formato que más le interesa. Esta segunda opción si requiere de algo
de trabajo por parte del administrador.

23.2 Configurando la negociación de contenido

Utilizaremos la característica de negociación de contenido que proporciona Apache. Debemos

verificar que las siguientes líneas aparecen en el fichero de configuración httpd.conf:

AddLanguage es .es
AddLanguage en .en
AddLanguage gl .gl

LanguagePriority gl es en

Con AddLanguage2 añadimos idiomas que pueden ser usados en la negociación y sus extensiones
asociadas, mientras que con LanguagePriority3 determinamos la prioridad de cada lenguaje caso
de que el cliente no indique ninguno.

Lo último que queda es traducir cada página e indicar cuál es el idioma en que está escrita. Para
ello se les cambia el nombre incluyendo la extensión adecuada al idioma. Por ejemplo, el archivo
index.html ahora tendrá tres versiones (una por idioma):

index.html.es
index.html.en
index.html.gl

Los clientes (navegadores) de última generación también pueden ser configurados para que
expresen la elección del usuario respecto al idioma. Un ejemplo puede observarse en la figura
(figura 23.1).

23.3 Personalizar los mensajes de error

Ahora que hemos configurado la negociación de contenido para el idioma, ¿por que no utilizarlo
para mejorar aún más el servicio que ofrece nuestro servidor? Efectivamente, decidimos
aprovechar la negociación de contenido para ofrecer un tratamiento de los errores más amigable y
2 (vea la sección 11.8.3 en la página 190)
3 (vea la sección 11.8.6 en la página 193)
23.3. PERSONALIZAR LOS MENSAJES DE ERROR 319

Figura 23.1: Configurando nuestro idioma de preferencia en Opera 5 para Linux.

explicativo para los usuarios. Combinaremos la negociación de contenidos con la posibilidad de

establecer ficheros de error predeterminados.

Haremos varios cambios en el fichero de configuración httpd.conf, utilizando la directiva

ErrorDocument que permite especificar el documento que será devuelto en caso de error.
Podemos enlazar por ejemplo una página Web con una descripción extensa del error:

ErrorDocument 401 /error/401.html

ErrorDocument 403 /error/403.html
ErrorDocument 404 /error/404.html
ErrorDocument 405 /error/405.html
ErrorDocument 500 /error/500.html

Pero tenemos un problema, hay ciertos parámetros que cambian en cada petición errónea y que
deberíamos incluir en los mensajes. Por ejemplo, la URL a la que intentamos acceder, el servidor
virtual que aloja la página, etc. Para presentar mensajes personalizados incluyendo este tipo de
información, podemos recurrir a SSI.

A continuación mostraremos la forma de conseguir errores personalizados, en el idioma adecuado

y para todos los hosts virtuales alojados, utilizando modelos de páginas SSI. Almacenaremos
todos los archivos involucrados en un sólo directorio de errores (/error). Tendremos dos archivos
comunes:
320CAPÍTULO 23. NEGOCIACIÓN DE CONTENIDO PARA PERSONALIZAR EL IDIOMA

head.shtml (.gl, .es, .en): una cabecera con inclusiones SSI. Como ejemplo vea el contenido
del archivo de cabecera en gallego head.shtml.gl:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">

<HTML>
<HEAD>
<TITLE>
[<!--#echo var="REDIRECT_STATUS" -->]
<!--#echo var="title" -->
</TITLE>
</HEAD>
<BODY BGCOLOR="white"><UL>
<H1 ALIGN="center">
<!--#set var="Servidor"
value="http://$HTTP_HOST/" -->
<!--#echo var="Servidor" -->
</H1>

<HR>

<H2>
[<!--#echo var="REDIRECT_STATUS" -->]
<!--#echo var="title" -->
</H2>

<DIV>

Listado 23.1 Negociación de contenido SSI. head.shtml.gl.

Fíjese que al mostrar la información de la variable HTTP_HOST en la respuesta personalizada,

estamos creando, de una manera muy sencilla, una versión personalizada del error para cada
host virtual.


foot.shtml (.gl, .es, .en): un pié con inclusiones SSI. El contenido del archivo de pié en
gallego foot.shtml.gl sería:

</DIV>
<HR>
<DIV ALIGN="center">
<font size=2>
<b>Aloxado en</b>:
23.3. PERSONALIZAR LOS MENSAJES DE ERROR 321

<!--#echo var="SERVER_SOFTWARE" --><BR>

<b>Hora do servidor local</b>:

<!--#echo var="DATE_LOCAL" --><BR>

Se o erro indicado lle parece froito dunha

mala configuración, faga o favor, informe ó
<A HREF="mailto:<!--#echo var="SERVER_ADMIN" -->"
SUBJECT="Error: <!--#echo var="title" -->
en httpd://<!--#echo var="HTTP_HOST" -->
<!--#echo var="REQUEST_URI" -->">WebMaster</A>.
</font>
</DIV>

</BODY>
</HTML>

Listado 23.2 Negociación de contenido SSI. foot.shtml.gl.

Además, por cada error4 tendremos también tres archivos .shtml (uno para cada idioma al que
vamos a traducir la explicación del error), que incluirán mediante directivas SSI el encabezado
(head.shtml) y pie (foot.shtml) definidos anteriormente. Por ejemplo el archivo que se procesará
cuando se produce un error 404 Not Found y el cliente tiene por idioma preferente el gallego es
404.shtml.gl:

<!--#set var="title" value="Bad Request"-->

<!--#include virtual="head" -->
<P>O seu navegador pediu un recurso que non se atopa no servidor:
<BLOCKQUOTE>
<b><!--#echo var="REQUEST_URI" --></b>
</BLOCKQUOTE>
</P>
<!--#include virtual="foot" -->

Listado 23.3 Negociación de contenido SSI. 404.shtml.gl.

Un ejemplo del resultado para un error 404 Not Found y un cliente que prefiere el gallego puede
observarse en la imagen (figura 23.2).
4 Hay bastantes errores, pero en la mayoría de los casos nos llegará con personalizar los más comunes (404, 500,
etc.)
322CAPÍTULO 23. NEGOCIACIÓN DE CONTENIDO PARA PERSONALIZAR EL IDIOMA

Figura 23.2: Un error personalizado.

Capítulo 24

Linkómetro. Ejecución de scripts CGI

de usuario

Contenidos de este capítulo

24.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
24.2 Configuración básica del servicio . . . . . . . . . . . . . . . . . . . . . . . . 323
24.3 Configurar un script de usuario de ejemplo. “Linkómetro” . . . . . . . . . 325
24.4 El resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

24.1 Nueva necesidad

Un usuario con conocimientos de programación nos comenta que le gustaría poder ejecutar sus
propios scripts CGI. Es un usuario en el que confiamos, y decimos darle esa posibilidad.

24.2 Configuración básica del servicio

Podemos habilitar la ejecución de CGIs para todos los usuarios, pero esto no nos interesa ya
que podría no ser muy seguro (vea la sección 13.3.6 en la página 236). La configuración que
realizaremos permitirá la ejecución sólo a los scripts del administrador y del usuario que realmente
necesita utilizar los CGI. Daremos los siguientes pasos:

1. Partimos de una instalación de Apache con el wrapper suEXEC activado (vea la sección
13.3.3 en la página 230).

2. Para permitir la ejecución de los scripts del administrador, utilizamos alguno de los métodos
de configuración básica de CGI que se comentan en un capítulo anterior (vea la sección
13.3.4 en la página 232). Concretamente elegimos la opción más extendida (de hecho suele
venir activada por defecto en el fichero httpd.conf ):

323
324 CAPÍTULO 24. LINKÓMETRO. EJECUCIÓN DE SCRIPTS CGI DE USUARIO

ScriptAlias /cgi-bin/ "/usr/local/proyecto/cgi-bin/"

<Directory "/usr/local/proyecto/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>

Listado 24.1 Configuración básica para ejecución de CGIs.

3. Finalmente habilitamos selectivamente la ejecución de scripts CGI para el usuario en el que

confiamos. Por ejemplo para que un usuario (txapi) pueda utilizar CGIs ubicados en su
directorio personal, puede utilizarse lo siguiente:

# Indicamos el directorio de usuario para el web

UserDir /home/*/public_html

# Definimos el acceso al directorio web de cada usuario.

<Directory /home/*/public_html>
Options Indexes
AllowOverride None
Order allow,deny
Allow from all
</Directory>

# Indicamos el directorio de usuario que va a poder

# ejecutar CGI.
# Utilizamos expresiones regulares, para indicar que
# solo "txapi" tiene acceso.

ScriptAliasMatch ^/~txapi/cgi-bin/(.*)
/home/txapi/public_html/cgi-bin/$1

# Definimos el acceso al directorio cgi del usuario,

# indicando que podrá ejecutar scripts.

<Directory /home/txapi/public_html/cgi-bin>
24.3. CONFIGURAR UN SCRIPT DE USUARIO DE EJEMPLO. “LINKÓMETRO” 325

Options ExecCGI
SetHandler cgi-script
</Directory>

Listado 24.2 Configuración para ejecución de CGIs en directorios de usuario.

24.3 Configurar un script de usuario de ejemplo. “Linkómetro”

Una vez preparado el soporte por parte del servidor, el usuario ya puede colocar sus scripts CGI.
En este caso, el usuario (txapi) ha hecho un pequeño programa en Perl, que se encarga de gestionar
sus enlaces preferidos (bookmarks) y mantener una página Web en su directorio personal con la
información de los mismos (figura 24.1). Al estar utilizando suEXEC, los scripts se ejecutarán
con los permisos del propietario, además se realizarán todas las comprobaciones de seguridad
asociadas (vea la sección 13.3.2 en la página 229).

Figura 24.1: Apariencia de una página Web de marcadores generada con el Linkómetro.

El programa, al que ha dado en llamar Linkómetro utiliza una serie de ficheros. Se presenta a
continuación la estructura de directorios y los permisos que “garantizan” la seguridad1 .

El usuario organiza su directorio Web en tres subdirectorios, uno para páginas (enlaces), otro para
gráficos (graficos) y uno más que contiene los scripts y ficheros de datos asociados (cgi-bin).
1 “Garantizan”, entre comillas, por que nada está absolutamente seguro en la red.
326 CAPÍTULO 24. LINKÓMETRO. EJECUCIÓN DE SCRIPTS CGI DE USUARIO

[txapi public_html]# ls -la

total 20
drwxr-xr-x 5 txapi txapi 4096 jul 9 22:23 .
drwxr-xr-x 25 txapi txapi 4096 jul 9 21:40 ..
drwxr-x--x 4 txapi txapi 4096 jul 9 22:55 cgi-bin
drwxr-xr-x 2 txapi txapi 4096 jul 9 22:35 enlaces
drwxr-xr-x 3 txapi txapi 4096 jul 9 21:51 graficos

Dentro del directorio public_html, los directorios de páginas y gráficos deben tener permisos
755 y el directorio de ejecución de cgi 751.

El programa se compone de tres scripts de Perl (con extensión .pl), ficheros de modelo de páginas
Web (con extensión .htm) y un par de directorios de datos que leerá/escribirá el programa:

[txapi cgi-bin]# ls -la

total 76
drwxr-x--x 4 txapi txapi 4096 jul 9 22:55 .
drwxr-xr-x 5 txapi txapi 4096 jul 9 22:23 ..
-rwx------ 1 txapi txapi 15896 jun 26 1998 cgi-lib-e.pl
-rwx------ 1 txapi txapi 1095 jul 9 22:21 criptar.pl
drwx------ 2 txapi txapi 4096 jul 9 22:51 datos
-rwx------ 1 txapi txapi 16707 jul 9 22:54 enl.pl
-r-------- 1 txapi txapi 5370 abr 12 1997 enlaces1.htm
-r-------- 1 txapi txapi 2806 abr 12 1997 enlaces2.htm
drwx------ 2 txapi txapi 4096 jul 9 23:35 linkometro_log
-r-------- 1 txapi txapi 1673 abr 11 1997 menu.htm
-r-------- 1 txapi txapi 3596 abr 12 1997 usuarios.htm

Dentro del directorio cgi-bin, nos basta con dar permisos sólo al propietario. Los scripts
CGI enl.pl, criptar.pl, cgi-lib.pl necesitan al menos poder ejecutarse, pero podemos
darle permisos 700. Los modelos de páginas enlaces1.htm, enlaces2.htm, menu.htm,
usuarios.htm se utilizan como plantillas que pueden ser leídas, completadas mediante un script
y presentadas como página Web. Estos modelos tendrán permisos de sólo lectura 400.

[txapi datos]# ls -la

total 24
drwx------ 2 txapi txapi 4096 jul 9 22:51 .
drwxr-x--x 4 txapi txapi 4096 jul 9 22:55 ..
-rw------- 1 txapi txapi 33 jul 9 23:55 enlaces.dat
-rw------- 1 txapi txapi 16 jul 9 22:35 mod_enl.htm
-rw------- 1 txapi txapi 94 jul 9 22:33 users.dat
24.4. EL RESULTADO 327

Los dos directorios que almacenan datos privados son: datos y linkometro_log. Ambos deben
tener permisos de acceso total para el usuario 700, y su contenido accesos de lectura y escritura
sólo para el usuario 600.

24.4 El resultado

El usuario ha escrito un conjunto de scripts CGI que le permiten manejar sus marcadores. Los
scripts se ejecutan bajo los permisos del propio usuario, lo que limita los riesgos de seguridad a la
vez que le da la posibilidad de crear contenido dinámico propio. El sistema se basa en formularios
que solicitan la información del usuario y la almacenan en un fichero de datos dentro del directorio
personal. Puede verse un ejemplo de la interface en la figura (figura 24.2).

Figura 24.2: Apariencia de la interface del Linkómetro.

328 CAPÍTULO 24. LINKÓMETRO. EJECUCIÓN DE SCRIPTS CGI DE USUARIO
Capítulo 25

Dreamweaver y WebDav. Gestión

remota de sitios Web

Contenidos de este capítulo

25.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

25.2 Configuración del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
25.3 El resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

25.1 Nueva necesidad

El departamento de Matemáticas, también quiere que sus datos se publiquen en la Web. Han
convocado unas becas de verano para las personas interesadas. Tras el escrutinio de candidatos,
salen elegidos dos chicos que estudian “magisterio”.

En las primeras reuniones se habla del material que va a ser necesario. Ni el departamento, ni los
becarios tienen mucha idea. Finalmente se llega a la conclusión de que será necesario comprar un
ordenador, que viene de fábrica con su Windows Millenium Edition.

El jueves, celebrando con sus amigos de informática la beca recién concedida, los becarios piden
consejo sobre que programa usar para hacer las páginas Web.

- ...
- ¿ Word ?, mejor no.
- ¿Por qué no utilizais Macromedia Dreamweaver 4.0?, es fácil, visual y soporta WebDAV.
- ¿WebDAV? ¿Eso que es?
- Es la solución si quereis trabajar en conjunto, pero cada uno desde vuestra casa ...

El viernes, nueva reunión con el responsable del departamento para que compre dos licencias del
programa en cuestión. El departamento acepta la petición.

329
330 CAPÍTULO 25. DREAMWEAVER Y WEBDAV. GESTIÓN REMOTA DE SITIOS WEB

El lunes, comienza el trabajo. En el departamento piden dos cosas, que la página esté acabada antes
de septiembre, y que se intenten aprovechar las posibilidades más novedosas del Dreamweaver,
para así justificar la inversión realizada1 . Rápidamente se ponen en contacto con el administrador
de la Web, solicitando que se active el soporte WebDAV.

25.2 Configuración del servicio

Sobre WebDAV (Web Distributed Authoring and Versioning) y sus entresijos teóricos ya se habló
en la primera parte de esta memoria (vea la sección 7.3 en la página 102). Las posibilidades
DAV de Apache también fueron analizadas anteriormente, comentábamos la existencia del módulo
mod_dav, las nuevas directivas de configuración que aporta e incluso llegamos a mostrar algún
pequeño listado de configuración (vea la sección 17.4 en la página 263).
Pero vamos a ir un poco más allá, partiendo del sitio Web del Departamento de Matemáticas2
habilitaremos WebDAV. De esta manera el sitio podrá ser construido de forma colaborativa
mediante los clientes Macromedia Dreamweaver de cada uno de los becarios. Lo primero será
añadir a httpd.conf las directivas generales de DAV (temporizadores y bloqueos):

DAVLockDB /usr/local/proyecto/dav/DAVLock
DAVMinTimeout 100

Luego se habilita en el servidor principal un directorio que va a tener acceso por DAV y que
coincidirá con el indicado por la directiva DocumentRoot del servidor virtual del Departamento
de Matemáticas. Asimismo estableceremos un alias (/dav) para este directorio. Con esto
conseguimos que todos los cambios realizados en http://www.ei.universidad.es/dav sean
accesibles automáticamente desde la URL del servidor virtual http://matematicas.ei.
universidad.es/:

Alias /dav "/usr/local/proyecto/htdocs/virtuales/matematicas/"

<Directory "/usr/local/proyecto/htdocs/virtuales/matematicas">
DAV On
</Directory>

Listado 25.1 Habilitar WebDAV para construir colaborativamente un servidor virtual.

Además y durante el período de desarrollo, protegeremos el acceso mediante claves de

autenticación básica3 . De esta forma sólo con una clave válida se podrán hacer cambios en el
sitio. La configuración quedará así:
12 licencias * 56.000 ptas/licencia (precio actualizado a julio de 2001)
2 Configurado como un servidor virtual en un capítulo anterior (vea el capítulo 21.3.1 en la página 305).
3 Los conceptos teóricos relacionados con la autentificación en Apache se presentan en un capítulo anterior (vea el

capítulo 16 en la página 253).

25.3. EL RESULTADO 331

Alias /dav "/usr/local/proyecto/htdocs/virtuales/matematicas/"

<Directory "/usr/local/proyecto/htdocs/virtuales/matematicas">
DAV On

AuthType Basic
AuthName "Directorio accesible mediante DAV"
AuthUserFile /usr/local/proyecto/conf/controlacceso
<Limit GET PUT POST DELETE PROPFIND PROPPATCH MKCOL
COPY MOVE LOCK UNLOCK>
Require user becario1 becario2
</Limit>
</Directory>

Listado 25.2 Habilitar control de acceso a un directorio con acceso WebDAV.

Las claves pueden ser creadas con la utilidad ./htpasswd que se distribuye con Apache,
por ejemplo, para introducir un nuevo usuario becario1 dentro del fichero de claves
../../conf/controlacceso:

./htpasswd ../../conf/controlacceso becario1

New password:
Re-type new password:
Adding password for user becario1

25.3 El resultado

Desde sus casas los becarios pueden utilizar Macromedia Dreamweaver para crear el sitio Web,
al que accederán de manera controlada mediante su login/password personal. En la figura (figura
25.1) se observa un momento en el proceso de desarrollo.
332 CAPÍTULO 25. DREAMWEAVER Y WEBDAV. GESTIÓN REMOTA DE SITIOS WEB

Figura 25.1: Utilizando Dreamweaver como cliente WebDAV.

Capítulo 26

UDMSearch. Un buscador Web

Contenidos de este capítulo

26.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

26.2 El buscador UDMSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
26.2.1 Características del buscador UDMSearch . . . . . . . . . . . . . . . . 334
26.3 Instalación básica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
26.3.1 Listas de parada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
26.3.2 Extracción de raíces . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
26.4 Configurar el robot indexador de páginas . . . . . . . . . . . . . . . . . . . 336
26.5 Ejecutar el robot indexador de páginas . . . . . . . . . . . . . . . . . . . . 338
26.6 Configurar el motor de búsqueda y la interface Web . . . . . . . . . . . . . 339
26.7 Probar una búsqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

26.1 Nueva necesidad

Ha pasado un tiempo y el número de páginas que forman parte de la Escuela de Informática

ha crecido de forma exponencial. Internet ofrece el medio y toda la comunidad universitaria
se ha subido al tren, publicando cantidades ingentes de información (departamentos, profesores,
asignaturas, calificaciones, congresos, cursillos, conferencias, tablón de anuncios, etc.). Comienza
a ser complicado para los usuarios localizar los datos que realmente le interesan y muchas
veces pierden bastante tiempo navegando sin sentido. Comienzan a llegar correos electrónicos al
webmaster solicitando la implantación de algún sistema de ayuda a la localización de contenidos.
Como primera medida decidimos enviar un mail a los desarrolladores de cada sitio Web alojado
en el servidor. En este mensaje pedimos encarecidamente que se incorpore una página mapa del
sitio donde se clarifique la estructura y los contenidos que se han publicando. Pasa el tiempo y
parece que los desarrolladores están ocupados, porque no han hecho caso a nuestras peticiones.
Pero siguen llegando quejas de usuarios ... ¡tenemos que ofrecer una solución!

333
334 CAPÍTULO 26. UDMSEARCH. UN BUSCADOR WEB

Tras unos días de búsqueda por la Web encontramos un programa de código libre1 UDMSearch
[122] que implementa un buscador completo bastante potente.

26.2 El buscador UDMSearch

UDMSearch es un buscador (vea la sección 8.4 en la página 121) que funciona en prácticamente
todas las plataformas Unix/Linux y trabaja con SQL sobre diversos SGBD (Oracle, MySQL,
Interbase, etc.). Las últimas versiones se distribuyen con un API en C y bibliotecas que permiten
a aplicaciones de terceras partes añadir capacidades de búsqueda. Sus componentes básicos son:

1. Robot + indexador (indexer): un robot que recorre la Web recuperando documentos,

indexándolos y almacenando los resultados en la base de datos. Soporta múltiples
protocolos (HTTP, NNTP, HTDB2 , etc.)

2. Motor de búsqueda + interface Web: para recuperar la información de la base de datos. Está
disponible en distintos formatos (PHP, CGI en C, o CGI en Perl).

26.2.1 Características del buscador UDMSearch

Entre las características más interesantes:

Reconoce el estándar de exclusión de robots.

Puede utilizar listas de parada (stop lists).

Soporta extracción de raíces apoyándose en el programa Ispell.

Utiliza un lenguaje booleano de búsqueda basado en los operadores típicos (and, or, not).

Formato de respuesta configurable con plantillas.

Internacionalización mediante diferentes conjuntos de caracteres.

...

En futuras versiones se pretende añadir nuevas mejoras, como diferentes tipos de búsqueda (por
frases, de sinónimos, etc.) o la implementación como módulo de Apache.
1 Existen algunos otros, como por ejemplo Lucene [62].
2 Un protocolo que permite indexar el contenido de páginas obtenidas de una BBDDs.
26.3. INSTALACIÓN BÁSICA 335

26.3 Instalación básica

Obtenemos el software udmsearch-3.0.23.tar.gz en el sitio http://mysearch.udm.net/ y

lo descomprimimos en un directorio adecuado para su instalación:

# cp udmsearch-3.0.23.tar.gz /usr/local/proyecto/src
# cd /usr/local/proyecto/src
# gunzip -c -d udmsearch-3.0.23.tar.gz | tar xf -
# cd udmsearch-3.0.23

Ahora configuramos el software indicando la ruta de instalación (--prefix) y un sistema gestor

de bases de datos, en nuestro caso MySQL (--with-mysql), que debe estar previamente instalado
en el sistema. Se termina con los pasos habituales para construir proyectos mediante la utilidad
make:

# ./configure --with-mysql \
--prefix=/usr/local/proyecto/aplicaciones/udmsearch
# make
# make install

A continuación se crea una base de datos de nombre udmsearch y sus tablas asociadas. La base de
datos es una parte fundamental en el buscador, en ella se almacenan los índices. Utilizamos una
utilidad estándar de Mysql (mysqladmin):

# mysqladmin create udmsearch

# mysql udmsearch < ./create/mysql/create.txt

26.3.1 Listas de parada

Actualmente en nuestro servidor existen páginas en tres idiomas: gallego, español e inglés.
UDMSearch permite añadir listas de parada (stopwords) para cada uno de ellos. Dentro del
árbol de instalación, en el directorio /create/stopwords/ se proporcionan listas de parada de
ejemplo. Basándonos en ellas podemos crear las listas de parada en español (stop.es.txt), gallego
(stop.gl.txt) e inglés (stop.en.txt) adecuadas a nuestras necesidades. Cada lista de parada es un
fichero de texto con el siguiente formato:

# idioma palabra
# ^ ^
INSERT INTO stopword(lang, word) VALUES (’es’, ’un’);
INSERT INTO stopword(lang, word) VALUES (’es’, ’una’);
INSERT INTO stopword(lang, word) VALUES (’es’, ’unas’);
336 CAPÍTULO 26. UDMSEARCH. UN BUSCADOR WEB

INSERT INTO stopword(lang, word) VALUES (’es’, ’unos’);

INSERT INTO stopword(lang, word) VALUES (’es’, ’uno’);
INSERT INTO stopword(lang, word) VALUES (’es’, ’sobre’);
INSERT INTO stopword(lang, word) VALUES (’es’, ’todo’);
...

Listado 26.1 Formato de un fichero con listas de parada para UDMSearch.

Una vez preparadas las añadimos a la BBDDs con las siguientes órdenes:

# mysql udmsearch <stop.gl.txt

# mysql udmsearch <stop.es.txt
# mysql udmsearch <stop.en.txt

26.3.2 Extracción de raíces

UDMSearch puede apoyarse en el programa Ispell para extraer raíces que se refieran a palabras de
significado parecido (plurales, tiempos verbales, etc.), de esta manera se “normalizan” las palabras
reduciendo el tamaño de la base de datos y mejorando la velocidad de búsqueda, pero se pierde la
capacidad de hacer búsquedas exactas.

Dado que en nuestra Escuela de Informática el tamaño de la BBDD no va a ser extremadamente

grande y que además no nos interesa perder la posibilidad de hacer búsquedas exactas, no
utilizaremos esta característica3 .

26.4 Configurar el robot indexador de páginas

Un programa llamado indexer implementa las características de robot indexador de páginas en el

buscador UDMSearch. indexer es capaz de visitar recursivamente documentos a través de varios
protocolos (HTTP, FTP, NEWS, sistemas de ficheros locales) y almacenar metadatos (índices) en
una base de datos SQL.

El programa soporta de manera nativa la indexación de páginas HTML o de texto, pero también
puede analizar ficheros con otros tipos de datos, para ello se apoya en programas externos que
convierten a formato texto (por ejemplo catdoc que convierte desde documentos de Word o
ps2ascii que convierte desde PostScript).

El comportamiento del robot / indexador se controla principalmente con el archivo indexer.conf,

aunque también pueden pasársele algunos parámetros desde la línea de órdenes. El fichero
de configuración indexer.conf está ubicado en /etc dentro del directorio de instalación del
3 Más información de como usar UDMSearch con Ispell puede encontrarse en el directorio /doc del árbol de

instalación.
26.4. CONFIGURAR EL ROBOT INDEXADOR DE PÁGINAS 337

programa, contiene una serie de directivas abundantemente comentadas4 , alguna de los más
interesantes pueden verse en la tabla (tabla 26.1).

Directiva Significado
DBAddr Cadena de conexión con la base de datos. Recuerde que una
BBDD es absolutamente necesaria para el funcionamiento de
UDMSearch.
DBMode Establece la estructura de la tabla de vocabulario (dict). Existen
diversas posibilidades: multi, crc y single que es el valor por
defecto. En según que casos, una estructura es más eficiente
que la otra, pero para nosotros nos vale el valor por defecto.
DisAllow Establece tipos de archivo que no se quieren indexar, por
ejemplo *.exe, *.avi, etc.
HTTPHeader Cabeceras de identificación del robot indexador que se le
envían al servidor.
Robots UDMSearch puede respetar o no los estándares de exclusión
de robots. Con esta directiva puede configurarse este
comportamiento.
Server Es la directiva principal de la configuración, indica una URL
de salida para la indexación. Pueden añadirse tantas directivas
Server como se deseen.

Tabla 26.1: Algunas directivas de configuración de UDMSearch.

Los valores por defecto son válidos para la mayoría de las directivas, los únicos cambios que
haremos en indexer.conf se muestran en el siguiente listado:

...
#######################################################
# Configuración de la cadena de conexión con la
# BBDD MySQL que acabamos de crear.

DBAddr mysql://root@localhost/udmsearch/

...

#######################################################
# Robots yes/no
# Activa/desactiva el uso de las características de
# exclusión de robots. Usar "no", no es ético para su
# uso en la red, pero puede utilizarse por ejemplo en
# la validación de enlaces de nuestro servidor.
4 Más información en las páginas man que se instalan con el programa.
338 CAPÍTULO 26. UDMSEARCH. UN BUSCADOR WEB

# El comando puede usarse varias veces en el fichero de

# configuración y tiene efecto hasta la próxima
# aparición de la directiva.
Robots yes

...

######################################################
#Server <url>
# Es la directiva principal de indexer.conf
# Añade una URL de comienzo.

Server http://www.ei.universidad.es/
Server http://matematicas.ei.universidad.es/
Server http://informatica.ei.universidad.es/

...

Listado 26.2 Configuración del indexador de UDMSearch. indexer.conf.

26.5 Ejecutar el robot indexador de páginas

El robot/indexador se ejecutará mediante la orden:

# /usr/local/proyecto/aplicaciones/udmsearch/sbin/indexer
Indexer[1182]: indexer UdmSearch v.3.0.23/MySQL started with
’/usr/local/proyecto/aplicaciones/udmsearch/etc/indexer.conf’
Indexer[1182]: [1] http://www.ei.universidad.es/robots.txt
Indexer[1182]: [1] http://www.ei.universidad.es/
...

Por defecto el programa lee la configuración de indexer.conf y procede con la indexación. Para
mantener la BBDD actualizada debe ejecutarse el programa cada cierto tiempo, no es una mala
idea automatizar la tarea con alguna utilidad, como por ejemplo cron.

Pero con el ejecutable (indexer) pueden hacerse más cosas que simplemente indexar. Para ello
se usan parámetros en la línea de órdenes5 . Por ejemplo:
5 El listado completo de parámetros puede consultarse en las páginas man que se instalan con el programa, mediante

el comando man indexer.

26.6. CONFIGURAR EL MOTOR DE BÚSQUEDA Y LA INTERFACE WEB 339

indexer -C: para borrar el contenido de la base de datos, puede utilizarse por ejemplo,
antes de reindexar tras haber añadido nuevas listas de parada. La salida del programa sería
la siguiente:

# ./indexer -C
You are going to delete database ’udmsearch’ content
Are you sure?(YES/no)

indexer -S: para presentar estadísticas del proceso de recuperación de documentos para
indexación. La información proporcionada se parecerá a:

# ./indexer -S
UdmSearch statistics

Status Expired Total

-----------------------------
200 0 137 OK
401 0 2 Unauthorized
404 0 2 Not found
-----------------------------
Total 0 141

26.6 Configurar el motor de búsqueda y la interface Web

El paquete UDMSearch proporciona varias soluciones para el motor de búsqueda y la interface:

Un programa CGI compilado hecho en C (search.cgi) que puede encontrarse en /bin, dentro
del directorio de destino del la instalación del programa6 . La interface es una página Web
no configurable que se genera desde el mismo programa.


Un script CGI en Perl (search.pl), que puede encontrarse en el árbol de directorios de

instalación7 bajo la ruta frontends/perl/. La interface es una página Web configurable
mediante cambios en el archivo de modelo frontends/perl/search.htm.


Una página Web con inclusiones PHP (search.php). Reside dentro del árbol de instalación
bajo el path frontends/php/. La interface es una página Web configurable mediante
cambios en el archivo de modelo frontends/php/search.htm.mysql.

Podemos usar cualquiera de los interfaces (CGI o PHP), pero el más evolucionado es el
proporcionado por la versión PHP, que entre otras cosas soporta completamente la búsqueda con
operadores booleanos. Para configurarla se siguen los siguientes pasos:
6 En nuestro caso /usr/local/proyecto/aplicaciones/udmsearch/bin/search.cgi.
7 En nuestro caso /usr/local/proyecto/src/udmsearch-3.0.23/.
340 CAPÍTULO 26. UDMSEARCH. UN BUSCADOR WEB

1. Copiar los ficheros relacionados con la interface en un directorio adecuado. Por ejemplo:

# cp ./frontends/php/
/usr/local/proyecto/aplicaciones/busqueda/

2. Editamos el fichero de modelo (search.htm.mysql) que incluye los parámetros adecuados

para configurar el acceso a la base de datos que almacena los índices. En nuestro caso:

...
DBAddr mysql://root@localhost/udmsearch/
DBMode single
...

3. Como la interface se apoya en PHP, obviamente necesitamos que nuestro servidor esté
preparado para manejar este tipo de código embebido8 . Posteriormente editamos el
fichero de configuración de Apache httpd.conf e incluimos las siguientes líneas que dan
acceso desde el Web a la búsqueda mediante la URL http://www.ei.universidad.es/
busqueda/:

# Habilitar busqueda PHP

<IfModule mod_alias.c>
# Alias del directorio de instalación
Alias /busqueda/ "/usr/local/proyecto/aplicaciones/busqueda/"

# Configuración de acceso al directorio

<Directory "/usr/local/proyecto/aplicaciones/busqueda/">
Options Indexes
AllowOverride None
DirectoryIndex index.php

# Control de acceso
Order deny,allow
Allow from All
</Directory>
</IfModule>

Listado 26.3 Configuración del indexador de UDMSearch. httpd.conf.

4. Y por fin reiniciamos Apache para que acepte los cambios y ya tenemos preparado el nuevo
motor de búsqueda de nuestro servidor.
8 En un capítulo anterior se explica como hacerlo (vea el capítulo 15 en la página 247)
346 CAPÍTULO 27. JIVE. UN SISTEMA DE FOROS BASADO EN SERVLETS Y JSP

2. Editar la configuración de Tomcat (server.xml), la ubicación del directorio depende de

como hayamos instalado Tomcat1 . Añadimos un nuevo contexto para Jive:

...

<Context path="/jive"
docBase="webapps/jive"
debug="0"
reloadable="true">
</Context>

...

Listado 27.1 Configuración de Jive. server.xml.

3. Copiar los ficheros de la aplicación (.jar y .propierties) desde el árbol de instalación a

su ubicación bajo el control de Tomcat:

# mv application/classes /var/tomcat/webapps/jive/WEB-INF
# mv application/lib /var/tomcat/webapps/jive/WEB-INF

4. Configurar el fichero de propiedades de Jive

(/var/tomcat/webapps/jive/WEB-INF/classes/jive.properties):

# jive.properties
# Note: you MUST edit this file to make Jive work.
# After copying this file into the
# the classpath of your servlet engine, change the "path"
# paramater to the full and exact path of where this file
# exists.

path =
/var/tomcat/webapps/jive/WEB-INF/classes/jive.properties

Listado 27.2 Configuración de Jive. jive.properties.

5. Instalar los skins, copiando el contenido del directorio de skins en el directorio creado para
Jive:

# mv skins/* /var/tomcat/webapps/jive
1 En nuestra instalación el fichero reside en /var/tomcat/conf/server.xml.
27.5. PROBAR 347

27.4.3 Terminar la configuración desde el entorno Web

Tras rearrancar Tomcat para que acepte los cambios, se continua la configuración con una
herramienta basada en Web accesible desde la URL http://localhost:8080/jive/admin
(figura 27.1). Es muy cómoda y funciona como un wizard que nos guía paso a paso en el resto del
proceso:


Conexión con la BBDD.



Configuración del directorio base de Jive.



Creación de cuenta de superusuario.



Configuración básica de usuarios, grupos, foros, permisos, ...

Figura 27.1: Configuración basada en Web de Jive.

27.5 Probar

Con la autoconfiguración de Tomcat para Apache activada (vea la sección 14.4.2 en la página
244), el acceso desde Apache a los servicios de Jive es prácticamente inmediato. Al teclear
la URL http://www.ei.universidad.es/jive/admin/ obtendremos acceso a la sección de
administración (figura 27.2).
Mientras que para el acceso de los usuarios se puede elegir entre varios skins o apariencias
distintas2 . En la distribución por defecto se incluyen dos skins, accesibles desde las URLs http:
2 Pueden crearse skins personalizados o conseguir más en el sitio Web de Jive.
348 CAPÍTULO 27. JIVE. UN SISTEMA DE FOROS BASADO EN SERVLETS Y JSP

//www.ei.universidad.es/jive/bay/ y http://www.ei.universidad.es/jive/vodka/
(figura 27.3).

Figura 27.2: Administración de Jive.

Figura 27.3: Aspecto de un skin de Jive.

Capítulo 28

PhpMyAdmin. Gestión Web de bases de

datos MySQL

Contenidos de este capítulo

28.1 Nueva necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

28.2 EL programa phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . 350
28.2.1 Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
28.2.2 Reconfigurar Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
28.2.3 Probar el resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
28.3 Añadiendo seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
28.3.1 Autenticación básica . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
28.3.2 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

28.1 Nueva necesidad

El servidor Web de la Escuela de Informática ha crecido mucho. Distintas aplicaciones están

usando un gran volumen de datos y para ello se apoyan en un SGBD (MySQL). El administrador
realiza habitualmente varias operaciones de mantenimiento del sistema de base de datos: relanza el
servidor, crea nuevas bases de datos, hace backups, etc. Conforme los servicios ofrecidos han ido
aumentando, el trabajo de gestión de las bases de datos también lo ha hecho. Nuestra operativa
actual se basa en realizar la administración de manera remota (por medio de telnet), pero esta
forma de trabajar tiene algunas contraindicaciones:

No nos resulta cómodo trabajar con tablas de datos en modo texto.



Telnet no proporciona comunicación segura, un intruso podría tener acceso a datos privados
de las bases de datos.

349
350 CAPÍTULO 28. PHPMYADMIN. GESTIÓN WEB DE BASES DE DATOS MYSQL

¿No habrá alguna forma de administrar las BBDDs de manera remota, cómoda y “segura”?
Tras varios días de búsqueda por la Web encontramos phpMyAdmin (http://phpwizard.net/
projects/phpMyAdmin/), una aplicación en PHP que nos ofrece un interface Web para las bases
de datos MySQL. Esto parece ser justo lo que necesitamos y decidimos instalarlo.

28.2 EL programa phpMyAdmin

phpMyAdmin [89] es un programa Open-Source que implementa la administración Web de los

datos contenidos en un SGBD MySQL. Permite dos formas de funcionamiento:

El administrador controla un servidor MySQL completo. Para ello se debe abrir una
conexión con el SGBD identificándose como superusuario.

Los usuarios particulares administran sus propios datos. Para ello se establecerá una
conexión como usuario con permisos de lectura y escritura en la base de datos concreta.

28.2.1 Instalación

La instalación del programa es muy rápida, sólo requiere dos pasos:

1. Descomprimir el fichero con el código fuente en un directorio adecuado:

# cd /usr/local/proyecto/aplicaciones/myadmin/
# tar xvzf phpMyAdmin-2.2.0rc3-php.tar.gz
# cd phpMyAdmin-2.2.0rc3-php

2. Editar el fichero config.inc y establecer los valores necesarios de host, usuario y password
de la base de datos. Estableceremos los valores adecuados para conseguir acceso como
superususario, porque lo que pretendemos es administrar todas las bases de datos de manera
remota.

28.2.2 Reconfigurar Apache

phpMyAdmin es una aplicación PHP, por tanto para ejecutarla debemos tener un servidor Web
que soporte este lenguaje1 .

Una vez tenemos Apache preparado, podemos configurarlo (editando httpd.conf) para dar
acceso desde la URL http://www.ei.universidad.es/myadmin/ al directorio donde hemos
instalado el programa:
1 En un capítulo anterior se analiza como hacerlo (vea el capítulo 15 en la página 247).
28.2. EL PROGRAMA PHPMYADMIN 351

# Habilitar myadmin
<IfModule mod_alias.c>
# Alias del directorio de instalación
Alias /myadmin/ "/usr/local/proyecto/aplicaciones/myadmin/"
# Configuración de acceso al directorio
<Directory "/usr/local/proyecto/aplicaciones/myadmin/">
Options none
AllowOverride None
DirectoryIndex index.php
Order allow,deny
Allow from all
</Directory>
</IfModule>

Listado 28.1 Configuración de httpd.conf para uso de phpMyAdmin.

Por último se rearranca el servidor Web (apachectl restart) para que se activen los cambios
en la configuración.

28.2.3 Probar el resultado

Desde cualquier navegador Web podemos conectarnos a la URL http://www.ei.universidad.

es/myadmin/ y observar (figura 28.1) si el programa funciona de manera adecuada.

Figura 28.1: phpMyAdmin en funcionamiento.

352 CAPÍTULO 28. PHPMYADMIN. GESTIÓN WEB DE BASES DE DATOS MYSQL

phpMyAdmin nos presenta dos frames, a la izquierda el listado de todas las bases de datos de
MySQL y a la derecha distintos enlaces a documentación, cambio de idioma, creación de nuevas
bases de datos, etc.

28.3 Añadiendo seguridad

Tras un tiempo navegando por el sistema, estamos convencidos de proporciona una forma muy
cómoda de gestionar de manera remota el SGBD. Pero ¿es seguro?, desgraciadamente no. Los
datos sobre HTTP se transmiten en claro y ni siquiera estamos controlando el acceso a la URL
http://www.ei.universidad.es/myadmin/. Pero existen algunas soluciones.

28.3.1 Autenticación básica

Mediante autenticación básica se exige un login/password para el acceso a directorios con datos
relevantes2 . Para nuestro caso crearemos un usuario mysql que será el único con acceso al
directorio donde hemos instalado myadmin. Se utiliza la utilidad htpasswd:

# ./htpasswd -c /usr/local/proyecto/conf/controlacceso mysql

New password: **
Re-type new password: **
Adding password for user mysql

Además, como un sistema de seguridad añadido se puede establecer algún mecanismo de control
de acceso. Limitaremos el acceso por IP, ya que conocemos las IPs de los dos equipos desde los
que se realizan tareas de administración de la base de datos. Dentro del fichero de configuración
de Apache httpd.conf, indicamos las directivas necesarias para añadir la autenticación y control
de acceso:

# Habilitar myadmin
<IfModule mod_alias.c>
# Alias del directorio de instalación
Alias /myadmin/ "/usr/local/proyecto/aplicaciones/myadmin/"

# Configuración de acceso al directorio

<Directory "/usr/local/proyecto/aplicaciones/myadmin/">
Options none
AllowOverride None
DirectoryIndex index.php

2 En un capítulo anterior (vea la sección 16.2 en la página 254) se explica el concepto más en profundidad
28.3. AÑADIENDO SEGURIDAD 353

# Autenticación básica
AuthType Basic
AuthName "Acceso exclusivo a administrador MySQL"
AuthUserFile /usr/local/proyecto/conf/controldeacceso
Require user mysql

###################
# Control de acceso
###################
Order deny,allow
Deny from All
Allow from 127.0.0.1 193.147.87.211
</Directory>

</IfModule>

Listado 28.2 Configuración 1 httpd.conf para uso de phpMyAdmin.

28.3.2 SSL

Con los cambios de la sección anterior se consigue un cierto grado de seguridad, pero podemos
mejorarlo utilizando las capacidades SSL de Apache. Más información teórica sobre este tema
puede encontrarse en un capítulo anterior (vea la sección 5.2 en la página 78). También se le ha
dedicado un capítulo a la instalación práctica de SSL con Apache (vea la sección 18 en la página
267).

Se parte de un servidor con el soporte SSL activado, y se introducen algunos cambios en el fichero
de configuración, lo único necesario es incluir las mejoras de seguridad que se presentan en la
sección anterior dentro del servidor virtual que maneja las peticiones https:

<VirtualHost _default_:443>

# Se omiten muchas líneas de configuración

# de parámetros SSL

...

<IfModule mod_alias.c>
# Alias del directorio de instalación
354 CAPÍTULO 28. PHPMYADMIN. GESTIÓN WEB DE BASES DE DATOS MYSQL

Alias /myadmin/ "/usr/local/proyecto/aplicaciones/myadmin/"

# Configuración de acceso al directorio

<Directory "/usr/local/proyecto/aplicaciones/myadmin/">
Options none
AllowOverride None
DirectoryIndex index.php

# Autenticación básica
AuthType Basic
AuthName "Acceso exclusivo a administrador MySQL"
AuthUserFile /usr/local/proyecto/conf/controldeacceso
Require user mysql

# Control de acceso
Order deny,allow
Deny from All
Allow from 127.0.0.1 193.147.87.211
</Directory>
</IfModule>

</VirtualHost>

Listado 28.3 Configuración httpd.conf para uso de phpMyAdmin sobre SSL.

Y con esto por fin conseguimos cumplir los objetivos, hemos establecido un sistema para
administrar las BBDDs de manera remota, que a la vez es cómodo de manejar desde una
interface hipertexto basada en Web y bastante seguro si consideramos las tecnologías disponibles
actualmente.
 Parte IV

Conclusión y trabajos futuros

355
Conclusión y trabajos futuros

Conclusión

En esta memoria se cubren los aspectos más relevantes de la World Wide Web desde el punto de
vista de un Webmaster. Se ha pretendido dar una visión global de las tecnologías y servicios que
se pueden utilizar en un servidor Web o de aplicaciones, con pequeños ejemplos prácticos de las
mismas.

El tiempo dedicado a este proyecto ha permitido sacar varias conclusiones:

Las tareas de configuración y mantenimiento de un servidor Web actual no son triviales.



Existen multitud de tecnologías alternativas que pueden desempeñar el mismo trabajo.



El sector está creciendo muy deprisa, haciendo que algunos productos pasen a explotación,
cuando no son todo lo estables que deberían.

Trabajos futuros

Hay algunos trabajos futuros que resultarían interesantes:

Probar un poco más a fondo las posibilidades reales los servidores Web y de aplicaciones
del mercado, haciendo una comparativa completa de los mismos. En este proyecto, la base
de todos los ejemplos prácticos ha sido el servidor Web Apache (el de más difusión en la
actualidad), aunque también han sido probados algunos otros servidores (como Jigsaw o
Enhydra).


Seguir la evolución de las nuevas tecnologías asociadas a los servidores Web, manteniendo
siempre una visión global de todas ellas. Es un campo interesante y amplio, debido a la
velocidad con que aparecen nuevas soluciones.


Por último, hacer un estudio parecido al que se presenta en esta memoria pero aplicado al
lado cliente. Por ejemplo, podrían analizarse los clientes Web del mercado (navegadores,
gestores de download, etc.), tecnologías asociadas (JavaScript, Flash, etc.), ...

357
358
 Parte V

Apéndices

359
Apéndice A

El lenguaje HTML

A.1 Introducción

HTML (HyperText Markup Language) [46] es un lenguaje de marcado simple diseñado para crear
documentos de hipertexto independientes de la plataforma. HTML se deriva de otro lenguaje de
mucha mayor complejidad, el SGML (Standard Generalized Markup Language) que estandariza
el concepto de lenguaje de marcado definiendo las partes del documento y los tipos de etiquetas
que se utilizan para definir su composición. HTML incluye una gran cantidad de etiquetas, las
que determinan las partes de un documento (cabeceras, listas, etc.), las que permiten incrustar
objetos (imágenes, aplicaciones “applets” Java, etc.), las de petición de datos (formularios), etc.
Un navegador será capaz de interpretar estas etiquetas visualizando un documento correctamente
formateado. Por ejemplo:

Código HTML Navegador

<b>este texto está en negrita</b> este texto está en negrita

HTML se ha venido usando como el lenguaje estandard de la Web desde 1990, aunque la
primera especificación oficial (HTML 2.0) data de 1994. A continuación se resume brevemente la
historia1 :

HTML 2.0: [95] fue desarrollado por el IETF desde 1994 hasta 1996.

HTML 3.2: es la versión de HTML que recomendó el W3C en 1996, basándose en ciertas
características de HTML 2.0 y añadiendo características muy utilizadas como tablas,
applets, etc.
1 Si necesia más datos sobre esta historia, con algunas anécdotas de los comienzos de la Web, puede leerla en

http://www.w3.org/Markup/.

361
362 APÉNDICE A. EL LENGUAJE HTML

HTML 4.0: fue la siguiente recomendación del W3C, apareció en 1997. Incorpora algunas
características muy utilizadas (frames, etc.) y marca como obsoletas algunas otras (center.
etc.).

HTML 4.01: es la última versión de HTML y apareció en diciembre de 1999 para arreglar los
pequeños errores aparecidos en la especificación HTML 4.0.

XHTML: [128] es la más reciente recomendación del W3C sobre lenguajes de marcado y esta
llamado a sustituir a HTML. Básicamente es una reformulación en XML del lenguaje
HTML 4.01. En un capítulo anterior tratamos en más profundidad este lenguaje (vea la
sección 6.3 en la página 93).

A.2 Algunas etiquetas comunes en HTML

El listado de etiquetas es cambiante y varia en cada nueva versión de la especificación HTML. Esto
es una consecuencia lógica de la evolución de la Web, hay etiquetas que van quedando obsoletas
y otras que necesitan crearse para dar soporte a las nuevas necesidades de contenido. A modo de
ejemplo se presenta una tabla con las más significativas (tabla A.2):

Categoría Semántica
Comentarios <!--comentario -->
Estructura de documento <html> <head> <body> <title> <meta>
<h1> <h2> <h3> <h4> <h5> <h6>
<div> <span>
Párrafos y líneas <p><br>
Listas <ul> <li> <dl> <dt> <dd>
Tipos de letra <b> <font> <i> <b> <u> <sub> <sup>
Enlaces <a>
Imágenes <img>
Tablas <table> <tr> <th> <td> <caption>
Formularios <form> <input> <select> <option> <textarea>

Tabla A.1: Algunas categorías importantes de etiquetas HTML.

A.3 Formularios HTML

En este proyecto se dedican bastantes hojas a las tecnologías para conseguir presentaciones de
contenido dinámico en la Web. Todas ellas se apoyan en páginas codificadas con HTML. En
este sentido son especialmente importantes algunas etiquetas, los formularios, que se utilizan para
solicitarle al usuario la introducción de datos. Los formularios son básicos en las aplicaciones que
se construyen sobre la Web y por ello se comentan aquí de manera un poco más extensa.
A.3. FORMULARIOS HTML 363

Los formularios HTML no son más que la parte de una página Web delimitada por las etiquetas
<form>...</form>. La etiqueta de inicio <form> puede contener atributos:

enctype: esquema de codificación que van a utilizar los datos del formulario. El valor por defecto
es application/x-www-form-urlencoded, aunque existen otros como multipart/form-data.
Una formulario urlencoded se transmite codificado según el siguiente esquema:


Un espacio se sustituye con un signo mas (+).



Los campos de entrada se separan por un símbolo &.



Los caracteres no alfanuméricos se sustituyen por el código %xx (donde xx es el

código de carácter ASCII en formato hexadecimal).

action: especifica el programa CGI, JSP, etc. que se debe ejecutar para procesar el formulario en
el servidor.

method: indica la manera en la que se debe enviar la entrada del usuario. Existen dos métodos
básicos GET y POST.

A.3.1 Campos del formulario

Existe un grupo de etiquetas HTML que siempre deben aparecer dentro de un formulario. Son las
que especifican los diferentes campos:

La etiqueta <input> permite especificar un campo de entrada de distinto tipo según el

atributo type.

text: indica que el campo de entrada es una linea simple de texto.

<input type="text" name="nombredevariable"

value="valorpordefecto">

password: el campo de entrada es una linea simple de texto pero al escribir se oculta como
si fuese una contraseña.

<input type="password" name="nombredevariable"

value="valorpordefecto">

hidden: el campo de entrada es un valor que se pasa oculto en el código de la página,

permite almacenar información valida para el programa CGI en el formulario.

<input type="hidden" name="nombredevariable"

value="valorpordefecto">

checkbox: el campo de entrada es una casilla de verificación. Se usa para permitir al

usuario seleccionar múltiples opciones de un conjunto.
364 APÉNDICE A. EL LENGUAJE HTML

<input type="checkbox" name="nombredevariable"

value="valorpordefecto">

radio: el campo de entrada es una casilla de botón radio. Estos se usan para visualizar
distintas opciones de las cuales el usuario tendrá que elegir una.

<input type="radio" name="nombredevariable"

value="valorpordefecto">

submit: el campo de entrada es un botón de envio, al pulsarlo el formulario se envia al

servidor.

<input type="submit" name="nombredevariable"

value="etiquetadelboton">

reset: da lugar a un botón de reseteo, al pulsarlo el formulario se restaura a sus valores por
defecto.

<input type="reset" name="nombredevariable"

value="etiquetadelboton">

button: da lugar a un botón de acción programable por medio de lenguajes en el lado cliente
(por ejemplo javascript).

<input type="button" name="nombredevariable"

value="etiquetadelboton">


Elemento <textarea>...</textarea> se utiliza para los campos de texto de múltiples

líneas.

<textarea name="areatexto"> Contenido del area de texto aquí</TEXTAREA>

Etiquetas <select>, <option> se usan para crear listas de opciones.

<select name="nombrecampolista">
<option value="1">1</option>
<option value="2">2</option>
</select>

A.3.2 Ejemplo

Se presenta a continuación el código y la apariencia de un formulario sencillo.

<FORM METHOD="POST" ACTION="...">

Texto:<INPUT TYPE="text" NAME="texto">
<BR>
Lista:<SELECT NAME="lista">
A.3. FORMULARIOS HTML 365

<OPTION VALUE="1">1</OPTION>
<OPTION VALUE="2">2</OPTION>
</SELECT>
<BR>
Chequea:<INPUT TYPE="checkbox" NAME="chequear">
<BR>
Radio:
<INPUT TYPE="radio" NAME="radio1">
<INPUT TYPE="radio" NAME="radio2">
<BR>
Area de texto:<BR>
<TEXTAREA NAME="areatexto" ROWS="3" ></TEXTAREA>
<BR>
Botones<BR>
<INPUT TYPE="reset" VALUE="botonreset">
<INPUT TYPE="submit" NAME="submit">
<INPUT TYPE="reset" VALUE="boton">
</FORM>

Listado A.1 Un formulario sencillo en HTML.

que resulta con la apariencia de la figura (figura A.3.2).

Figura A.1: Un formulario sencillo en HTML.

366 APÉNDICE A. EL LENGUAJE HTML
Apéndice B

Dynamic Shared Objects en Apache

Este apéndice ha sido adaptado de la traducción hecha por el proyecto ApacheES [21] del documento
Soporte de Objetos Compartidos Dinámicos (Dynamic Shared Object - DSO)
Originalmente escrito por:
Ralf S. Engelschall <rse@apache.org>, Abril 1998

B.1 Algo de información

En los sucesores modernos de Unix existe un ingenioso mecanismo llamado carga/enlace dinámico
de Objetos Compartidos y Dinámicos (DSO), que proporciona un modo de construir un trozo de
código en un formato especial y que permite cargarlo en tiempo de ejecución en el espacio de
direcciones de un programa ejecutable.

Windows y NetWare proporcionan funcionalidades semejantes, aunque han sido implementadas

de una forma algo diferente que el método DSO de Unix que se describe en este documento. En
particular, los módulos DSO (DLL’s y NML’s respectivamente) se construyen de forma diferente
que en Unix. Este documento no pretende explorar el tema de la construcción de módulos DSO
en esas plataformas. Sin embargo la descripción de mod_so y su configuración son semejantes.

La carga del código puede hacerse de dos modos:

Automáticamente a través de un programa de sistema llamado ld.so que se encarga de cargar

el módulo una vez el programa ejecutable ha arrancado.

Manualmente desde dentro de un programa en ejecución por medio de interfaz al cargador

de Unix con llamadas al sistema de tipo dlopen()/dlsym().

367
368 APÉNDICE B. DYNAMIC SHARED OBJECTS EN APACHE

B.1.1 Carga automática, bibliotecas compartidas

Del primer modo los DSO son llamados bibliotecas compartidas o bibliotecas DSO y nombrados
como libfoo.so o libfoo.so.1.2. Residen en un directorio específico (generalmente
/usr/lib) y el enlace al programa ejecutable se establece en tiempo de compilación especificando
el parámetro -lfoo al enlazador (linker). Las bibliotecas así codificadas hacen referencia al
ejecutable, de modo que al arrancar el cargador de Unix es capaz de localizar libfoo.so en
/usr/lib1 . A partir de aquí resuelve cualquier símbolo en el programa ejecutable que esté
disponible en el DSO.

Los símbolos en el programa ejecutable normalmente no son referenciados desde el DSO (porque
es una biblioteca reutilizable de código general) y por tanto no se debe hacer ningún tipo de
resolución. El programa ejecutable no necesita hacer nada por su cuenta para utilizar los símbolo
de DSO porque la resolución completa la lleva a cabo el cargador de Unix. De hecho el código para
invocar ld.so, forma parte del código de arranque que es enlazado a cada programa ejecutable no
estático. La ventaja de la carga dinámica de código común de biblioteca es obvia: el código de
biblioteca necesita ser almacenado sólo una vez, ahorrando espacio en disco para cada programa.

B.1.2 Carga manual, objetos compartidos

Los DSO son normalmente llamados objetos compartidos o ficheros DSO y se les puede asignar
un nombre con cualquier extensión (aunque el nombre estándar es foo.so). Cuando se realiza la
carga de los módulo compartidos de forma manual, los ficheros DSO suelen permanecer dentro
de un directorio específico de cada programa y no se establece ningún link (enlace) automático
al programa ejecutable donde son usados. En lugar de esto, el programa ejecutable carga
manualmente el DSO en tiempo de ejecución a un espacio de direcciones por medio de dlopen().
En ese momento DSO realiza ninguna resolución de símbolos para el programa ejecutable. En
su lugar el cargador de Unix automáticamente resuelve cualquier símbolo en el DSO del conjunto
de símbolos exportados por el programa ejecutable y que ya ha sido cargado por las librerías
DSO (especialmente todos los símbolos de libc.so). De este modo DSO tiene conocimiento del
conjunto de símbolos del programa ejecutable como si hubiera sido enlazado estáticamente con él
desde el principio.

Finalmente, para aprovechar el API de DSO el programa ejecutable debe resolver símbolos
particulares de DSO a través de dlsym() , de esta forma podrán ser utilizados posteriormente
dentro de tablas enviadas etc. En otras palabras, el programa ejecutable debe resolver
manualmente cada símbolo que necesita a fin de poder utilizarlo. La ventaja de este mecanismo
es que las partes opcionales del programa no necesitan ser cargadas (y de este modo no gastan
memoria) hasta que el programa en cuestión las necesite. Cuando sean requeridos, estas partes del
programa pueden ser cargadas dinámicamente para extender la funcionalidad básica del programa.
1 O en otras rutas que se le pueden indicar al linker como un parámetro o por medio de la variable de entorno

LD_LIBRARY_PATH.
B.2. UTILIZACIÓN PRÁCTICA 369

Aunque este mecanismo del DSO parece sencillo, se da un paso difícil: la resolución de símbolos
desde el programa ejecutable para el DSO. ¿Porqué? Porque resolver de modo inverso símbolos
DSO desde el símbolo del programa ejecutable va en contra del diseño de la biblioteca (la
biblioteca no tiene conocimiento del programa que lo está usando) y ni está disponible en todas
las plataformas ni estandarizado. En la práctica los símbolos globales del programa ejecutable no
son a menudo reexportados y, de este modo, no están en disposición de ser usados en un DSO.
Cuando se usa DSO para extender un programa en tiempo de ejecución, el principal problema que
se debe resolver es encontrar un modo de forzar al enlazador para que exporte todos los símbolos
globales.

B.2 Utilización práctica

De las aproximaciones explicadas en el apartado anterior la más usual es la primera, y es usada

para casi todo tipo de bibliotecas que proporciona el sistema operativo. Por otro lado, también
se pueden usar objetos compartidos para extender un programa y no para ser usados por muchos
programas.

Hasta 1998 sólo había unos pocos paquetes disponibles que usaran el mecanismo DSO para
extender su funcionalidad en tiempo de ejecución: Perl 5 (por medio de su mecanismo XS y
el módulo DynaLoader), Netscape Server, etc. Empezando con la versión 1.3, Apache se unió al
grupo comenzando a usar el concepto de módulo para extender su funcionalidad.

B.3 Implementación

El soporte DSO para cargar módulos individuales de Apache está asentado en un módulo llamado
mod_so.c, que debe ser estáticamente compilado en el núcleo de Apache. Es el único módulo,
además de http_core.c, que no puede ser añadido a DSO por sí mismo, ya que forman parte
del bootstrapping (secuencia de instrucciones iniciales). Prácticamente todos los otros módulos
distribuidos de Apache pueden ser emplazados en DSO habilitando para ello el soporte DSO en
la construción de Apache2 . Después de que un módulo sea compilado en un DSO, por ejemplo,
mod_foo.so puede usarse el comando LoadModule en el fichero httpd.conf para cargar este
módulo cuando arranque el servidor.

Para simplificar la creación de ficheros DSO para módulos Apache (especialmente para módulos
de terceros) se dispone de un programa llamado apxs (APache eXtenSion). Se puede usar para
construir módulos DSO fuera del árbol fuente de Apache.

Para emplazar dentro de una biblioteca DSO el núcleo completo de Apache (sólo requerido
en algunas de las plataformas soportadas para forzar al enlazador a exportar los símbolos del
2 Usando configure -enable-shared. Para más información consulte el fichero INSTALL en el árbol de
instalación Apache.
370 APÉNDICE B. DYNAMIC SHARED OBJECTS EN APACHE

núcleo de Apache, un requisito para la modularización de DSO) se debe habilitar la regla

SHARED_CORE 3. En ese momento el código del núcleo es emplazado en una biblioteca DSO
llamada libhttpd.so. Ya que no se puede enlazar DSO con una librería estática en todas las
plataformas, se ha creado un programa ejecutable adicional llamado libhttpd.ep que enlaza
este código estático y provee de la función main(). Finalmente, el programa ejecutable httpd es
sustituido por una secuencia de instrucciones (bootstrapping) que automáticamente se asegura que
el cargador Unix sea capaz de cargar y arrancar libhttpd.ep pasándole LD_LIBRARY_PATH a
libhttpd.so.

B.4 Plataformas soportadas

El mecanismo DSO de Apache se apoya en las llamadas al sistema dlopen()/dlsym(). La

mayoría de las plataformas que proporcionan estas llamadas soportan los módulos DSO de
Apache. Apache 1.3.20 presenta a la siguiente lista como plataformas soportadas:

Linux SunOS UnixWare Darwin/Mac OS

FreeBSD Solaris AIX OpenStep/Mach
OpenBSD IRIX SCO DYNIX/ptx
NetBSD HPUX ReliantUNIX NetWare
BSDI Digital Unix DGUX Windows

B.5 Ventajas y desventajas

Las solución DSO proporcionada en Apache 1.3 tienen las siguientes ventajas:

El paquete del servidor es más flexible en tiempo de ejecución porque el proceso actual
del servidor puede ser ensamblado en tiempo de ejecución por medio de LoadModule en
httpd.conf en lugar de hacerlo por medio de la configuration en tiempo de compilación.
De este modo se pueden arrancar diferentes instancias del servidor (estándar, versión SSL,
mínima, versión potenciada [PHP, etc. ], etc.) con una única instalación de Apache.


El paquete del servidor puede ser fácilmente ampliado con módulos de terceros incluso
después de la instalación. Esto representa un gran beneficio para los que mantienen
paquetes, ya que les permite crear el paquete del núcleo de Apache y adicionalmente
paquetes que contengan extensiones como PHP, mod_perl, mod_fastcgi, ...

Mayor facilidad en los prototipos de módulos Apache porque con DSO y apxs se puede
trabajar fuera del árbol fuente de Apache y necesitar un único comando apxs -i seguido
3 Usando configure -enable-rule=SHARED_CORE. Para más información consulte el fichero INSTALL en el

árbol de instalación Apache.

B.5. VENTAJAS Y DESVENTAJAS 371

de un apachectl restart para cargar una nueva versión del módulo desarrollado en el
servidor Apache que esté funcionando actualmente.

Pero como todo, también tiene algunos inconvenientes:

El mecanismo DSO no puede ser usado en todas las plataformas porque no todos los
sistemas operativos soportan carga dinámica del código en el espacio de direcciones de
un programa.


El servidor es aproximadamente un 20% más lento en su arranque debido a la sobrecarga

que la resolución representa para el cargador (loader).


El servidor es aproximadamente un 5% más lento en su ejecución bajo algunas plataformas

porque el PIC (Position Independent Code, posición de código independiente) necesita
maniobras complicadas para direccionamiento dinámico, que no es necesariamente tan
rápido como el direccionamiento absoluto.


No se puede usar DSO para todo tipo de módulos, debido a que los módulos DSO no pueden
ser enlazados con otras bibliotecas basadas en DSO (ld -lfoo) en todas las plataformas4 . En
otras palabras, los módulos compilados como ficheros DSO están restringidos a utilizar sólo
símbolos del núcleo de Apache, de las biblioteca C (libc) y todas las demás bibliotecas
dinámicas o simbólicas usadas por el núcleo de Apache o desde archivos de bibliotecas
estáticas (libfoo.a) que contengan PIC. La única ocasión de usar otro código es, o bien
asegurarse de que el núcleo de Apache ya contenga una referencia a él, cargando uno mismo
el código por medio de dlopen(), o bien habilitando la regla SHARED_CHAIN cuando se
compila Apache y la plataforma soporta el enlace de ficheros DSO contra bibliotecas DSO.


Bajo algunas plataformas (varios sistemas SVR4) no hay forma de forzar al enlazador para
que exporte todos los símbolos globales cuando se enlaza el programa ejecutable httpd. Pero
sin la visibilidad de los símbolos del núcleo de Apache, ningún módulo estándar de Apache
podría ser usado como DSO. La única posible solución es compilar el sistema con la opción
SHARED_CORE porque de este modo los símbolos globales se fuerzan a ser exportados.

4 Por ejemplo las basadas en a.out normalmente no proporcionan esta funcionalidad, mientras las basadas en ELF sí.
372 APÉNDICE B. DYNAMIC SHARED OBJECTS EN APACHE
Apéndice C

Expresiones regulares

C.1 Introducción

Muchas directivas de configuración de Apache (<LocationMatch>, <DirectoryMatch>, etc.)

aceptan expresiones regulares. Una expresión regular es un patrón que describe cadenas de
caracteres, funcionan como los comodines (widcards) que se utilizan en los intérpretes de
comandos (shells), pero son más potentes. Se construyen combinando expresiones más pequeñas
mediante ciertos operadores hasta formar expresiones complejas.
El campo de las expresiones regulares es complejo y amplio, de hecho podría escribirse un libro
completo sobre ellas. Aquí símplemente haremos un pequeño repaso.

C.2 Nociones básicas

Circunflejo (^) y dólar ($) : son metacaracteres que concuerdan con la cadena vacía al comienzo
y al final de línea respectivamente. Por ejemplo:

#--------
# Concuerda con la palabra "inicio" al principio
# de una línea

^inicio

#--------
# Concuerda con la palabra "fin" al final de
# una línea

fin$

Punto (.) : concuerda con cualquier carácter simple excepto el salto de línea. Un ejemplo:

373
374 APÉNDICE C. EXPRESIONES REGULARES

#--------
# concuerda con cualquier palabra o frase que
# comienze por "t" y acabe por "i", por ejemplo
# txapi, te pregunto así, ...

t.*i

Operadores de repetición : existen unos cuantos operadores (tabla C.1) que provocan que una
expresión regular empareje con patrones construidos mediante repetición de caracteres.
Cualquier expresión regular que concuerde con un solo carácter puede ser seguida por uno
de estos varios operadores de repetición. Dos de los más conocidos son el asterisco * y
el interrogante ?. El asterisco empareja con el caracter precedente repetido 0 o más veces,
mientras el interrogante empareja con el caracter precedente repetido cero o una vez. Un
ejemplo:

#----------
# Concuerda con cualquier nombre del estilo
# pagina0.htm
# pagina01.htm
# ...
# (\d concuerda con cualquier número [0-9])

^pagina\d*.htm

#----------
# Puede concordar con la palabra "nota", si la
# "s" se repite 0 veces o con "notas" si se
# repite una vez.

^notas?

Patrón Semántica
? El elemento precedente puede aparecer 0 o 1 veces.
* El elemento precedente concordará cero o más veces.
+ El elemento precedente concordará una o más veces.
{n} El elemento precedente concuerda exactamente n veces.
{n,} El elemento precedente concuerda n o más veces.
{,m} El elemento precedente es opcional y concuerda como mucho m veces.
{n,m} El elemento precedente concuerda como poco n veces, pero no más de m veces.

Tabla C.1: Patrones de repetición en expresiones regulares.

C.2. NOCIONES BÁSICAS 375

Listas de caracteres : una lista de caracteres rodeados por [] concuerda con cualquier carácter
de esa lista. Se puede especificar un rango de caracteres ASCII dando el primero y el
último, separados por un guión. Si el primer carácter de la lista es ^, entonces concuerda
con la negación de los caracteres de la lista. También puede expresarse la alternancia
entre expresiones regulares de una lista mediante el operador infijo | . La expresión
regular resultante concuerda con cualquier cadena que concuerde con cualquiera de las
subexpresiones. Un ejemplo:

#----------
# concuerda con cualquier letra entre la "a" y la "z"

[a-z]

#----------
# concuerda con alguno de las letras "a", "i", "u"

[a|i|u]

#----------
# concuerda con cualquier caracter que no sea una letra
# de la "a" a la "z"

[^a-z]

Patrones predefinidos : también existen ciertas clases de patrones predefinidos1 (tabla C.2).

Puede encontrarse más información en la Web http://www.perl.com/CPAN-local/doc/

manual/html/pod/perlre.htnml, o simplemente consultando la ayuda man del comando grep.

1 Los corchetes son parte de los nombres de clases y no indican lista de caracteres.
376 APÉNDICE C. EXPRESIONES REGULARES

Patrón Semántica
[:alnum:] Alfanumérico [0-9A-Za-z]
[:digit:] Dígitos [0-9]
[:graph:] Cualquier caracter imprimible, menos los de
la clase [:space:]
[:lower:] Cualquier letra en minúsculas [a-z]
[:print:] Cualquier caracter imprimible
[:punct:] Cualquier signo de puntuación
[:space:] Cualquier caracter que deja espacio, es decir,
tabulado, tabulado vertical, salto de línea,
form feed, retorno de carro y espacio.
[:upper:] Cualquier letra en mayúscula.
[:xdigit:] Un dígito en hexadecimal [0-9A-Fa-f]
[:cntrl:] Cualquier expresión que no forme parte de las
clases anteriores

Tabla C.2: Clases predefinidas en expresiones regulares.

Apéndice D

Configuración por defecto del servidor

Apache

Más de la mitad de esta memoria se ha dedicado a explicar temas de configuración de Apache

(presentando listados parciales de directivas), sin embargo, el tema quedaría un poco cojo si no se
presentara en algún lugar un listado completo de un fichero de configuración httpd.conf. Incluir
este fichero ayuda a ubicar cada directiva en su sitio y además es una buena fuente de información
llena de comentarios (en inglés).

##
## httpd.conf -- Apache HTTP server configuration file
##

#
# Based upon the NCSA server configuration files originally by
# Rob McCool.
#
# This is the main Apache server configuration file. It contains
# the configuration directives that give the server its
# instructions. See <URL:http://www.apache.org/docs/> detailed
# information about the directives.
#
# Do NOT simply read the instructions in here without understanding
# what they do. They’re here only as hints or reminders. If you are
# unsure consult the online docs. You have been warned.
#
# After this file is processed, the server will look for and process
# /usr/local/proyecto/conf/srm.conf and then

377
378 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

# /usr/local/proyecto/conf/access.conf
# unless you have overridden these with ResourceConfig and/or
# AccessConfig directives here.
#
# The configuration directives are grouped into three basic sections:
# 1. Directives that control the operation of the Apache server
# process as a whole (the ’global environment’).
# 2. Directives that define the parameters of the ’main’ or ’default’
# server, which responds to requests that aren’t handled by a
# virtual host.
# These directives also provide default values for the settings
# of all virtual hosts.
# 3. Settings for virtual hosts, which allow Web requests to be sent
# to different IP addresses or hostnames and have them handled by
# the same Apache server process.
#
# Configuration and logfile names: If the filenames you specify for
# many of the server’s control files begin with "/" (or "drive:/"
# for Win32),# the server will use that explicit path. If the
# filenames do *not*
# begin with "/", the value of ServerRoot is prepended -- so
# "logs/foo.log" with ServerRoot set to "/usr/local/apache" will be
# interpreted by the server as "/usr/local/apache/logs/foo.log".
#

### Section 1: Global Environment

#
# The directives in this section affect the overall operation of
# Apache,
# such as the number of concurrent requests it can handle or where
# it can find its configuration files.
#

#
# ServerType is either inetd, or standalone. Inetd mode is only
# supported on Unix platforms.
#
ServerType standalone

#
# ServerRoot: The top of the directory tree under which the server’s
 379

# configuration, error, and log files are kept.

#
# NOTE! If you intend to place this on an NFS (or otherwise network)
# mounted filesystem then please read the LockFile documentation
# (available <URL:http://www.apache.org/docs/mod/core.html#lockfile>)
# you will save yourself a lot of trouble.
#
ServerRoot "/usr/local/proyecto/apache"

#
# The LockFile directive sets the path to the lockfile used when
# Apache is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or
# USE_FLOCK_SERIALIZED_ACCEPT. This directive should normally be left
# at its default value. The main reason for changing it is if the
# logs directory is NFS mounted, since the lockfile MUST BE STORED ON
# A LOCAL DISK. The PID of the main server process is automatically
# appended to the filename.
#
#LockFile /usr/local/proyecto/apache/logs/httpd.lock

#
# PidFile: The file in which the server should record its process
# identification number when it starts.
#
PidFile /usr/local/proyecto/apache/logs/httpd.pid

#
# ScoreBoardFile: File used to store internal server process
# information.
# Not all architectures require this. But if yours does (you’ll
# know because this file will be created when you run Apache)
# then you *must* ensure that no two invocations of Apache share
# the same scoreboard file.
#
ScoreBoardFile /usr/local/proyecto/apache/logs/httpd.scoreboard

#
# In the standard configuration, the server will process
# httpd.conf (this file, specified by the -f command line option),
# srm.conf, and access.conf in that order. The latter two files
# are now distributed empty, as it is
380 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

# recommended that all directives be kept in a single file for

# simplicity.
# The commented-out values below are the built-in defaults. You
# can have the server ignore these files altogether by using
# "/dev/null" (for Unix) or
# "nul" (for Win32) for the arguments to the directives.
#
#ResourceConfig conf/srm.conf
#AccessConfig conf/access.conf

ResourceConfig /dev/null
AccessConfig /dev/null

#
# Timeout: The seconds before receives and sends time out.
#
Timeout 300

#
# KeepAlive: Whether or not to allow persistent connections (more
# than one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited
# amount.
# We recommend you leave this number high, for maximum
# performance.
#
MaxKeepAliveRequests 100

#
# KeepAliveTimeout: Number of seconds to wait for the next
# request from the
# same client on the same connection.
#
KeepAliveTimeout 15
 381

#
# Server-pool size regulation. Rather than making you guess
# how many server processes you need, Apache dynamically
# adapts to the load it sees --- that is, it tries to maintain
# enough server processes to
# handle the current load, plus a few spare servers to handle
# transient load spikes (e.g., multiple simultaneous requests
# from a single Netscape browser).
#
# It does this by periodically checking how many servers are
# waiting for a request. If there are fewer than
# MinSpareServers, it creates a new spare. If there are more
# than MaxSpareServers, some of the spares die off. The default
# values are probably OK for most sites.
#
MinSpareServers 5
MaxSpareServers 10

#
# Number of servers to start initially --- should be a reasonable
# ballpark figure.
#
StartServers 5

#
# Limit on total number of servers running, i.e., limit on the number
# of clients who can simultaneously connect --- if this limit is ever
# reached, clients will be LOCKED OUT, so it should NOT BE SET TOO
# LOW.
# It is intended mainly as a brake to keep a runaway server from
# taking the system with it as it spirals down...
#
MaxClients 150

#
# MaxRequestsPerChild: the number of requests each child process is
# allowed to process before the child dies. The child will exit so
# as to avoid problems after prolonged use when Apache (and maybe the
# libraries it uses) leak memory or other resources. On most systems
# this isn’t really needed, but a few (such as Solaris) do have
# notable leaks
382 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

# in the libraries. For these platforms, set to something like 10000

# or so; a setting of 0 means unlimited.
#
# NOTE:
# This value does not include keepalive requests after the initial
# request per connection. For example, if a child process handles
# an initial request and 10 subsequent "keptalive" requests, it
# would only count as 1 request towards this limit.
#
MaxRequestsPerChild 0

#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, in addition to the default. See also the <VirtualHost>
# directive.
#
#Listen 3000
#Listen 12.34.56.78:80

#
# BindAddress: You can support virtual hosts with this option. This
# directive is used to tell the server which IP address to listen to.
# It can either contain "*", an IP address, or a fully qualified
# Internet domain name.
# See also the <VirtualHost> and Listen directives.
#
#BindAddress *

#
# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was built as
# a DSO you have to place corresponding ‘LoadModule’ lines at this
# location so the directives contained in it are actually available
# _before_ they are used.
# Please read the file README.DSO in the Apache 1.3 distribution for
# more details about the DSO mechanism and run ‘httpd -l’ for the
# list of already built-in (statically linked and thus always
# available) modules in your httpd binary.
#
# Note: The order in which modules are loaded is important. Don’t
 383

# change the order below without expert advice.

#
# Example:
# LoadModule foo_module libexec/mod_foo.so
LoadModule vhost_alias_module libexec/mod_vhost_alias.so
LoadModule env_module
LoadModule config_log_module
LoadModule mime_magic_module
LoadModule mime_module
LoadModule negotiation_module libexec/mod_negotiation.so
LoadModule status_module
LoadModule info_module
LoadModule includes_module
LoadModule autoindex_module
LoadModule dir_module
LoadModule cgi_module
LoadModule asis_module
LoadModule imap_module
LoadModule action_module
LoadModule speling_module
LoadModule userdir_module
LoadModule alias_module
LoadModule rewrite_module
LoadModule access_module
LoadModule auth_module
LoadModule anon_auth_module
LoadModule dbm_auth_module
LoadModule digest_module
LoadModule proxy_module
LoadModule cern_meta_module
LoadModule expires_module
LoadModule headers_module
LoadModule usertrack_module
LoadModule unique_id_module
LoadModule setenvif_module
libexec/mod_env.so
libexec/mod_log_config.so
libexec/mod_mime_magic.so
libexec/mod_mime.so
libexec/mod_status.so
libexec/mod_info.so
libexec/mod_include.so
libexec/mod_autoindex.so
libexec/mod_dir.so
libexec/mod_cgi.so
libexec/mod_asis.so
libexec/mod_imap.so
libexec/mod_actions.so
libexec/mod_speling.so
libexec/mod_userdir.so
libexec/mod_alias.so
libexec/mod_rewrite.so
libexec/mod_access.so
libexec/mod_auth.so
libexec/mod_auth_anon.so
libexec/mod_auth_dbm.so
libexec/mod_digest.so
libexec/libproxy.so
libexec/mod_cern_meta.so
libexec/mod_expires.so
libexec/mod_headers.so
libexec/mod_usertrack.so
libexec/mod_unique_id.so
libexec/mod_setenvif.so

#Reconstruction of the complete module list from all available

# modules (static and shared ones) to achieve correct module
# execution order. [WHENEVER YOU CHANGE THE LOADMODULE SECTION
# ABOVE UPDATE THIS, TOO]
ClearModuleList
384 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

AddModule mod_vhost_alias.c
AddModule mod_env.c
AddModule mod_log_config.c
AddModule mod_mime_magic.c
AddModule mod_mime.c
AddModule mod_negotiation.c
AddModule mod_status.c
AddModule mod_info.c
AddModule mod_include.c
AddModule mod_autoindex.c
AddModule mod_dir.c
AddModule mod_cgi.c
AddModule mod_asis.c
AddModule mod_imap.c
AddModule mod_actions.c
AddModule mod_speling.c
AddModule mod_userdir.c
AddModule mod_alias.c
AddModule mod_rewrite.c
AddModule mod_access.c
AddModule mod_auth.c
AddModule mod_auth_anon.c
AddModule mod_auth_dbm.c
AddModule mod_digest.c
AddModule mod_proxy.c
AddModule mod_cern_meta.c
AddModule mod_expires.c
AddModule mod_headers.c
AddModule mod_usertrack.c
AddModule mod_unique_id.c
AddModule mod_so.c
AddModule mod_setenvif.c

#
# ExtendedStatus controls whether Apache will generate "full"
# status information (ExtendedStatus On) or just basic
# information (ExtendedStatus Off) when the "server-status"
# handler is called. The default is Off.
#
#ExtendedStatus On
 385

### Section 2: ’Main’ server configuration

#
# The directives in this section set up the values used by the ’main’
# server, which responds to any requests that aren’t handled by a
# <VirtualHost> definition. These values also provide defaults for
# any <VirtualHost> containers you may define later in the file.
#
# All of these directives may appear inside <VirtualHost> containers,
# in which case these default settings will be overridden for the
# virtual host being defined.
#

#
# If your ServerType directive (set earlier in the ’Global
# Environment’ section) is set to "inetd", the next few directives
# don’t have any effect since their settings are defined by the
# inetd configuration. Skip ahead to the ServerAdmin directive.
#

#
# Port: The port to which the standalone server listens. For
# ports < 1023, you will need httpd to be run as root initially.
#
Port 80

ScriptLog /usr/local/proyecto/cgi-bin/cgi.log

#
# If you wish httpd to run as a different user or group, you must
# run httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run
# httpd as.
# . On SCO (ODT 3) use "User nouser" and "Group nogroup".
# . On HPUX you may not be able to use shared memory as nobody,
# and the suggested workaround is to create a user www and use
# that user.
# NOTE that some kernels refuse to setgid(Group) or semctl
# (IPC_SET)
# when the value of (unsigned)Group is above 60000;
# don’t use Group nobody on these systems!
386 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

#
User nobody
Group nobody

#
# ServerAdmin: Your address, where problems with the server should
# be e-mailed. This address appears on some server-generated
# pages, such as error documents.
#
ServerAdmin txapi@montsfortis.micasa.es

#
# ServerName allows you to set a host name which is sent back to
# clients for your server if it’s different than the one the
# program would get (i.e., use "www" instead of the host’s real
# name).
#
# Note: You cannot just invent host names and hope they work. The
# name you define here must be a valid DNS name for your host. If
# you don’t understand this, ask your network administrator.
# If your host doesn’t have a registered DNS name, enter its IP
# address here.
# You will have to access it by its address (e.g.,
# http://123.45.67.89/)
# anyway, and this will make redirections work in a sensible way.
#
# 127.0.0.1 is the TCP/IP local loop-back address, often named
# localhost. Your machine always knows itself by this address. If
# you use Apache strictly for local testing and development, you
# may use 127.0.0.1 as the server name.
#
#ServerName montsfortis.micasa.es

#
# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this directory,
# but symbolic links and aliases may be used to point to other
# locations.
#
DocumentRoot "/usr/local/proyecto/htdocs"
 387

#
# Each directory to which Apache has access, can be configured with
# respect to which services and features are allowed and/or disabled
# in that directory (and its subdirectories).
#
# First, we configure the "default" to be a very restrictive set of
# permissions.
#
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>

#
# Note that from this point forward you must specifically allow
# particular features to be enabled - so if something’s not working
# as you might expect, make sure that you have specifically enabled
# it below.
#

#
# This should be changed to whatever you set DocumentRoot to.
#
<Directory "/usr/local/proyecto/htdocs">

#
# This may also be "None", "All", or any combination of "Indexes",
# "Includes", "FollowSymLinks", "ExecCGI", or "MultiViews".
#
# Note that "MultiViews" must be named *explicitly* "Options All"
# doesn’t give it to you.
#
Options Indexes FollowSymLinks MultiViews Includes

#
# This controls which options the .htaccess files in directories
# can override. Can also be "All" or any combination of "Options",
# "FileInfo", "AuthConfig", and "Limit"
#
AllowOverride None
388 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

#
# Controls who can get stuff from this server.
#
Order allow,deny
Allow from all
</Directory>

#
# UserDir: The name of the directory which is appended onto a
# user’s home directory if a ~user request is received.
#
<IfModule mod_userdir.c>
UserDir disabled root public_html
</IfModule>

#
# Control access to UserDir directories. The following is an example
# for a site where these directories are restricted to read-only.
#
#<Directory /home/*/public_html>
# AllowOverride FileInfo AuthConfig Limit
# Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
# <Limit GET POST OPTIONS PROPFIND>
# Order allow,deny
# Allow from all
# </Limit>
# <LimitExcept GET POST OPTIONS PROPFIND>
# Order deny,allow
# Deny from all
# </LimitExcept>
#</Directory>

<Directory /home/*/public_html>
Options Indexes ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>

#
 389

# DirectoryIndex: Name of the file or files to use as a pre-written

# HTML directory index. Separate multiple entries with spaces.
#
<IfModule mod_dir.c>
DirectoryIndex index.html
</IfModule>

#
# AccessFileName: The name of the file to look for in each directory
# for access control information.
#
AccessFileName .htaccess

#
# The following lines prevent .htaccess files from being viewed by
# Web clients. Since .htaccess files often contain authorization
# information, access is disallowed for security reasons. Comment
# these lines out if you want Web visitors to see the contents of
# .htaccess files. If you change the AccessFileName directive above,
# be sure to make the corresponding changes here.
#
# Also, folks tend to use names such as .htpasswd for password
# files, so this will protect those as well.
#
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>

#
# CacheNegotiatedDocs: By default, Apache sends "Pragma: no-cache"
# with each document that was negotiated on the basis of content.
# This asks proxy servers not to cache the document. Uncommenting
# the following line disables this behavior, and proxies will be
# allowed to cache the documents.
#
#CacheNegotiatedDocs

#
# UseCanonicalName: (new for 1.3) With this setting turned on,
# whenever Apache needs to construct a self-referencing URL (a URL
390 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

# that refers back to the server the response is coming from) it

# will use ServerName and Port to form a "canonical" name. With
# this setting off, Apache will use the hostname:port that the
# client supplied, when possible. This also affects SERVER_NAME
# and SERVER_PORT in CGI scripts.
#
UseCanonicalName On

#
# TypesConfig describes where the mime.types file (or equivalent) is
# to be found.
#
<IfModule mod_mime.c>
TypesConfig /usr/local/proyecto/conf/mime.types
</IfModule>

#
# DefaultType is the default MIME type the server will use for a
# document if it cannot otherwise determine one, such as from
# filename extensions.
# If your server contains mostly text or HTML documents,
# "text/plain" is a good value. If most of your content is binary,
# such as applications or images, you may want to use
# "application/octet-stream" instead to keep browsers from trying
# to display binary files as though they are text.
#
DefaultType text/plain

#
# The mod_mime_magic module allows the server to use various hints
# from the contents of the file itself to determine its type. The
# MIMEMagicFile directive tells the module where the hint
# definitions are located.
# mod_mime_magic is not part of the default server (you have to add
# it yourself with a LoadModule [see the DSO paragraph in the Global
# Environment section], or recompile the server and include
# mod_mime_magic as part of the configuration), so it’s enclosed in
# an <IfModule> container.
# This means that the MIMEMagicFile directive will only be processed
# if the module is part of the server.
#
 391

<IfModule mod_mime_magic.c>
MIMEMagicFile /usr/local/proyecto/conf/magic
</IfModule>

#
# HostnameLookups: Log the names of clients or just their IP addresses
# e.g., www.apache.org (on) or 204.62.129.132 (off).
# The default is off because it’d be overall better for the net if
# people
# had to knowingly turn this feature on, since enabling it means that
# each client request will result in AT LEAST one lookup request to the
# nameserver.
#
HostnameLookups Off

#
# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a <VirtualHost>
# container, error messages relating to that virtual host will be
# logged here. If you *do* define an error logfile for a <VirtualHost>
# container, that host’s errors will be logged there and not here.
#
ErrorLog /usr/local/proyecto/apache/logs/error_log

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn

#
# The following directives define some format nicknames for use with
# a CustomLog directive (see below).
#
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
392 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

#
# The location and format of the access logfile (Common Logfile
# Format).
# If you do not define any access logfiles within a <VirtualHost>
# container, they will be logged here. Contrariwise, if you *do*
# define per-<VirtualHost> access logfiles, transactions will be
# logged therein and *not* in this file.
#
CustomLog /usr/local/proyecto/apache/logs/access_log common

#
# If you would like to have agent and referer logfiles,
# uncomment the following directives.
#
#CustomLog /usr/local/proyecto/apache/logs/referer_log referer
#CustomLog /usr/local/proyecto/apache/logs/agent_log agent

#
# If you prefer a single logfile with access, agent, and referer
# information
# (Combined Logfile Format) you can use the following directive.
#
#CustomLog /usr/local/proyecto/apache/logs/access_log combined

#
# Optionally add a line containing the server version and virtual host
# name to server-generated pages (error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of: On | Off | EMail
#
ServerSignature On

# EBCDIC configuration:
# (only for mainframes using the EBCDIC codeset, currently one of:
# Fujitsu-Siemens’ BS2000/OSD, IBM’s OS/390 and IBM’s TPF)!!
# The following default configuration assumes that "text files"
# are stored in EBCDIC (so that you can operate on them using the
# normal POSIX tools like grep and sort) while "binary files" are
# stored with identical octets as on an ASCII machine.
 393

#
# The directives are evaluated in configuration file order, with
# the EBCDICConvert directives applied before EBCDICConvertByType.
#
# If you want to have ASCII HTML documents and EBCDIC HTML documents
# at the same time, you can use the file extension to force
# conversion off for the ASCII documents:
# > AddType text/html .ahtml
# > EBCDICConvert Off=InOut .ahtml
#
# EBCDICConvertByType On=InOut text/* message/* multipart/*
# EBCDICConvertByType On=In application/x-www-form-urlencoded
# EBCDICConvertByType On=InOut application/postscript model/vrml
# EBCDICConvertByType Off=InOut */*

#
# Aliases: Add here as many aliases as you need (with no limit). The
# format is Alias fakename realname
#
<IfModule mod_alias.c>
#
# Note that if you include a trailing / on fakename then the
# server will
# require it to be present in the URL. So "/icons" isn’t aliased
# in this
# example, only "/icons/". If the fakename is slash-terminated,
# then the
# realname must also be slash terminated, and if the fakename
# omits the
# trailing slash, the realname must also omit it.
#
Alias /icons/ "/usr/local/proyecto/apache/icons/"

<Directory "/usr/local/proyecto/apache/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
394 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

#
# ScriptAlias: This controls which directories contain server
# scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as
# applications and
# run by the server when requested rather than as documents sent
# to the client.
# The same rules about trailing "/" apply to ScriptAlias
# directives as to Alias.
#
ScriptAlias /cgi-bin/ "/usr/local/proyecto/cgi-bin/"

#
# "/usr/local/proyecto/cgi-bin" should be changed to whatever
# your ScriptAliased
# CGI directory exists, if you have that configured.
#
<Directory "/usr/local/proyecto/cgi-bin">
AllowOverride None
Options None ExecCGI
Order allow,deny
Allow from all
</Directory>

</IfModule>
# End of aliases.

#
# Redirect allows you to tell clients about documents which used
# to exist in
# your server’s namespace, but do not anymore. This allows you to
# tell the
# clients where to look for the relocated document.
# Format: Redirect old-URI new-URL
#

#
# Directives controlling the display of server-generated
# directory listings.
#
 395

<IfModule mod_autoindex.c>

#
# FancyIndexing is whether you want fancy directory indexing
# or standard
#
IndexOptions FancyIndexing

#
# AddIcon* directives tell the server which icon to show for
# different
# files or filename extensions. These are only displayed for
# FancyIndexed directories.
#
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

AddIconByType (TXT,/icons/text.gif) text/*

AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe

AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
396 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

AddIcon /icons/blank.gif ^^BLANKICON^^

#
# DefaultIcon is which icon to show for files which do not
# have an icon explicitly set.
#
DefaultIcon /icons/unknown.gif

#
# AddDescription allows you to place a short description
# after a file in
# server-generated indexes. These are only displayed for
# FancyIndexed
# directories.
# Format: AddDescription "description" filename
#
#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz

#
# ReadmeName is the name of the README file the server will
# look for by
# default, and append to directory listings.
#
# HeaderName is the name of a file which should be prepended to
# directory indexes.
#
# If MultiViews are amongst the Options in effect, the server will
# first look for name.html and include it if found. If name.html
# doesn’t exist, the server will then look for name.txt and include
# it as plaintext if found.
#
ReadmeName README
HeaderName HEADER

#
# IndexIgnore is a set of filenames which directory indexing
# should ignore
# and not include in the listing. Shell-style wildcarding is
# permitted.
 397

#
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

</IfModule>
# End of indexing directives.

#
# Document types.
#
<IfModule mod_mime.c>

#
# AddEncoding allows you to have certain browsers
# (Mosaic/X 2.1+) uncompress
# information on the fly. Note: Not all browsers support this.
# Despite the name similarity, the following Add* directives
# have nothing
# to do with the FancyIndexing customization directives above.
#
AddEncoding x-compress Z
AddEncoding x-gzip gz tgz

#
# AddLanguage allows you to specify the language of a document.
# You can
# then use content negotiation to give a browser a file in a
# language
# it can understand.
#
# Note 1: The suffix does not have to be the same as the language
# keyword --- those with documents in Polish (whose net-standard
# language code is pl) may wish to use "AddLanguage pl .po" to
# avoid the ambiguity with the common suffix for perl scripts.
#
# Note 2: The example entries below illustrate that in quite
# some cases the two character ’Language’ abbreviation is not
# identical to the two character ’Country’ code for its country,
# E.g. ’Danmark/dk’ versus ’Danish/da’.
#
# Note 3: In the case of ’ltz’ we violate the RFC by using a
# three char
398 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

# specifier. But there is ’work in progress’ to fix this and get

# the reference data for rfc1766 cleaned up.
#
# Danish (da) - Dutch (nl) - English (en) - Estonian (ee)
# French (fr) - German (de) - Greek-Modern (el)
# Italian (it) - Korean (kr) - Norwegian (no)
# Portugese (pt) - Luxembourgeois* (ltz)
# Spanish (es) - Swedish (sv) - Catalan (ca) - Czech(cz)
# Polish (pl) - Brazilian Portuguese (pt-br) - Japanese (ja)
# Russian (ru)
#
AddLanguage da .dk
AddLanguage nl .nl
AddLanguage en .en
AddLanguage et .ee
AddLanguage fr .fr
AddLanguage de .de
AddLanguage el .el
AddLanguage he .he
AddCharset ISO-8859-8 .iso8859-8
AddLanguage it .it
AddLanguage ja .ja
AddCharset ISO-2022-JP .jis
AddLanguage kr .kr
AddCharset ISO-2022-KR .iso-kr
AddLanguage no .no
AddLanguage pl .po
AddCharset ISO-8859-2 .iso-pl
AddLanguage pt .pt
AddLanguage pt-br .pt-br
AddLanguage ltz .lu
AddLanguage ca .ca
AddLanguage es .es
AddLanguage sv .se
AddLanguage cz .cz
AddLanguage ru .ru
AddLanguage zh-tw .tw
AddLanguage tw .tw
AddCharset Big5 .Big5 .big5
AddCharset WINDOWS-1251 .cp-1251
AddCharset CP866 .cp866
 399

AddCharset ISO-8859-5 .iso-ru

AddCharset KOI8-R .koi8-r
AddCharset UCS-2 .ucs2
AddCharset UCS-4 .ucs4
AddCharset UTF-8 .utf8

# LanguagePriority allows you to give precedence to some languages

# in case of a tie during content negotiation.
#
# Just list the languages in decreasing order of preference.
# We have
# more or less alphabetized them here. You probably want to change.
#
<IfModule mod_negotiation.c>
LanguagePriority en da nl et fr de el it ja kr no pl pt pt-br
ru ltz ca es sv tw
</IfModule>

#
# AddType allows you to tweak mime.types without actually editing
# it, or to
# make certain files to be certain types.
#
# For example, the PHP 3.x module (not part of the Apache
# distribution - see
# http://www.php.net) will typically use:
#
#AddType application/x-httpd-php3 .php3
#AddType application/x-httpd-php3-source .phps
#
# And for PHP 4.x, use:
#
#AddType application/x-httpd-php .php
#AddType application/x-httpd-php-source .phps

AddType application/x-tar .tgz

#
# AddHandler allows you to map certain file extensions to
# "handlers",
# actions unrelated to filetype. These can be either built into the
400 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

# server
# or added with the Action command (see below)
#
# If you want to use server side includes, or CGI outside
# ScriptAliased directories, uncomment the following lines.
#
# To use CGI scripts:
#
#AddHandler cgi-script .cgi

#
# To use server-parsed HTML files
#
AddType text/html .shtml
AddHandler server-parsed .shtml

#
# Uncomment the following line to enable Apache’s send-asis HTTP
# file feature
#
#AddHandler send-as-is asis

#
# If you wish to use server-parsed imagemap files, use
#
#AddHandler imap-file map

#
# To enable type maps, you might want to use
#
#AddHandler type-map var

</IfModule>
# End of document types.

#
# Action lets you define media types that will execute a script
# whenever a matching file is called. This eliminates the need
# for repeated URL
# pathnames for oft-used CGI file processors.
# Format: Action media/type /cgi-script/location
 401

# Format: Action handler-name /cgi-script/location

#
AddHandler accion .acc
Action accion /cgi-bin/p1.pl
#
# MetaDir: specifies the name of the directory in which Apache can find
# meta information files. These files contain additional HTTP headers
# to include when sending the document
#
#MetaDir .web

#
# MetaSuffix: specifies the file name suffix for the file containing
# the
# meta information.
#
#MetaSuffix .meta

#
# Customizable error response (Apache style)
# these come in three flavors
#
# 1) plain text
#ErrorDocument 500 "The server made a boo boo.
# n.b. the single leading (") marks it as text, it does not
# get output
#
# 2) local redirects
#ErrorDocument 404 /missing.html
# to redirect to local URL /missing.html
#ErrorDocument 404 /cgi-bin/missing_handler.pl
# N.B.: You can redirect to a script or a document using
# server-side-includes.
#
# 3) external redirects
#ErrorDocument 402 http://some.other_server.com/subscription_info.html
# N.B.: Many of the environment variables associated with the original
# request will *not* be available to such a script.

#
# Customize behaviour based on the browser
402 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

#
<IfModule mod_setenvif.c>

#
# The following directives modify normal HTTP response behavior.
# The first directive disables keepalive for Netscape 2.x and
# browsers that
# spoof it. There are known problems with these browser
# implementations.
# The second directive is for Microsoft Internet Explorer 4.0b2
# which has a broken HTTP/1.1 implementation and does not properly
# support keepalive when it is used on 301 or 302 (redirect)
# responses.
#
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0
force-response-1.0

#
# The following directive disables HTTP/1.1 responses to browsers
# which
# are in violation of the HTTP/1.0 spec by not being able to grok a
# basic 1.1 response.
#
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0

</IfModule>
# End of browser customization directives

#
# Allow server status reports, with the URL of
# http://servername/server-status
# Change the ".your_domain.com" to match your domain to enable.
#
#<Location /server-status>
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .your_domain.com
 403

#</Location>

#
# Allow remote server configuration reports, with the URL of
# http://servername/server-info (requires that mod_info.c be loaded).
# Change the ".your_domain.com" to match your domain to enable.
#
#<Location /server-info>
# SetHandler server-info
# Order deny,allow
# Deny from all
# Allow from .your_domain.com
#</Location>

#
# There have been reports of people trying to abuse an old bug
# from pre-1.1 days. This bug involved a CGI script distributed
# as a part of Apache.
# By uncommenting these lines you can redirect these attacks to a
# logging script on phf.apache.org. Or, you can record them
# yourself, using the script support/phf_abuse_log.cgi.
#
#<Location /cgi-bin/phf*>
# Deny from all
# ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
#</Location>

#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
#<IfModule mod_proxy.c>
# ProxyRequests On

# <Directory proxy:*>
# Order deny,allow
# Deny from all
# Allow from .your_domain.com
# </Directory>

#
404 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE

# Enable/disable the handling of HTTP/1.1 "Via:" headers.

# ("Full" adds the server version; "Block" removes all
# outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
# ProxyVia On

#
# To enable the cache as well, edit and uncomment the
# following lines:
# (no cacheing without CacheRoot)
#
# CacheRoot "/usr/local/proyecto/apache/proxy"
# CacheSize 5
# CacheGcInterval 4
# CacheMaxExpire 24
# CacheLastModifiedFactor 0.1
# CacheDefaultExpire 1
# NoCache a_domain.com another_domain.edu joes.garage_sale.com

#</IfModule>
# End of proxy directives.

### Section 3: Virtual Hosts

#
# VirtualHost: If you want to maintain multiple domains/hostnames
# on your
# machine you can setup VirtualHost containers for them. Most
# configurations
# use only name-based virtual hosts so the server doesn’t need to
# worry about
# IP addresses. This is indicated by the asterisks in the
# directives below.
#
# Please see the documentation at
# <URL:http://www.apache.org/docs/vhosts/>
# for further details before you try to setup virtual hosts.
#
# You may use the command line option ’-S’ to verify your virtual host
# configuration.
 405

#
# Use name-based virtual hosting.
#
#NameVirtualHost *

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for requests without a known
# server name.
#
#<VirtualHost *>
# ServerAdmin webmaster@dummy-host.example.com
# DocumentRoot /www/docs/dummy-host.example.com
# ServerName dummy-host.example.com
# ErrorLog logs/dummy-host.example.com-error_log
# CustomLog logs/dummy-host.example.com-access_log common
#</VirtualHost>

Listado D.1 Configuración por defecto del servidor

Este listado incluye la configuración por defecto de un servidor Web Apache 1.3.20, en la versión
2.0 probablemente aparezcan multitud de cambios. La documentación más completa y actualizada
sobre las directivas puede encontrarse en el sitio http://httpd.apache.org/.
406 APÉNDICE D. CONFIGURACIÓN POR DEFECTO DEL SERVIDOR APACHE
Bibliografía

[1] Apache Web Server Administration & e-commerce Handbook.

Scott Hawkins. (2001).
Prentice Hall PTR.

[2] Core Servlets and Java Server Pages.

Marti Hall. (2000).
Prentice Hall PTR.

[3] Cryptography and network security: principles ans practice.

William Stallings. (1999).
Prentice Hall PTR. Second Edition.

[4] Edición especial Seguridad en Java.

Jamie Jaworski, Paul J. Perrone. (2001).
Pearson Educación S.A.

[5] Java 1.2 Al Descubierto.

Jamie Jaworski. (1999).
Prentice Hall.

[6] Linux Apache web server administration.

Charles Aulds. (2001).
Sybex.

[7] Modern Information Retrieval.

Ricardo Baeza-Yates, Berthier Ribero-Nieto. (1999).
ACM Press, Addison-Wesley.

[8] MySQL.
Paul Dubois. (2000).
New Riders Publishing.

[9] Servidor Apache al descubierto.

Rich Bowen, Ken Coar. (2000).
Pearson Educación S.A.

407
408 BIBLIOGRAFÍA

[10] Sistema de Información Empresarial basado en páginas Web.

Fernando González Fernández. ( Julio 2000).
PFC INX-52. LSI. Universidad de Vigo.

[11] Structured Generalized Markup Language and Interchange Format (ISO 8879)
(International Organization for Standardization, 1986.)
URLs

[12] Analog, una herramienta para análisis de logs.

http://www.analog.cx/

[13] Apache:ASP: una implementación de ASP para Apache.

http://www.apache-asp.org/

[14] Apache: servidor Web.

http://httpd.apache.org/

[15] Apache: Interfaces Gráficos de Usuario.

http://gui.apache.org/

[16] Apache: manual on-line de Apache 1.3.

http://httpd.apache.org/docs/

[17] Apache: módulos.

http://modules.apache.org

[18] Apache: zona de descarga.

http://httpd.apache.org/dist/

[19] Apache-SSL.
http://www.apache-ssl.org

[20] Apache Software Foundation.

http://www.apache.org/

[21] ApacheES, proyecto de traducción al español de la documentación de Apache.

http://quark.fe.up.pt/ApacheES/

[22] API JSP de Sun.

http://java.sun.com/products/jsp/

[23] API Servlet.

http://java.sun.com/products/servlet/

[24] BEA systems, distribuidor de WebLogic.

http://www.beasys.com/
BIBLIOGRAFÍA 409

[25] C embebido, módulo de Apache.

http://linux.medyatext.com.tr/apache/cint.html

[26] C++ embebido, módulo de Apache.

http://d-000631-pp.dhcp.fnal.gov/~onuchin/Carrot/

[27] Chili!soft: una implementación de ASP.

http://www.chilisoft.com

[28] Coldfusion, servidor de aplicaciones de Allaire-Macromedia.

http://www.macromedia.com/software/coldfusion/

[29] Coldfusion, modulo para Apache.

http://mod-fusion.indyhosting.net/

[30] Comanche, un GUI para Apache.

http://www.covalent.net/projects/comanche/

[31] Conversor de HTML a XHTML.

http://www.w3.org/People/Raggett/tidy/

[32] Comprehensive Perl Archive Network (CPAN).

http://www.cpan.org/

[33] Covalent Intrusion Detector: módulo de Apache.

http://www.covalent.net/products/intrusiondetector/

[34] Cronolog, programa para rotar logs de Apache.

http://www.ford-mason.co.uk/resources/cronolog/

[35] CyPay: módulo Apache.

http://www.cypay.com

[36] Debian.
http://www.debian.org/

[37] DOM API para XML.

http://www.w3.org/DOM/

[38] Enhydra, servidor de aplicaciones Open-Source.

http://www.enhydra.org

[39] Especificación CGI.

http://hoohoo.ncsa.uiuc.edu/cgi/

[40] Expat: un API C para parsers XML.

http://sourceforge.net/projects/expat/
410 BIBLIOGRAFÍA

[41] FastCgi, ejecución de código en servidor.

http://www.fastcgi.com

[42] Freshmeat, páginas con proyectos en código fuente open-source.

http://freshmeat.org

[43] FreshRpms, buscador de paquetes rpm.

http://freshrpms.net

[44] Generación de contenido dinámico para la Web: revisión, alternativas y soluciones Java..
Florentino Fernandez Riverola; Dpto. Informática; Universidad de Vigo (2001).
http://lsi2.ei.uvigo.es/proa/download/apuntes/ContenidoDinamico.zip

[45] Hotwired XSSI.

http://hotwired.lycos.com/webmonkey/99/10/stuff0a/

[46] HTML, versión actual.

http://www.w3.org/TR/html

[47] IETF, Internet Engeneering Task Force.

http://www.ietf.org

[48] Informix, sistema gestor de bases de datos.

http://www.informix.com

[49] InstantASP, una implementación de ASP.

http://www.halcyonsoft.com/

[50] iPlanet, servidor Web de Netscape-Sun.

http://www.iplanet.com/

[51] ISO: International Organization for Standaritation

http://www.iso.ch/iso/en/ISOOnline.frontpage

[52] Intrusion Detection: módulo de Apache.

http://yunus.hacettepe.edu.tr/~burak/mod\_id/

[53] Jakarta, proyecto de la Apache Software Foundation.

http://jakarta.apache.org

[54] Java de Sun.

http://java.sun.com

[55] JAXP: un API Java para parsers XML.

http://java.sun.com/xml/xml_jaxp.html

[56] JDBC driver para MySQL.

http://www.worldserver.com/mm.mysql/
BIBLIOGRAFÍA 411

[57] JDBC, página Web.

http://java.sun.com/products/jdbc/

[58] Jigsaw, servidor Web del W3C.

http://www.w3.org/Jigsaw

[59] Jive, un sistema de foros Web.

http://www.coolservlets.com/jive

[60] JSSE: API Java para sockets seguros.

http://java.sun.com/products/jsse/

[61] Linuxconf, un sistema general de administración gráfica.

http://www.solucorp.qc.ca/linuxconf/

[62] Lucene, un buscador Java.

http://www.lucene.com/

[63] Lutris, empresa patrocinadora del servidor de aplicaciones Enhydra.

http://www.lutris.com.

[64] Microsoft.
http://www.microsoft.com/

[65] Microsoft Data Universal Access.

http://www.microsoft.com/data/

[66] Microsoft Internet Information Server.

http://www.microsoft.com/windows2000/server/evaluation/features/web.asp

[67] Microsoft SQL Server.

http://www.microsoft.com/sql/default.asp

[68] Mason HQ, un módulos de Apache para embeber Perl.

http://www.masonhq.com/

[69] mod_backhand: módulo de Apache.

http://www.backhand.org/

[70] mod_dav: módulo de Apache.

http://www.lyra.org/greg/mod_dav/

[71] mod_redundancy: módulo de Apache.

http://www.ask-the-guru.com/

[72] mod_ssl: módulo de Apache.

http://www.modssl.org
412 BIBLIOGRAFÍA

[73] mod_throttle: módulo de Apache.

http://www.snert.com/Software/mod_throttle/

[74] ModCBroker: módulo de Apache.

http://www.gradsoft.com.ua/eng/Products/cbroker/cbroker.html

[75] Módulos XHTML.

http://www.w3.org/TR/xhtml-modularization/

[76] Mohawk, un GUI para Apache.

http://eunuchs.org/linux/Tkapache/

[77] mSQL, sistema gestor de bases de datos.

http://www.hughes.com.au

[78] MySQL, página Web.

http://www.mysql.com/

[79] NCSA HTTPd, servidor Web.

http://hoohoo.ncsa.uiuc.edu/

[80] Netscape manuales de tecnologías relacionadas.

http://developer.netscape.com/docs/manuals/

[81] Netcraft, mediciones de mercado.

http://www.netcraft.com

[82] Network World, comparativas de servidores Web.

http://www.nwfusion.com/

[83] OpenASP: una implementación de ASP.

http://www.activescripting.org

[84] OpenSSL.
http://www.openssl.org

[85] Oracle
http://www.oracle.com.

[86] Perl Apache: proyectos de integración de Perl y Apache.

http://perl.apache.org/

[87] Perl Embebed Engine, un módulos de Apache para embeber Perl.

http://pee.sourceforge.net/

[88] PHP: PHP Hypertext Preprocessor.

http://www.php.net/
BIBLIOGRAFÍA 413

[89] phpMyAdmin: un sistema de gestión para MySQL basado en PHP.

http://phpwizard.net/projects/phpMyAdmin/

[90] PostgreSQL, sistema gestor de bases de datos.

http://www.postgresql.org/

[91] Red Hat.

http://www.redhat.com/

[92] (RFC 1413) Identification protocol

http://www.ietf.org/rfc/rfc1413.txt
(Febrero 1993)

[93] (RFC 1847) Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
http://www.ietf.org/rfc/rfc1847.txt
(Octubre 1995)

[94] (RFC 1848) MIME Object Security Services

http://www.ietf.org/rfc/rfc1848.txt
(Octubre 1995)

[95] (RFC 1866) Hypertext Markup Language - 2.0

http://www.ietf.org/rfc/rfc1866.txt
(Febrero 1993)

[96] (RFC 1867) Form-based File Upload in HTML

http://www.ietf.org/rfc/rfc1867.txt
(Noviembre 1995)

[97] (RFC 1945) HTTP/1.0 Informational RFC

http://www.ietf.org/rfc/rfc1945.txt
(Mayo 1996)

[98] (RFC 2109) HTTP State Management Mechanism

http://www.ietf.org/rfc/rfc2109.txt
(Febrero 1997)

[99] (RFC 2045) Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies
http://www.ietf.org/rfc/rfc2045.txt
(Noviembre 1996)

[100] (RFC 2046) Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
http://www.ietf.org/rfc/rfc2046.txt
(Noviembre 1996)
414 BIBLIOGRAFÍA

[101] (RFC 2047) MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII Text
http://www.ietf.org/rfc/rfc2047.txt
(Noviembre 1996)

[102] (RFC 2048) Multipurpose Internet Mail Extensions (MIME) Part Four: Registration
Procedures
http://www.ietf.org/rfc/rfc2048.txt
(Noviembre 1996)

[103] (RFC 2049) Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance
Criteria and Examples
http://www.ietf.org/rfc/rfc2049.txt
(Noviembre 1996)

[104] (RFC 2145) Use and Interpretation of HTTP Version Numbers

http://www.ietf.org/rfc/rfc2145.txt
(Mayo 1997)

[105] (RFC 2396) Uniform Resource Identifiers (URI): Generic Syntax

http://www.ietf.org/rfc/rfc2296.txt
(Agosto 1998)

[106] (RFC 2518) HTTP Extensions for Distributed Authoring – WEBDAV

http://www.ietf.org/rfc/rfc2518.txt
(Febrero 1999)

[107] (RFC 2616) Hypertext Transfer Protocol – HTTP/1.1

http://www.ietf.org/rfc/rfc2616.txt
(Junio 1999)

[108] (RFC 2617) HTTP Authentication: Basic and Digest Access Authentication
http://www.ietf.org/rfc/rfc2617.txt
(Junio 1999)

[109] (RFC 2660) The Secure HyperText Transfer Protocol

http://www.ietf.org/rfc/rfc2660.txt
(Agosto 1999)

[110] RpmFind, buscador de paquetes rpm.

http://www.rpmfind.net

[111] SAX API para XML.

http://www.xml.org/xml/xmldev.shtml
BIBLIOGRAFÍA 415

[112] Security Space, mediciones de mercado.

http://www.securityspace.com/

[113] Server compare, comparativas de servidores.

http://webcompare.internet.com/

[114] Server Watch, listado y características de servidores.

http://serverwatch.internet.com/

[115] Server Side JavaScript.

http://developer.netscape.com/docs/manuals/js/server/jsref/index.htm

[116] Segure Sockets Layer: Especificación SSL v3.

http://home.netscape.com/eng/ssl3/

[117] SHTTP: artículo “An Overview of SHTTP”.

http://www.homeport.org/~adam/shttp.html

[118] SOAP: especificación.

http://www.w3.org/TR/soap12/

[119] SourceForge, páginas con proyectos en código fuente open-source.

http://sourceforge.net/

[120] Sybase
http://www.sybase.com.

[121] Thawte: Autoridad Certificadora.

http://www.thawte.com

[122] UDMSearch, un buscador de código libre.

http://mysearch.udm.net/

[123] Utilización de técnicas de recuperación de información para búsquedas en la Web..

Manuel J. Maña López; Dpto. Informática; Universidad de Vigo (2001).
http://couso.ei.uvigo.es/cursoWeb/presentaciones/Pres_Mmaña.pdf

[124] Validador de código XHTML.

http://validator.w3.org/check/referer

[125] Verisign: Autoridad Certificadora.

http://www.verisign.com

[126] Webmin, un sistema general de administración gráfica.

http://www.webmin.com/webmin/

[127] W3C: WWW Consortium.

http://www.w3.org
416 BIBLIOGRAFÍA

[128] XHTML
http://www.w3.org/MarkUp/

[129] XML Apache.

http://xml.apache.org/

[130] XML: El futuro del Web

Francisco Rodriguez; Dpto. Informática; Universidad de La Coruña (2001).
http://couso.ei.uvigo.es/cursoWeb/resumenes/pdf/FJrodriguez.pdf

[131] XML: Extensible Markup Language 1.0 (Recomendación W3C)

http://www.w3.org/TR/2000/REC-xml-20001006
(Second Edition)

[132] Zend Technologies, Ltd. Socio desarrollador de PHP.

http://www.zend.com/.

[133] Zeus Technologies, distribuidor de servidor Web Zeus.

http://www.zeustechnology.com/.
Índice de Materias
Símbolos
.htaccess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
/etc/group. . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
/etc/ld.so.conf . . . . . . . . . . . . . . . . . . . . . . . . 247
/etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . 254
/etc/profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
/etc/rc.d/init.d/tomcat . . . . . . . . . . . . . . . . . 242
<? código PHP ?> . . . . . . . . . . . . . . . . . . . . . 65
<?php código PHP ?> . . . . . . . . . . . . . . . . . . 65
<?phpinfo()?>. . . . . . . . . . . . . . . . . . . . . . . . 251
<Directory>, directiva Apache . . . . . . . . . 183
<DirectoryMatch>, directiva Apache . . . 183
<Files>, directiva Apache . . . . . . . . . . . . . 183
<FilesMatch>, directiva Apache . . . . . . . 184
<IfModule>, directiva Apache. . . . . 152, 160
<Limit>, directiva Apache . . . . . . . . . . . . . 185
<LimitExcept>, directiva Apache . . . . . . 185
<Location>, directiva Apache . . . . . . . . . . 185
<LocationMatch>, directiva Apache . . . . 186
<META NAME=ROBOTS ...> . . . . . . . . 122
<VirtualHost, directiva Apache . . . . . . . . 218
<VirtualHost>, directiva Apache . . . . . . . 187
<% etiqueta ASP %> . . . . . . . . . . . . . . . . . . 72
<% scriptlet JSP %> . . . . . . . . . . . . . . . . . . . 61
<%= expresión JSP %> . . . . . . . . . . . . . . . . 62
<%!declaración JSP %> . . . . . . . . . . . . . . . . 61
<%@directiva JSP [atributo =valor] %> . 61
<!--#config --> . . . . . . . . . . . . . . . . . . . . . . . . 54
<!--#echo -->, directiva XSSI . . . . . . . . . . . 54
<!--#exec -->, directiva XSSI . . . . . . . . . . . 55
<!--#flastmod -->, directiva XSSI . . . . . . . 56
<!--#fsize -->, directiva XSSI . . . . . . . . . . . 55
<!--#include -->, directiva XSSI . . . . . . . . 56
<!--#parse_form -->, directiva HW XSSI 58
417
<!--#printenv -->, directiva XSSI . . . . . . . 57
<!--#random -->, directiva HW XSSI . . . . 58
<!--#set -->, directiva XSSI . . . . . . . . . . . . 57
<form>, etiqueta HTML . . . . . . . . . . . 36, 362
<jsp:accion JSP ... > . . . . . . . . . . . . . . . . . . . 62
A
access.conf . . . . . . . . . . . . . . . . . . . . . . 151, 210
access_log . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
AccessConfig, directiva Apache . . . . . . . . 151
AccessFileName, directiva Apache . . . . . 158
ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Action, directiva Apache . . . . . . . . . . . . . . 233
Active Server Pages . . . . . . . . . . . . véase ASP
AddCharset, directiva Apache . . . . . . . . . 188
AddEncoding, directiva Apache . . . . . . . . 189
AddHandler, directiva Apache . . . . . 227, 233
AddIcon, directiva Apache . . . . . . . . . . . . 174
AddIconByEncoding, directiva Apache . 175
AddIconByType, directiva Apache . . . . . 176
AddLanguage, directiva Apache . . . . . . . 190
AddModule, directiva Apache . . . . . . . . . 159
AddType, directiva Apache . . . . . . . 191, 227
ADO, Active Data Objects . . . . . . . . . 72, 114
AJP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Alias, directiva Apache . . . . . . . . . . . . . . . 181
Allow, directiva Apache . . . . . . . . . . 200, 259
AllowOverride, directiva Apache . . 151, 201
Analizador sintáctico XML . . . . véase Parser
XML
Analog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
configuración. . . . . . . . . . . . . . . . 286–291
analog.cfg . . . . . . . . . véase analog.cfg
analog.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
418
Apache
2.0
APR . . . véase APR, Apache Portable
Run-Time
MPM . . . . . . . . . . . . . . . . . véase MPM,
Multiple-Processing Modules
APACI . . . . . . . . . . . . . . . . . véase APACI
config.status. . . . . . . .véase config.status
Configuration . . . . . véase Configuration
Configuration.tmpl. . . . . . . . . . . . . . véase
Configuration.tmpl
Directivas . . . . . . . . . . . . . . . . . . . 152–210
Ficheros de configuración . . . . . . . . . 151
.htaccess . . . . . . . . . . . . véase .htaccess
access.conf . . . . . . . véase access.conf
httpd.conf . . . . . . . . . . véase httpd.conf
magic . . . . . . . . . . . . . . . . . véase magic
mime.types . . . . . . . véase mime.types
server.crt . . . . . . . . . . . . véase server.crt
server.csr . . . . . . . . . . . véase server.csr
server.key . . . . . . . . . . véase server.key
srm.conf . . . . . . . . . . . . véase srm.conf
Ficheros de log
access_log. . . . . . . . . véase access_log
Common log format . véase Common
log format
error_log . . . . . . . . . . . véase error_log
GUI
Comanche . . . . . . . . . véase Comanche
Linuxconf . . . . . . . . . véase Linuxconf
Mohawk . . . . . . . . . . . . véase Mohawk
Webmin . . . . . . . . . . . . . véase Webmin
httpd.pid . . . . . . . . . . . . . . véase httpd.pid
instalación básica. . . . . . . . . . . . . . . . .133
Módulos. . . . . . . . . . . . . . . . . . . . . . . . . 152
Seguridad
Apache-SSL . . . . . véase Apache-SSL
mod_ssl . . . . . véase mod_ssl, módulo
Apache
otros . . . . . . . . . . . . . . . véase Seguridad
Utilidades
ÍNDICE DE MATERIAS
apachectl . . . . . . . . . . . véase apachectl
apxs . . véase apxs, APache eXtenSion
Configure . . . . . . . . . . véase Configure
configure . . . . . . . . . . . véase configure
dbmmanage . . . . . . véase dbmmanage
htdigest . . . . . . . . . . . . . . véase htdigest
htpasswd . . . . . . . . . . . véase htpasswd
httpd . . . . . . . . . . . . . . . . . . . véase httpd
Apache-SSL . . . . . . . . . . . . . . . . . . . . . . . . . 267
Apache:ASP . . . . . . . . . . . . . . . . . . . . . . . . . . 73
apachectl. . . . . . . . . . . . . . . . . . . . . . . . 144, 147
APACI . . . . . . . . . . . . . . . . . . . . . 137, 230, 271
APR, Apache Portable Run-Time . . . . . . . 12
apxs, APache eXtenSion . . . . . . . . . . . . . . 140
ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72–75
acceso a datos. . . . . . . . . . . . . . . . . . . . 116
Implementaciones
Apache:ASP . . . . . véase Apache:ASP
Chili!Soft . . . . . . . . . . véase Chili!Soft
InstantASP . . . . . . . . véase InstantASP
OpenASP . . . . . . . . . . véase OpenASP
Autenticación . . 32, 104, 126, 253, 330, 352
Autentificación . . . . . . . . véase Autenticación
AuthDBGroupFile, directiva Apache . . . 256
AuthDBUserFile, directiva Apache . . . . . 256
AuthDigestDomain, directiva Apache . . 258
AuthDigestFile, directiva Apache . . . . . . 258
AuthGroupFile, directiva Apache . . . . . . 254
AuthName, directiva Apache . . . . . . . . . . 254
AuthType, directiva Apache . . . . . . . . . . . 254
AuthUserFile, directiva Apache . . . . . . . . 254
Autorización . . . . . . . . . . . . . . . . . . . . . . . . . 253
B
Búsqueda Web . . . . . . . . . . . . . . . . . . . 120–124
Configuración . . . . . . véase UDMSearch
Estándar de exclución de robots . . véase
Estándar de exclución de robots
Extracción de raices . . véase Extracción
de raices
Indexador . . . . . . . . . . . . véase Indexador
ÍNDICE DE MATERIAS
Listas de parada . véase Listas de parada
Motor de búsqueda . . . . véase Motor de
búsqueda
Robot . . . . . . . . . . . . . . . . . . . véase Robot
Balanceo de carga . . . . . . . . . . . . . . . . . . . . 294
Bases de datos . . . . . . . . . . . . . . . . . . . 108–120
ADO . véase ADO, Active Data Objects
JDBC . . . . . . . . . . . . . . . . . . . véase JDBC
LiveWire . . . . . . . . . . . . . véase LiveWire
ODBC . . . . . . . . . . . . . . . . . . véase ODBC
Perl:DBI . . . . . . . . . . . . . . véase Perl:DBI
Productos
Informix . . . . . . . . . . . . véase Informix
mSQL . . . . . . . . . . . . . . . . véase mSQL
MySQL . . . . . . . . . . . . . véase MySQL
Oracle . . . . . . . . . . . . . . . . véase Oracle
SQL Server . . . . . . . véase SQL Server
Sybase . . . . . . . . . . . . . . . véase Sybase
Propiedades ACID . . . . . . . . véase ACID
SGBDR . . . . . . . . . . . . . . . véase SGBDR
SQL . . . . . . . . . . . . . . . . . . . . . . véase SQL
biblioteca jk . . . . . . . . . . . . . . . . . . . . . . . . . 243
BindAddress, directiva Apache . . . . . . . . 205
Bitácora . . . . . . . . . . . . . . . . . . . . . . . véase Log
BrowserMatch, directiva Apache . . . . . . . 207
BrowserMatchNoCase, directiva Apache207
C configuración. . . . . . . . . . . . . . . . 285–286
C, C++ embebido. . . . . . . . . . . . . . . . . . . . . . 75
Código embebido . . . . . . . . . . . . . . . . . . 52–76
ASP . . . . . . . . . . . . . . . . . . . . . . véase ASP
HotWired XSSI . véase HotWired XSSI
JSP . . . . . . . . . . . . . . . . . . . . . . . . véase JSP
JSSI . . . . . . . . . . . . . . . . . . . . . . véase JSSI
Mason HQ . . . . . . . . . . véase Mason HQ
Perl embebido . . . . . . . . véase PEE, Perl
Embebed Engine
PHP . . . . . . . . . . . . . . . . . . . . . . véase PHP
SSI . . . . . . . . . . . . . . . . . . . . . . . . véase SSI
Caché . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33, 295
CERN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
419
CFML, ColdFusion Markup Language . . 15,
76
CGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36–43
configuración . . . . . . 228–236, 313, 323
nph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Chili!Soft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Cipher method protocol . . . . . . . . . . . . . . . . 81
CLASSPATH, variable de entorno. . . . . . 239
ClearModuleList, directiva Apache . . . . . 159
cliente/servidor . . . . . . . . . . . . . . . . . 6, 21, 109
Cocoon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Comanche . . . . . . . . . . . . . . . . . . . . . . . . 12, 297
Common log format . . . . . . . . . . . . . . . . . . 126
config.status . . . . . . . . . . . . . . . . . . . . . . . . . 138
config_log_module, módulo Apache . . . 280
Configuration . . . . . . . . . . . . . . . . . . . . . . . . 136
Configuration.tmpl . . . . . . . . . . . . . . . . . . . 136
Configure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
configure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Content-type . . . . . . . . . . . . . . . . . . . . . . . . . . 41
CONTENT_LENGTH, variable de entorno
CGI . . . . . . . . . . . . . . . . . . . . . . . . . . 38
CONTENT_TYPE, variable de entorno CGI
38
Control ancho de banda . . . . . . . . . . . . . . . 294
Control de acceso . . . . . . . . . . . . . . . . . . . . 253
Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
CookieTracking, directiva Apache . . . . . . 285
CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Covalent Intrusion Detector, módulo Apache
295
CRL, Certificate Revocation Lists . . . . . . 273
cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Cronolog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
configuración. . . . . . . . . . . . . . . . 283–285
utilidades
cronolog . . . . . . . . . . . . . . . . . . . . . . 284
cronosplit . . . . . . . . . . . . . . . . . . . . . 284
CSR, Certificate Signing Requests . . . . . 273
CSS, Cascading Style Sheets . . . . . . . . . . . 94
420
CustomLog, directiva Apache. . . . . . . . . . 195
CyPay, módulo Apache . . . . . . . . . . . . . . . 296
D Extracción de raíces . . . . . . . . . . . . . . 123, 336
DAV, directiva Apache . . . . . . . . . . . . . . . . 263
DAVDepthInfinity, directiva Apache . . . . 264
DAVLockDB, directiva Apache . . . . . . . . 263
DAVMinTimeout, directiva Apache . . . . 264
dbmmanage . . . . . . . . . . . . . . . . . . . . . . . . . . 256
DCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
DefaultIcon, directiva Apache . . . . . . . . . 176
DefaultType, directiva Apache . . . . . . . . . 192
Deny, directiva Apache. . . . . . . . . . . . . . . . 259
DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79, 82
Detección de intrusos . . . . . . . . . . . . . . . . . 294
Diffie - Hellman . . . . . . . . . . . . . . . . . . . . . . . 79
DirectoryIndex, directiva Apache . . . . . . 177
dkpg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Documento bien formado. . . . . . . . . . . . . . . 90
Documento válido . . . . . . . . . . . . . . . . . . . . . 90
DocumentRoot, directiva Apache . . . . . . 160
DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
DSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
DSO, Dynamic Shared Objects . . . . . . . . 135,
367–371
DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Dynamic virtual hosts . . . . . . . . . . . . . . . . . 221
E Formularios . . . . véase <form>, etiqueta
EAPI . . . . . . . . . . . . . . . . . . . . . . . 135, 244, 270
Ejecutar programas externos . . . . . . . . . . . . 35
CGI . . . . . . . . . . . . . . . . . . . . . . . véase CGI
FastCGI . . . . . . . . . . . . . . . véase FastCGI
ISAPI . . . . . . . . . . . . . . . véase ISAPI API
mod_perl . . . . . véase mod_perl, módulo
Apache
NSAPI . . . . . . . . . . . . . véase NSAPI API
Servlets . . . . . . . . . . . . . . . . véase Servlets
Error protocol . . . . . . . . . . . . . . . . . . . . . . . . . 81
error_log . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
ÍNDICE DE MATERIAS
ErrorLog, directiva Apache . . . . . . . . . . . . 196
Estándar de exclusión de robots . . . 122, 334
Expat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
F
FancyIndexing . . . . . . . . . . . . . . . . . . . 174, 312
FastCGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Fortezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
FrontPage . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
G
Gestión de recursos remotos . . . . . . 101–104
FrontPage . . . . . . . . . . . . véase FrontPage
Group, directiva Apache . . . . . . . . . . 164, 213
gzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
H
Handshake protocol. . . . . . . . . . . . . . . . . . . . 80
HeaderName, directiva Apache . . . . . . . . 178
Hiperenlaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Hipertexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
HolaMundo.java. . . . . . . . . . . . . . . . . . . . . . 240
HostNameLookups, directiva Apache . . . 197
Hotwired XSSI . . . . . . . . . . . . . . . . . . . . . . . . 58
htdigest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
HTML, HyperText Markup Language . . . 88
HTML, Hypertext Markup Language . . 361–
365
HTML
XHTML . . . . . . . . . . . . . . véase XHTML
htpasswd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
HTTP
Authentication. . . . . . . . . . . . . véase RFC
2617, HTTP Authentication: Basic
and Digest Access Authentication
Códigos de estado . . . . . . . . . . . . . . . . . 24
Conexiones persistentes . . . . . . . . . véase
Keep-Alive
Encabezados . . . . . . . . . . . . . . . . . . . . . . 25
ÍNDICE DE MATERIAS
Hosts virtuales . . . . . véase Virtual hosts
HTTP/0.9 . . . . . . . . . . . . véase HTTP/0.9
HTTP/1.0 . .véase RFC 1945, HTTP/1.0
Métodos . . . . . . . . . . . . . . . . . . . . . . . . . . 22
GET . . . . . . . . . . . . véase Método GET
HEAD . . . . . . . . véase Método HEAD
POST . . . . . . . . . . véase Método POST
Negociación de contenido . . . . . . . véase
Negociación de contenido
State Management Mechanism . . . véase
RFC 2019, HTTP State
Management Mechanism
Version Numbers véase RFC 2145, Use
and Interpretation of HTTP Version
Numbers
HTTP seguro . . . . . . . . . . . . . . . . . . . . . . 77–86
configuración. . . . . . . . . . . . . . . . 267–277
HTTPS . . . . . . . . . . . . . . . . .véase HTTPS
S-HTTP . . . . . . . . . . . . . . . véase S-HTTP
HTTP, Hypertext Transfer Protocol . . 19–33
HTTP/0.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
httpd. . . . . . . . . . . . . . . . . . . . . . . . . . . . 144, 145
httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
httpd.pid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
HTTPS . . . . . . . . . . . . . . . . . . . . . . . 83–84, 276
I Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
IANA, Internet Asigned Numbers Authority
28
Idea. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79, 82
IMT, Internet Media Types . . . . véase MIME
Include, directiva Apache . . . . . . . . . . . . . 244
Indexador. . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Indexes, directiva Apache . . . . . . . . . . . . . 213
IndexIgnore, directiva Apache . . . . . . . . . 178
IndexOptions, directiva Apache . . . . . . . . 179
Informix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
InstantASP. . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Intrusion Detection, módulo Apache. . . . 294
Ip-based virtual hosts . . . . . . . . . . . . . . . . . 217
421
ISAPI API . . . . . . . . . . . . . . . . . . . . . . . . . 49, 72
ISO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
J
J2EE, Java 2 Enterprise Edition . . . . . . . . . . 8
J2SDK, Java 2 Development Kit . . . . . . . 238
Jakarta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
JAVA_HOME, variable de entorno . . . . . 239
JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Client Side . . . . . . . . . . . . . . . . . . . . . . . . 53
Server Side . . . . . . . . . . . . . . . . . . . . . . . 75
JAXP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
aplicación . . . . . . . . . . . . . . . . . . . . . . . 344
JDK . . . . . . . . . . . . . . . . . . . . . . . . véase J2SDK
Jive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
JNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
JSP, Java Server Pages . . . . . . . . . . . . . . 59–64
acceso a datos. . . . . . . . . . . . . . . . . . . . 118
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
aplicación . . . . . . . . . . . . . . . . . . . . . . . 344
JSSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
JSSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
JVM . . . . . . . . . . . . . . . . . . . . . . . véase J2SDK
K
KeepAlive, directiva Apache. . . . . . . . . . . 169
KeepAliveTimeout, directiva Apache . . . 170
L
LanguagePriority, directiva Apache. . . . .193
ldconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
libdav.so . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
LimitRequestBody, directiva Apache . . . 264
LimitXMLRequestBody, directiva Apache
264
Linkómetro . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Linuxconf . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Listas de parada . . . . . . . . . . . . . . . . . 123, 335
422
Listen, directiva Apache . . . . . . . . . . . . . . . 170
LiveConnect . . . . . . . . . . . . . . . . . . . . . . . . . . 75
LiveWire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
LoadModule, directiva Apache . . . . 152, 161
Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Log . . . . . . . . . . . . . . . . . . . . . . . . 125–130, 195
Análisis. . . . . . . . . . . . . . . . . . . . . 128–129
Formato véase Variables de formato log
Rotación . . . . . . . . . . . . . . . . . . . . . . . . 130
Utilidades
Cronolog . . . . . . . . . . . véase Cronolog
Logrotate . . . . . . . . . . . véase Logrotate
LogFormat, directiva Apache . . . . . . . . . . 198
LogLevel, directiva Apache. . . . . . . . . . . . 198
Logrotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
M mod_dir, módulo Apache. . . . . . . . . . . . . . 177
Método DELETE . . . . . . . . . . . . . . . . . . . . . 102
Método GET . . . . . . . . . . . . . . . . . . . . . . 23, 38
Método HEAD . . . . . . . . . . . . . . . . . . . . . . . . 23
Método POST . . . . . . . . . . . . . . . . . . . . . 24, 38
Método PUT . . . . . . . . . . . . . . . . . . . . . . . . . 102
magic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
make . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Mason HQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
MaxClients, directiva Apache . . . . . . . . . . 164
MaxKeepAliveRequests, directiva Apache
171
MaxRequestsPerChild, directiva Apache 165
MaxSpareServers, directiva Apache . . . . 166
MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Mediciones de mercado
Netcraft . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Security Space . . . . . . . . . . . . . . . . . . . . 10
MIME . . . . . . . . . . . . . . . . . . . . 28, 41, 96, 188
mime.types . . . . . . . . . . . . . . . . . . . . . . . . . . 151
MIMEMagicFile, directiva Apache . . . . . 194
MinSpareServers, directiva Apache. . . . . 166
mod_access, módulo Apache . 200, 204, 253
mod_actions, módulo Apache. . . . . . . . . . 233
ÍNDICE DE MATERIAS
mod_alias, módulo Apache . . . 181, 186, 296
mod_auth, módulo Apache . . . . . . . . . . . . 253
mod_auth_db, módulo Apache . . . . . . . . . 256
mod_auth_dbm, módulo Apache . . . . . . . 256
mod_auth_digest, módulo Apache. . . . . .258
mod_auth_ldap, módulo Apache . . . . . . . 257
mod_auth_mysql, módulo Apache . . . . . 257
mod_auth_nis, módulo Apache . . . . . . . . 257
mod_auth_oraX, módulo Apache . . . . . . 257
mod_auth_pgsql, módulo Apache . . . . . . 257
mod_auth_smb, módulo Apache . . . . . . . 257
mod_autoindex, módulo Apache. . .174–180
mod_backhand, módulo Apache . . . . . . . 294
mod_cgi, módulo Apache . . . . . . . . . 230, 280
mod_dav, módulo Apache . . . . . . . . . . . . . 261
mod_digest, módulo Apache . . . . . . 253, 258
mod_include, módulo Apache . . . . . . . . . 226
mod_info, módulo Apache . . . . . . . . . . . . 214
mod_jk, módulo Apache . . . . . . . . . . . . . . 243
mod_jk.conf-auto. . . . . . . . . . . . . . . . . . . . . 244
mod_jserv, módulo Apache . . . . . . . . . . . . 243
mod_log_config, módulo Apache . . . . . . 195,
198–200
mod_mime, módulo Apache . 151, 189, 190,
192
mod_mime_magic, módulo Apache151, 194
mod_negotiation, módulo Apache . . . . . . 193
mod_perl, módulo Apache . . . . . . . . . . . . . . 49
mod_php4, módulo Apache . . . . . . . . . . . 250
mod_proxy, módulo Apache . . . . . . . . . . . 295
mod_redundancy, módulo Apache. . . . . . 296
mod_rewrite, módulo Apache . . . . . 195, 296
mod_session, módulo Apache . . . . . . . . . 128
mod_setenvif, módulo Apache . . . . . . . . . 207
mod_so, módulo Apache . . . . . . . . . . . . . . 161
mod_ssl, módulo Apache . . . . . . . . . . 84, 267
mod_status, módulo Apache . . . . . . . . . . . 213
mod_throttle, módulo Apache . . . . . . . . . 294
mod_userdir, módulo Apache . . . . . . . . . . 209
mod_usertrack, módulo Apache . . . . . . . . 285
ÍNDICE DE MATERIAS
mod_vhost_aliases, módulo Apache . . . . 221
ModCBroker, módulo Apache . . . . . . . . . 295
Mohawk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Motor de búsqueda . . . . . . . . . . . . . . . . . . . 123
MPM, Multiple-Processing Modules . . . . 12
mSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Multipart Internet Mail Extension . . . . véase
MIME
MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
N QUERY_STRING, variable de entorno CGI
Name-based virtual hosts . . . . . . . . . . . . . . 219
NameVirtualHost, directiva Apache206, 219
NCSA Mosaic . . . . . . . . . . . . . . . . . . . . . . . 101
Negociación de contenido . . . . . . . . . . . . . . 30
Nodo SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
NSAPI API . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
O Redundancia . . . . . . . . . . . . . . . . . . . . . . . . . 296
ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Ole DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
OpenASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . .83, 268
Operaciones atómicas . . . . . . . . . . . . . . . . . 109
Options, directiva Apache . . . . . . . . . . . . . 202
Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Order, directiva Apache. . . . . . . . . . .204, 259
P RFC 2019,
Pago electrónico. . . . . . . . . . . . . . . . . . . . . . 296
Parser XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
PATH, variable de entorno . . . . . . . . . . . . . 239
PATH_INFO, variable de entrono CGI . . . 39
PEE, Perl Embebed Engine . . . . . . . . . . . . . 75
Perl:DBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
acceso a datos. . . . . . . . . . . . . . . . . . . . 115
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
aplicación . . . . . . . . . . . . . . . . . . . . . . . 349
configuración. . . . . . . . . . . . . . . . 247–252
php.ini . . . . . . . . . . . . . . . . . . . . . . . . . . 250
PHP, Hypertext Preprocessor . . . . . . . . . . . 64
423
PhpMyAdmin . . . . . . . . . . . . . . . . . . . 349–354
PidFile, directiva Apache . . . . . . . . . . . . . . 162
Pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Port, directiva Apache . . . . . . . . . . . . . . . . 172
PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . 111
PROPFIND . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32, 295
Proxy SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Q
38, 56
R
RC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79, 82
RC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79, 82
RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90, 104
ReadmeName, directiva Apache . . . . . . . 180
Register protocol . . . . . . . . . . . . . . . . . . . . . . 81
Registro de actividad . . . . . . . . . . . . véase Log
REQUEST_METHOD, variable de entrono
CGI . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Require, directiva Apache . . . . . . . . . . . . . 254
ResourceConfig, directiva Apache . . . . . . 151
RFC 1867, Form-based File Upload in
HTML . . . . . . . . . . . . . . . . . . . . . . . 28
RFC 1945, HTTP/1.0 . . . . . . . . . . . . . . . . . . 20
HTTP State Management
Mechanism . . . . . . . . . . . . . . . . . . . 20
RFC 2045, MIME I: Format of Internet
Message Bodies . . . . . . . . . . . . . . . 28
RFC 2046, MIME II: Media Types . . . . . . 28
RFC 2047, MIME III: Message Header
Extensions for Non-ASCII Text . 28
RFC 2048, MIME IV: Registration
Procedures . . . . . . . . . . . . . . . . . . . 28
RFC 2049, MIME V: Conformance Criteria
and Examples . . . . . . . . . . . . . . . . . 28
RFC 2145, Use and Interpretation of HTTP
Version Numbers . . . . . . . . . . . . . . 20
424
RFC 2396, URI: Generic Syntax . . . . . . . . 21
RFC 2518, HTTP Extensions for Distributed
Authoring – WEBDAV . . . . . . véase
WebDAV
RFC 2616 . . . . . . . . . . . . . . . . véase HTTP/1.1
RFC 2617, HTTP Authentication: Basic and
Digest Access Authentication. . . 20
RFC 2660, The Secure HyperText Transfer
Protocol . . . . . . . . . . . véase S-HTTP
RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
rpm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79, 83
S Internet Information Server . . . . . . . . . 15
S-HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 84–86
Clientes
Secure Mosaic . . . . . . . . . . . . . . . . . . 85
Servidores Web
Alibaba . . . . . . . . . . . . . . . . . . . . . . . . 85
WebSite . . . . . . . . . . . . . . . . . . . . . . . . 85
WebTen . . . . . . . . . . . . . . . . . . . . . . . . 85
Wildcat. . . . . . . . . . . . . . . . . . . . . . . . . 85
Satisfy, directiva Apache . . . . . . . . . . . . . . 259
SAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
ScoreBoardFile, directiva Apache . . . . . . 162
Script, directiva Apache . . . . . . . . . . . . . . . 233
ScriptAlias, directiva Apache . . . . . . . . . . 186
ScriptAliasMatch, directiva Apache . . . . 187
ScriptLog, directiva Apache . . . . . . . . . . . 235
ScriptLogBuffer, directiva Apache . . . . . 236
ScriptLogLength, directiva Apache . . . . . 236
Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Autentificación. . . . véase Autenticación
Autorización. . . . . . . véase Autorización
Control de acceso . . . . véase Control de
acceso
server.crt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
server.csr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
server.key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
ÍNDICE DE MATERIAS
server.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
ServerAdmin, directiva Apache . . . . . . . . 155
ServerAlias, directiva Apache . . . . . 206, 220
ServerName, directiva Apache . . . . . . . . . 156
ServerPath, directiva Apache . . . . . . . . . . 220
ServerRoot, directiva Apache . . . . . . . . . . 163
ServerSignature, directiva Apache . . . . . . 157
ServerType, directiva Apache . . . . . . . . . . 167
Servidores de aplicaciones . . . . . . . . . . . . . . . 6
BEA Weblogic . . . . . . . . . . . . . . . . . . . . 13
ColdFusion . . . . . . . . . . . . . . . . . . . . . . . 15
Enhydra . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Servidores Web . . . . . . . . . . . . . . . . . . . . . . . . . 5
Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
iPlanet . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Jigsaw . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
NCSA HTTPd . . . . . . . . . . . . . . . . . . . . 16
Zeus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . 43–48
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
aplicación . . . . . . . . . . . . . . . . . . . . . . . 344
configuración . . . . . . . . . . . véase Tomcat
Contenedor . . . . . . . . . . . . . . . . . . . . . . . 44
servlet.jar . . . . . . . . . . . . . . . . . . . . . . . . . 48
Sesión . . . . . . . . . . . . . . . . . . . . . véase Cookies
SetEnvIf, directiva Apache . . . . . . . . . . . . 207
SetEnvIfNoCase, directiva Apache . . . . . 207
SetHandler, directiva Apache . . . . . . . . . . 232
SGBDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
SGML, Standard Generalized Markup
Language. . . . . . . . . . . . . . . . . . . . . 88
SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
SOAP, Simple Object Access Protocol96–99
Nodo . . . . . . . . . . . . . . véase Nodo SOAP
Proxy . . . . . . . . . . . . . véase Proxy SOAP
SOAPAction . . . . . . . . . . . . . . . . . . . . . . 98
Spider . . . . . . . . . . . . . . . . . . . . . . . véase Robot
SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . 112
ÍNDICE DE MATERIAS
srm.conf . . . . . . . . . . . . . . . . . . . . . . . . 151, 210
SSI, Server Side Includes . . . . . . . . . . . 53–59
Configuración . . . . . . . . . . . . . . . 226–228
SSL, Secure Sockets Layer . . . . . . . . . . 78–84
Algoritmos
DES . . . . . . . . . . . . . . . . . . . . véase DES
Diffie-Hellman . véase Diffie-Hellman
DSA . . . . . . . . . . . . . . . . . . . véase DSA
DSH . . . . . . . . . . . . . . . . . . . véase DSH
Fortezza . . . . . . . . . . . . . véase Fortezza
Idea . . . . . . . . . . . . . . . . . . . . véase Idea
MD5 . . . . . . . . . . . . . . . . . . . véase MD5
RC2 . . . . . . . . . . . . . . . . . . . . véase RC2
RC4 . . . . . . . . . . . . . . . . . . . . véase RC4
RSA . . . . . . . . . . . . . . . . . . . véase RSA
SHA-1 . . . . . . . . . . . . . . . . véase SHA1
Certificados
CRL . . . . . . . . . véase CRL, Certificate
Revocation Lists
CSR . véase CSR, Certificate Signing
Requests
X.509 . . . . . . . . . . . . . . . . . . véase x.509
Cipher method protocol . . véase Cipher
method protocol
Error protocol. . . . .véase Error protocol
Handshake protocol . . véase Handshake
protocol
Implementaciones
OpenSSL . . . . . . . . . . . véase OpenSSL
SSL de Netscape . . . . . . . . . . . . . . . . 82
SSLeay . . . . . . . . . . . . . . . . . . . . . . . . . 82
SSLJava . . . . . . . . . . . . . . . . véase JSSE
SSLRef . . . . . . . . . . . . . . . . . . . . . . . . 82
Register protocol . . . . . . . véase Register
protocol
SSLCertificateFile, directiva Apache . . . 275
SSLCertificateKeyFile, directiva Apache275
SSLCipherSuite, directiva Apache . . . . . 275
SSLEngine, directiva Apache . . . . . . . . . . 275
SSLOptions, directiva Apache . . . . . . . . . 275
StartServers, directiva Apache . . . . . . . . . 168
425
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
suEXEC . . . . . . . . . . . . . . . . . . . . . . . . 228–230
Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
T
tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Thawte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
TimeOut, directiva Apache . . . . . . . . . . . . 173
TLS, Transport Layer Security . . . . . . . . . . 78
Tolerancia a fallos . . . . . . . . . . . . . . . . . . . . 296
Tomcat . . . . . . . . . . . . . . . . . . . . . . 48, 237–245
biblioteca jk . . . . . . . . véase biblioteca jk
mod_jk.conf-auto. . . . . . . . . . . . . . . véase
mod_jk.conf-auto
server.xml . . . . . . . . . . . véase server.xml
servlet.jar . . . . . . . . . . . . véase servlet.jar
web.xml . . . . . . . . . . . . . . . véase web.xml
TOMCAT_HOME, variable de entorno . 242
TransferLog, directiva Apache . . . . . . . . . 199
Triple Des . . . . . . . . . . . . . . . . . . . . . véase DES
TypesConfig . . . . . . . . . . . . . . . . . . . . . . . . . 192
U
UDMSearch . . . . . . . . . . . . . . . . . . . . . . . . . 333
uname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Uniform Resource Locator. . . . . . véase URL
URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21, 92
URN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
UseCanonicalName, directiva Apache . . 173
User, directiva Apache. . . . . . . . . . . . 168, 213
UserDir, directiva Apache . . . . . . . . 208, 211
V
Variables de entorno CGI . . . . . . . . . . . . . . . 39
Variables de entorno SSI . . . . . . . . . . . . . . . 54
Variables de formato de log . . . . . . . . . . . . 280
Verisign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Virtual hosts . . . . . . . . . . . . . . . . . . . . . . 31, 305
configuración. . . . . . . . . . . . . . . . 217–223
Dynamic virtual hosts . . véase Dynamic
virtual hosts
426 ÍNDICE DE MATERIAS

Ip-based virtual hosts . . . véase Ip-based Xerces . . . . . . . . . . . . . . . . véase Xerces

virtual hosts XHTML . . . . . . . . . . . . véase XHTML
Name-based virtual hosts . . . . . . . . véase BASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Name-based virtual hosts Documento bien formado. . . . . . . . véase
por defecto . . . . . . . . . . . . . . . . . . . . . . 222 Documento bien formado
VirtualDocumentRoot, directiva Apache 221 Documento válido . . . véase Documento
VirtualDocumentRootIP, directiva Apache válido
221 DTD . . . . . . . . . . . . . . . . . . . . . véase DTD
VirtualScriptAlias, directiva Apache . . . . 221 Encryption. . . . . . . . . . . . . . . . . . . . . . . . 93
VirtualScriptAliasIP, directiva Apache . . 221 Namespaces . . . . . . . . . . . . . . . . . . . . . . 90
Parser . . . . . . . . . . . . . véase Parser XML
W Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3, 4, 101 Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Web Folders . . . . . . . . . . . . . . véase WebDAV RDF . . . . . . . . . . . . . . . . . . . . . . véase RDF
web.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Webcrawler . . . . . . . . . . . . . . . . . . véase Robot signature . . . . . . . . . . . . . . . . . . . . . . . . . 93
WebDAV . . . . . . . . . . . . . . . . . . . . . . . . 102–104 XLink, XML Linking Language92, 104
configuración . . . . . . . . . . . . . . . . . . . . 330 XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . 97
PROPFIND . . . . . . . . . véase PROPFIND XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 XPointer, XML Pointer Language . . . 92
World Wide Web . . . . . . . . . . . . . . . véase Web XSL Formatting Objects . . . . . . . . . . . 92
wrapper CGI . . . . . . . . . . . . . . . véase suEXEC XSL, Extensible Stylesheet Language92
XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
X XSSI, eXtended Server Side Includes . . . 54,
X.509 . . . . . . . . . . . . . . . . . . . . . . . . . 79, 80, 83 226
Xalan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Xang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
XBitHack, directiva Apache . . . . . . . . . . . 227
Xerces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . 93–96
XML, eXtensible Markup Language87–100,
104
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
DOM . . . . . . . . . . . . . . . . . . véase DOM
SAX . . . . . . . . . . . . . . . . . . . véase SAX
Aplicaciones
Cocoon . . . . . . . . . . . . . . véase Cocoon
Expat . . . . . . . . . . . . . . . . . . véase Expat
JAXP . . . . . . . . . . . . . . . . . . véase JAXP
Xalan . . . . . . . . . . . . . . . . . véase Xalan
Xang . . . . . . . . . . . . . . . . . . véase Xang