Capítulo 30. El servidor web Apache / 30.8. Contenidos activos | ||||
|---|---|---|---|---|
 | 30.7. Funcionamiento de Apache | 30.9. Máquinas virtuales |  | |
Capítulo 30. El servidor web Apache / 30.8. Contenidos activos | ||||
|---|---|---|---|---|
| 30.7. Funcionamiento de Apache | 30.9. Máquinas virtuales | | |
Apache ofrece varias posibilidades para proporcionar contenidos activos a clientes. Por contenidos activos se entienden páginas HTML creadas como resultado de datos variables introducidos por el cliente. Los buscadores constituyen un ejemplo muy conocido. En estas páginas, la introducción de uno o varios términos de búsqueda, quizá separados por operadores lógicos como “y”, “o”, etc., tiene como resultado una lista de páginas que incluyen el término buscado.
Existen tres formas de crear contenidos activos con Apache:
Aquí se trata de instrucciones que son integradas en una página HTML por medio de comentarios especiales. Apache analiza el contenido de estos comentarios e incluye el resultado en la página HTML.
En este caso se ejecutan programas situados dentro de determinados directorios. Apache pasa los parámetros transmitidos por el cliente a estos programas y devuelve el resultado de los programas al cliente. Este tipo de programación es relativamente fácil, especialmente al ser posible configurar programas de línea de comandos ya existentes para que acepten datos de entrada de Apache y emitan su salida a Apache.
Apache incluye interfaces para ejecutar cualquier módulo como parte del procesamiento de una solicitud y ofrece a estos programas acceso a información importante como la solicitud o la cabecera HTTP. De esta forma, en el procesamiento de solicitudes pueden participar programas que no sólo son capaces de crear contenidos activos sino también de realizar otras funciones (como por ejemplo la autenticación). La programación de estos módulos requiere un cierto nivel de conocimientos. Como contrapartida, se logra un alto rendimiento además de posibilidades más amplias que las obtenidas con SSI y CGI.
Mientras los scripts CGI son activados por Apache (mediante el ID de usuario de su propietario), para utilizar los módulos es necesario integrar en Apache un intérprete que se ejecute continuamente. (Se dice que el intérprete es “persistente”.) De esta forma se evita el tener que iniciar y terminar un proceso propio para cada solicitud (lo que implica un importante consumo de recursos con respecto a la administración de procesos, gestión de memoria, etc.). En su lugar, el script se pasa al intérprete que ya está ejecutándose.
Este método tiene un inconveniente: mientras los scripts ejecutados a través de CGI muestran una relativa tolerancia ante fallos de programación, dichos fallos tienen un efecto muy negativo cuando se utilizan módulos. La razón es que, en scripts CGI normales, los programas son finalizados tras procesar la solicitud y los fallos de recursos o memoria no compartidos no tienen tanta importancia porque la memoria o recurso vuelve a estar disponible una vez finalizado el programa. En cambio, al utilizar los módulos, los efectos de los fallos de programación son permanentes ya que el intérprete está en constante ejecución. Si el servidor no es reiniciado, el intérprete puede funcionar sin interrupción durante meses. Durante un periodo tan largo, los recursos no compartidos se hacen notar.
Server Side Includes son instrucciones integradas en comentarios especiales
ejecutados por Apache. El resultado se integra
inmediatamente en la salida de Apache. Por
ejemplo, la instrucción <!--#echo var="DATE_LOCAL"
--> produce la fecha actual. Nótese aquí #
inmediatamente después del inicio del comentario
<!--, que indica a Apache
que se trata de una instrucción SSI y no de un comentario normal.
Las instrucciones SSIs pueden activarse de diversas maneras. El modo más sencillo consiste en examinar todos los archivos ejecutables en busca de Server Side Includes. La alternativa implica definir ciertos tipos de archivos que deben examinarse en busca de SSIs. Ambos procedimientos se explican en la Sección 30.6.2.15, “Server-Side Includes”.
CGI es la abreviatura de Common Gateway Interface. Mediante CGI, el servidor no se limita a proporcionar una página HTML estática, sino que ejecuta un programa que se encarga de entregar esa página. De esta forma es posible crear páginas fruto de una operación de cálculo, como el resultado de una búsqueda en una base de datos. Además existe la posibilidad de pasar parámetros al programa ejecutado, permitiéndose así entregar una página individual de respuesta para cada solicitud.
La principal ventaja de CGI radica en su sencillez. El programa sólo tiene
que estar en un directorio determinado para ser ejecutado por el servidor
web como si se tratase de un programa en la línea de comandos. El servidor
simplemente entrega al cliente el resultado del programa en la salida
estándar (stdout).
En principio, los programas CGI pueden estar escritos en cualquier lenguaje de programación. Normalmente se utilizan lenguajes de scripts (lenguajes interpretados) como Perl o PHP. En el caso de CGIs que deban ejecutarse muy rápidamente, el lenguaje elegido será C o C++.
En el caso más sencillo, Apache busca estos programas en un directorio
concreto (cgi-bin). Este directorio puede definirse en el
archivo de configuración, vea la Sección 30.6, “Configuración”.
Si es necesario, es posible especificar directorios adicionales que serán
examinados por Apache en busca de programas ejecutables. No obstante esto
conlleva cierto riesgo, ya que cualquier usuario (bien o malintencionado) será
capaz de hacer que Apache ejecute programas. Si los programas ejecutables sólo
se admiten en cgi-bin, el administrador puede controlar
más fácilmente quién guarda qué programas o scripts en ese directorio y si
dichos programas o scripts son peligrosos.
Los parámetros de entrada pueden pasarse al servidor mediante
GET o bien POST. Dependiendo del método
utilizado, el servidor pasa los parámetros al script de forma distinta. En el
caso de POST, el servidor pasa los parámetros al programa en
la entrada estándar (stdin) (el programa obtiene aquí los
parámetros de la misma forma que si se iniciara en una consola). Con
GET, el servidor pasa los parámetros al programa en la
variable de entorno QUERY_STRING.
Existen numerosos módulos que pueden utilizarse en Apache. El término “módulo” posee aquí dos acepciones. Por un lado se encuentran los módulos que pueden integrarse en Apache y que asumen en el servidor una función determinada como la integración de lenguajes de programación en Apache. Un ejemplo son los módulos que se explican a continuación.
Por otro lado, en los lenguajes de programación se emplea la palabra módulo para referirse a una cantidad determinada de funciones, clases y variables. Estos módulos se integran en programas para proporcionar diversas prestaciones. Un ejemplo son los módulos CGI disponibles en todos los lenguajes de scripts. Estos módulos simplifican la programación de aplicaciones CGI al ofrecer métodos para leer los parámetros de la solicitud y proporcionar código HTML.
Perl es un lenguaje de scripts muy utilizado y de eficacia probada. Existe una multitud de módulos y librerías para Perl (entre las que se encuentra una librería para ampliar el archivo de configuración de Apache). Puede encontrar una amplia selección de librerías para Perl en la URL del proyecto Comprehensive Perl Archive Network (CPAN) http://www.cpan.org/.
Para trabajar con mod_perl en SUSE LINUX, basta con
instalar el paquete correspondiente (véase la Sección 30.5, “Instalación”). Las entradas
necesarias para Apache en el archivo de
configuración ya están incluidas, véase
/etc/apache2/mod_perl-startup.pl. Puede obtener
información adicional sobre mod_perl en http://perl.apache.org/.
En el caso más sencillo, es posible ejecutar un script CGI como script
mod_perl simplemente activándolo a través de otra URL.
El archivo de configuración contiene alias que apuntan al mismo directorio
y ejecutan los scripts allí almacenados a través de CGI o bien mediante
mod_perl. Estas entradas ya han sido introducidas en el
archivo de configuración. La entrada alias para CGI es:
ScriptAlias /cgi-bin/ "/srv/www/cgi-bin/"
mientras que las entradas para mod_perl son las siguientes:
<IfModule mod_perl.c>
# Provide two aliases to the same cgi-bin directory,
# to see the effects of the 2 different mod_perl modes.
# for Apache::Registry Mode
ScriptAlias /perl/ "/srv/www/cgi-bin/"
# for Apache::Perlrun Mode
ScriptAlias /cgi-perl/ "/srv/www/cgi-bin/"
</IfModule>
Las siguientes entradas también son necesarias para mod_perl y se encuentran ya en el archivo de configuración.
# # If mod_perl is activated, load configuration information # <IfModule mod_perl.c> Perlrequire /usr/include/apache/modules/perl/startup.perl PerlModule Apache::Registry # # set Apache::Registry Mode for /perl Alias # <Location /perl> SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI PerlSendHeader On </Location> # # set Apache::PerlRun Mode for /cgi-perl Alias # <Location /cgi-perl> SetHandler perl-script PerlHandler Apache::PerlRun Options ExecCGI PerlSendHeader On </Location> </IfModule>
Estas entradas crean nombres alias para los modos
Apache::Registry y Apache::PerlRun.
La diferencia entre ambos modos es la siguiente:
Se compilan todos los scripts y después se guardan en la memoria caché. Cada script se crea como contenido de una subrutina. Aunque esto resulta positivo desde el punto de vista del rendimiento, presenta también un inconveniente: los scripts han de estar muy bien programados, ya que las variables y las subrutinas se mantienen entre los procesos de activación. Esto significa que las variables deben devolverse a su valor original para poder ser reutilizadas cuando se vuelva a activar el script. Por ejemplo, si se guarda el número de tarjeta de crédito de un cliente en un script de banca a distancia, este número podría volver a aparecer cuando el próximo cliente utilice la aplicación y vuelva a activar el script.
Los scripts son compilados de nuevo para cada solicitud de tal forma
que las variables y subrutinas desaparecen del espacio de nombres entre
los procesos de activación. El espacio de nombres es el conjunto de
todos los nombres de variables y rutinas definidos en un momento
determinado durante la existencia de un script. Por tanto, con
Apache::PerlRun no es necesario prestar tanta
atención a la calidad de la programación, ya que todas las variables se
inician al activar el programa y no pueden contener ningún valor
procedente de procesos de activación anteriores. Este es el motivo por
el que Apache::PerlRun es más lento que
Apache::Registry, pero aún así considerablemente más
rápido que CGI, ya que se evita el tener que iniciar un proceso propio
para el intérprete. Apache::PerlRun se comporta de
manera similar a CGI.
PHP es un lenguaje de programación creado especialmente para su uso con servidores web. Al contrario que otros lenguajes que guardan sus comandos en archivos independientes (scripts), los comandos en PHP están integrados en una página HTML de manera similar a SSI. El intérprete PHP procesa los comandos PHP e integra el resultado del proceso en la página HTML.
La página web de PHP es http://www.php.net/.
El paquete mod_php4-core ha de estar
instalado necesariamente. Para Apache 2 se requiere además el paquete
apache2-mod_php4.
Python es un lenguaje de programación orientado a objetos con una sintaxis
muy clara y legible. La estructura del programa depende del sangrado, lo
cual puede resultar un poco raro al principio pero muy cómodo cuando uno se
acostumbra. Los bloques no se definen por medio de abrazaderas (como en C y
en Perl) o delimitadores como begin y
end, sino mediante la profundidad del sangrado. Ha de
instalar el paquete apache2-mod_python.
Puede encontrar información adicional sobre este lenguaje en http://www.python.org/ y sobre mod_python en
http://www.modpython.org/
Ruby es un lenguaje de programación de alto nivel orientado a objetos.
Ruby, un lenguaje relativamente joven, se asemeja tanto a Perl como a
Python y resulta muy adecuado para su uso en scripts. Tiene en común con
Python la sintaxis clara y bien organizada y con Perl las abreviaturas del
tipo $.r y el número de la última línea
leída del archivo de entrada. Ateniéndonos a su concepto, Ruby presenta
enormes similitudes con Smalltalk.
La página web de Ruby es http://www.ruby-lang.org/. Existe también un módulo Apache para Ruby cuya página web es http://www.modruby.net/.
