Este artículo es parte del Curso Arquitectura Web. No olvides ver todo el programa y acceder a cada uno de los capítulos desde aquí.

Ya tenemos instalado nuestro servidor web apache, no importa si es Linux, Windows u OS X, la configuración de Apache y sus reglas son generales, las particularidades surgen a partir de la ubicación de los archivos y el método de instalación, pero el funcionamiento es el mismo como veremos más adelante.

Aprendimos cómo determinar si apache ha levantado (sin cambios en la instalación por defecto) en el puerto 80, tanto con comandos en una terminal como en la interfaz gráfica como se describe aquí y también cómo funciona la comunicación entre el navegador y el servidor web. Teniendo en mente estos conceptos nos será mucho más fácil continuar en esta parte del curso.

Apache HTTP Server  se encarga de procesar solicitudes / reglas y devolver documentos web. Generalmente, toda respuesta que apache da a una solicitud regresa en forma de HTML.

Para poder exponer “publicar” en modo web aplicaciones escritas por ejemplo en PERL, Python o PHP necesitaremos instalar módulos adicionales en apache.

Apache por sí solo es incapaz de entender Python, PERL o PHP, necesita de módulos específicos que puedan procesar esos lenguajes y devolver una salida HTML, la cual será entregada al cliente/navegador para que se procese finalmente.

Si por ejemplo publicamos una aplicación php en Apache sin configurar el módulo “php para apache” entonces podremos ver el código sin procesar de PHP ¡Todo un riesgo de seguridad!

Si alguna vez usaron la opción en su navegador “Ver código fuente” podrán notar que jamás se observan tags, etiquetas o funciones de PHP, siempre es HTML. Esto pasa porque, el archivo PHP como tal se procesa y regresa una salida HTML, jamás se entrega (o se debería) el PHP al cliente/navegador.

Para continuar la explicación, consideremos este gráfico (abreviado – groso modo) del funcionamiento interno de Apache:

Funcionamiento interno de Apache HTTP Server

Funcionamiento interno de Apache HTTP Server

Puede que aún no lo comprendan todo, pero a continuación voy a describir el proceso.

Todo inicia con la solicitud del cliente, puede ser un teléfono, una PC o MAC, una tablet…  que disponga de un cliente (un navegador de texto o gráfico, una herramienta para conectarse a la web) podrá interactuar con el servidor.

La solicitud comienza con el nombre de dominio, supongamos en este caso “dominio.com.ar” y posteriormente con el recurso /index.php

Aclaremos de momento, que escribir dominio.com.ar nos llevará al default HTTP:80, pero si escribimos expresamente HTTPS iremos a HTTPS:443, lo cual para apache es completamente distinto, veámos un ejemplo.

Todo comienza con el dominio

Recuerden ponerse al día con los puertos 80 y 443 en uno de los capítulos anteriores para comprender mejor lo que viene.

Lo primero que el cliente usa para comunicarse con apache es el dominio, en nuestro gráfico “dominio.com.ar”, pero para entrar más en detalle veamos este ejemplo rápido:

Mi dominio http://migueleonardortiz.com.ar (este sitio web) les muestra el curso y otros contenidos. Intenten ingresar vía HTTPS con este Link: https://migueleonardortiz.com.ar (verán un mensaje de advertencia como este):

Mensaje de advertencia para SSL

Una vez den clic en “advanced / opciones avanzadas” y “proceed to migueleonardortiz.com.ar (unsafe)” verán lo siguiente:

Intento de ingreso vía SSL

Estamos ingresando al mismo dominio, pero en protocolos diferentes, por ello apache lo procesa distinto y nos lleva a Virtual Hosts o Reglas distintas. Es decir que:

http://migueleonardortiz.com.ar -> HTTP al puerto 80 -> Sitio de WordPress de Miguel Leonardo Ortiz

https://migueleonardortiz.com.ar -> HTTP al puerto 443 – Página por default de mi proovedor de Hosting para vender SSL

También podría comprar un certificado SSL y habilitar mi sitio para establecer una comunicación encriptada, así no se mostraría el mensaje y las personas ingresarían a mi sitio con normalidad vía HTTPS, pero eso lo veremos más adelante.

Finalmente sepan que Apache puede redireccionar el tráfico también. Piensen en Facebook / Twitter / Google, no importa cuanto intenten inrgesar vía HTTP:80 siempre los redirige a HTTPS al 443 (por temas de seguridad), esta redirección también podría ser inversa, del 443 al 80, con Apache controlamos todo el flujo del tráfico.

Una vez hemos solicitado el dominio y acontece toda la comunicación vía cliente servidor que vimos en otros capítulos, Apache recibe la solicitud y dependiendo de cómo lo hayamos configurado va a procesarla.

Si la solicitud es correcta ( el dominio existe en el apache como un VirtualHost ) entonces se procesarán las reglas específicas para ese dominio y sus recursos. Si el recurso existe y es accesible ( si el archivo index.php según el htdocs o directory y tiene los permisos suficientes) se ejecutará el php en el módulo de apache-php, el cual da una respuesta HTML plano y lo regresa al cliente (navegador / aplicación) y finaliza con el código HTTP 200.

Si la solicitud es correcta, pero el recurso no existe (solicitud incorrecta) o hay un error interno de configuración de apache veremos un error del tipo HTTP 404 como respuesta HTML.

También puede ser que tengamos problemas en el servidor internamente (alguna configuración mal hecha) y obtenemos errores del tipo HTTP 500.

Para comprender todos los conceptos mucho mejor, en el siguiente capítulo vamos a armar un laboratorio con el dominio “dominio.com.ar” y vamos a ver cómo funcionan en la práctica las reglas, los virtualhost, htdocs, permisos y mucho más.