Introducción a Apache HTTP Server

Apache HTTP Server es el servidor web por excelencia. Es una herramienta libre que ha acompañado el desarrollo de la web prácticamente desde sus inicios y durante mucho tiempo ha sido el servidor web más utilizado en Internet aunque recientemente ha cedido el podio a otro servidor libre: nginx.

El servidor web Apache HTTP Server se desarrolla de manera abierta bajo el amparo de la Fundación Apache que también desarrolla muchos otros proyectos libres e interesantes.

En este artículo únicamente se va a tratar una breve introducción a las características básicas de Apache HTTP Server pero este servidor web tiene muchísimas funciones. Afortunadamente esta herramienta cuenta con una buena documentación traducida a muchos idiomas: Documentación de Apache HTTP Server.

Instalación de Apache HTTP Server

El servidor web Apache se encuentra en los repositorios de cualquier distribución que se precie y normalmente esta es la manera recomendada para su instalación.

Por ejemplo en Ubuntu se puede instalar así:

# apt update
# apt install apache2

La instalación activa el servicio y lo enciende con la configuración por defecto que escucha en el puerto 80 de todas las interfaces de red.

Naturalmente el servicio se puede controlar con systemctl de la forma habitual:

root@apache:~# systemctl status apache2
● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2021-01-15 18:00:09 UTC; 17s ago
       Docs: https://httpd.apache.org/docs/2.4/
    Process: 183 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
   Main PID: 240 (apache2)
      Tasks: 55 (limit: 9346)
     Memory: 7.7M
     CGroup: /system.slice/apache2.service
             ├─240 /usr/sbin/apache2 -k start
             ├─243 /usr/sbin/apache2 -k start
             └─244 /usr/sbin/apache2 -k start

Jan 15 18:00:09 apache systemd[1]: Starting The Apache HTTP Server...
Jan 15 18:00:09 apache systemd[1]: Started The Apache HTTP Server.
root@apache:~# 

El servidor publicará en la web el contenido del directorio DocumentRootque por defecto es /var/www/html y únicamente contiene una página para comprobar que todo funciona bien.

En el directorio /var/log/apache2 se encuentran los siguientes ficheros de registro:

• access.log: Fichero de registro de accesos. Contendrá una línea por cada acceso al servidor web para el VirtualHost por defecto.
• other_vhosts_access.log: Fichero de registro de accesos para otros VirtualHosts. Es posible indicar el fichero de registro a utilizar en la definición del VirtualHost.
• error.log: Fichero de registro de errores. Aquí Apache HTTP Server mostrará información sobre los problemas que encuentre.

Configuración de Apache HTTP Server

La configuración del servidor depende de la distribución de GNU/Linux que se utilice. En Debian —y derivados como Ubuntu— está dividida en diferentes ficheros en el interior de /etc/apache2:

root@apache:/etc/apache2# ll
total 92
drwxr-xr-x  8 root root    12 Jan 10 16:29 ./
drwxr-xr-x 91 root root   180 Jan 11 15:48 ../
-rw-r--r--  1 root root  7224 Aug 12 19:46 apache2.conf
drwxr-xr-x  2 root root     7 Jan 10 16:29 conf-available/
drwxr-xr-x  2 root root     7 Jan 10 16:29 conf-enabled/
-rw-r--r--  1 root root  1782 Apr 13  2020 envvars
-rw-r--r--  1 root root 31063 Apr 13  2020 magic
drwxr-xr-x  2 root root   143 Jan 10 16:29 mods-available/
drwxr-xr-x  2 root root    31 Jan 10 16:29 mods-enabled/
-rw-r--r--  1 root root   320 Apr 13  2020 ports.conf
drwxr-xr-x  2 root root     4 Jan 10 16:29 sites-available/
drwxr-xr-x  2 root root     3 Jan 10 16:29 sites-enabled/
root@apache:/etc/apache2#

Evidentemente el fichero principal de configuración es apache2.conf. Este fichero contiene valores globales de configuración para todo el servidor con unos valores por defecto muy razonables, además incluye otros ficheros de configuración como son:

• ports.conf: Aquí se indican los puertos en los que escuchará el servidor. Por defecto 80 TCP para HTTP y 443 TCP para HTTPS.
• Directorio conf-available: Contiene fragmentos para la configuración global del servidor.
• Directorio conf-enabled: Enlaces a los fragmentos del directorio actual que están activos.
• Directorio mods-available: Contiene los módulos —y su configuración— que están instalados.
• Directorio mods-enabled: Enlaces a los módulos del directorio anterior que están activos.
• Directorio sites-available: Declaración de VirtualHosts.
• Directorio sites-enabled: Enlaces a los sitios activos.

Herramientas para la gestión de la configuración: a2enconf, a2enmod, a2ensite

La configuración de Apache HTTP Server guarda los fragmentos para la configuración general, los módulos y los sitios (VirtualHosts) en directorios diferenciados. Para cada uno de estos elementos se utilizan dos directorios, uno de ellos guarda todos los elementos disponibles y el otro contiene enlaces simbólicos para aquellos elementos activos.

Por ejemplo, para el caso de los sitios tenemos los directorios: sites-available y sites-enabled. En el primero se guardan todos los VirtualHosts que existen y desde el segundo se enlazan aquellos que se desea que Apache HTTP Server tenga en cuenta.

Así en sites-available tras la instalación encontramos 000-default.conf y default-ssl.conf:

root@apache:/etc/apache2# ll sites-available/
total 20
drwxr-xr-x 2 root root    4 Jan 10 16:29 ./
drwxr-xr-x 8 root root   12 Jan 15 18:34 ../
-rw-r--r-- 1 root root 1332 Apr 13  2020 000-default.conf
-rw-r--r-- 1 root root 6338 Apr 13  2020 default-ssl.conf
root@apache:/etc/apache2#

Pero en sites-enabled sólo hay un enlace para el primero de ellos que corresponde al VirtualHost por defecto para HTTP.

root@apache:/etc/apache2# ll sites-enabled/
total 11
drwxr-xr-x 2 root root  3 Jan 10 16:29 ./
drwxr-xr-x 8 root root 12 Jan 15 18:34 ../
lrwxrwxrwx 1 root root 35 Jan 10 16:29 000-default.conf -> ../sites-available/000-default.conf
root@apache:/etc/apache2#

Durante el arranque Apache HTTP Server leerá todos los fragmentos que estén en el interior de los directorios *-enabled/ y los tendrá en cuenta durante su configuración.

Aunque es posible gestionar estos enlaces de manera manual, existen unas herramientas específicas que crean o eliminan estos enlaces (activando o desactivando la configuración, el módulo o el sitio que corresponda).

Estas herramientas son:

Por ejemplo, para habilitar el VirtualHost default-ssl.conf que publica contenidos con HTTPS bastará con hacer:

1. Activar el módulo SSL que necesita HTTPS: a2enmod ssl
2. Activar el sitio: a2ensite default-ssl
3. Pedir a Apache HTTP Server que vuelva a cargar la configuración: systemctl reload apache2

Después se podrá acceder mediante HTTPS al servidor. Tenga en cuenta que se está utilizando un certificado autogenerado durante la instalación de Apache HTTP Server y los navegadores mostrarán una advertencia de seguridad que espantará a los usuarios :-)

Módulos de Apache HTTP Server

Las funciones de Apache HTTP Server están implementadas en diferentes módulos que se pueden habilitar o deshabilitar según convenga. En general no convienen tener activos módulos que no sean necesarios pues:

• Aumentará el consumo de recursos.
• Estaremos exponiendo funciones sin prestar atención y tal vez sin configurar debidamente.

La instalación básica del paquete apache2 ya ha instalado varios módulos en el directorio /etc/apache2/mods-available y ha activado algunos de ellos con enlaces simbólicos en el directorio /etc/apache2/mods-enabled.

root@apache:/etc/apache2# ll mods-enabled/
total 48
drwxr-xr-x 2 root root 32 Jan 16 11:18 ./
drwxr-xr-x 8 root root 12 Jan 15 18:34 ../
lrwxrwxrwx 1 root root 36 Jan 10 16:29 access_compat.load -> ../mods-available/access_compat.load
lrwxrwxrwx 1 root root 28 Jan 10 16:29 alias.conf -> ../mods-available/alias.conf
lrwxrwxrwx 1 root root 28 Jan 10 16:29 alias.load -> ../mods-available/alias.load
lrwxrwxrwx 1 root root 33 Jan 10 16:29 auth_basic.load -> ../mods-available/auth_basic.load
lrwxrwxrwx 1 root root 33 Jan 10 16:29 authn_core.load -> ../mods-available/authn_core.load
lrwxrwxrwx 1 root root 33 Jan 10 16:29 authn_file.load -> ../mods-available/authn_file.load
lrwxrwxrwx 1 root root 33 Jan 10 16:29 authz_core.load -> ../mods-available/authz_core.load
lrwxrwxrwx 1 root root 33 Jan 10 16:29 authz_host.load -> ../mods-available/authz_host.load
lrwxrwxrwx 1 root root 33 Jan 10 16:29 authz_user.load -> ../mods-available/authz_user.load
lrwxrwxrwx 1 root root 32 Jan 10 16:29 autoindex.conf -> ../mods-available/autoindex.conf
lrwxrwxrwx 1 root root 32 Jan 10 16:29 autoindex.load -> ../mods-available/autoindex.load
lrwxrwxrwx 1 root root 30 Jan 10 16:29 deflate.conf -> ../mods-available/deflate.conf
lrwxrwxrwx 1 root root 30 Jan 10 16:29 deflate.load -> ../mods-available/deflate.load
lrwxrwxrwx 1 root root 26 Jan 10 16:29 dir.conf -> ../mods-available/dir.conf
lrwxrwxrwx 1 root root 26 Jan 10 16:29 dir.load -> ../mods-available/dir.load
lrwxrwxrwx 1 root root 26 Jan 10 16:29 env.load -> ../mods-available/env.load
lrwxrwxrwx 1 root root 29 Jan 10 16:29 filter.load -> ../mods-available/filter.load
lrwxrwxrwx 1 root root 27 Jan 10 16:29 mime.conf -> ../mods-available/mime.conf
lrwxrwxrwx 1 root root 27 Jan 10 16:29 mime.load -> ../mods-available/mime.load
lrwxrwxrwx 1 root root 32 Jan 10 16:29 mpm_event.conf -> ../mods-available/mpm_event.conf
lrwxrwxrwx 1 root root 32 Jan 10 16:29 mpm_event.load -> ../mods-available/mpm_event.load
lrwxrwxrwx 1 root root 34 Jan 10 16:29 negotiation.conf -> ../mods-available/negotiation.conf
lrwxrwxrwx 1 root root 34 Jan 10 16:29 negotiation.load -> ../mods-available/negotiation.load
lrwxrwxrwx 1 root root 33 Jan 10 16:29 reqtimeout.conf -> ../mods-available/reqtimeout.conf
lrwxrwxrwx 1 root root 33 Jan 10 16:29 reqtimeout.load -> ../mods-available/reqtimeout.load
lrwxrwxrwx 1 root root 31 Jan 10 16:29 setenvif.conf -> ../mods-available/setenvif.conf
lrwxrwxrwx 1 root root 31 Jan 10 16:29 setenvif.load -> ../mods-available/setenvif.load
lrwxrwxrwx 1 root root 36 Jan 15 19:11 socache_shmcb.load -> ../mods-available/socache_shmcb.load
lrwxrwxrwx 1 root root 29 Jan 10 16:29 status.conf -> ../mods-available/status.conf
lrwxrwxrwx 1 root root 29 Jan 10 16:29 status.load -> ../mods-available/status.load
root@apache:/etc/apache2#

Cabe observar que muchos módulos tienen su propio fichero de configuración donde se especifican los parámetros generales de funcionamiento. De estos módulos podemos destacar:

<Location "/server-status">
    SetHandler server-status
    Require ip 192.168.0.0/16
</Location>

Y aún son más los módulos que se encuentran instalados por defecto pero no están activados. Pero sobre todo hay muchos módulos que están en su propio paquete y se pueden instalar a partir de los repositorios de la distribución utilizada.

Por ejemplo, en Ubuntu todos los paquetes libapache2-mod_* corresponden a módulos para Apache HTTP Server.

Autenticación de acceso básica con HTTP

Apache HTTP Server puede proteger con autenticación de acceso básica HTTP algunos recursos. Así es posible, por ejemplo, pedir usuario y contraseña para acceder al contenido de cierto directorio y permitir el acceso únicamente en el caso de algún usuario concreto o un grupo de ellos.

Para poner en marcha la autenticación básica conviene crear un fichero de contraseñas en el que se registrarán los usuarios y contraseñas. Este fichero se gestiona con el comando htpasswd y debería estar fuera de cualquier DocumentRoot para evitar que el servidor lo publique en la web.

Por ejemplo, para crear el fichero de contraseñas /var/www/passwords y guardar en su interior el usuario usuario1 se puede hacer:

root@apache:/var/www# htpasswd -c passwords usuario1
New password: 
Re-type new password: 
Adding password for user usuario1
root@apache:/var/www#

Una vez creado el fichero se podrán añadir más usuarios al volver a ejecutar htpasswd sin utilizar el argumento -c que únicamente sirve para crear un fichero nuevo (o borrar los contenidos de un fichero existente).

Después se podrá utilizar una directiva <Directory> para cambiar la configuración de acceso a los contenidos de un directorio. Por ejemplo, para proteger con autenticación básica el directorio /var/www/html/secreto, se puede añadir la siguiente configuración al VirtualHost por defecto y recargar la configuración.

<Directory "/var/www/html/secreto">
    AuthType Basic
    AuthName "Ficheros restringidos"
    AuthBasicProvider file
    AuthUserFile "/var/www/passwords"
    Require user usuario1
</Directory>

La directiva Require también nos permitirá:

• Utilizar Require valid-user para aceptar cualquier usuario del fichero de contraseñas.
• Especificar una lista de usuarios válidos: Require user usuario1 usuario2 usuario4
• Filtrar por una dirección (IP, fragmento de IP o lista de IPs): Require ip 192.168.0.50
• Filtrar por un host: Require host cliente-50.elpuig.xeill.net
• Otras opciones que aparecen en su documentación: https://httpd.apache.org/docs/2.4/es/mod/mod_authz_core.html#require

También es posible utilizar un fichero en el que se pueden declarar grupos de usuarios a conveniencia. Por ejemplo al declarar el fichero /var/www/groups con el siguiente contenido:

grupo1: usuario1 usuario2 usuario4

Se puede cambiar la configuración de acceso para permitir el acceso a cualquier usuario del grupo grupo1

<Directory "/var/www/html/secreto">
    AuthType Basic
    AuthName "Ficheros restringidos"
    AuthBasicProvider file
    AuthUserFile "/var/www/passwords"
    AuthGroupFile "/var/www/groups"
    Require group grupo1
</Directory>

Contenedores de autorización: RequireAll, RequireAny, RequireNone

Las distintas directivas Require se pueden agrupar mediante los llamados contenedores de autorización para conseguir configuraciones muy flexibles.

Cuando se utilicen varias directivas Require sin ningún contenedor será como si estuvieran en el interior de un RequireAny, es decir, se permitirá el acceso si se cumple alguno de los Require.

El contenedor RequireAll exigirá que se cumplan todas las directivas y RequireNone que no se cumpla ninguna.

Varios sitios con la directiva VirtualHost

Un servidor Apache HTTP Server puede publicar diferentes sitios web, cada uno con su propio DocumentRoot, protocolo (HTTP/HTTPS/HTTP2) y configuración. En el interior de un VirtualHost se heredan los valores de configuración global pero es posible redefinir de manera particular aquellos que deban cambiar.

Los VirtualHost pueden ser:

• Basados en IP
• Basado en nombre

Los primeros atienden en una dirección IP diferente para cada VirtualHost. Lo segundos son más flexibles porque no hay que añadir más direccions al servidor web, Apache HTTP Server utilizará el VirtualHost adecuado basándose en el nombre que utilizó el navegador para llegar hasta el servidor. Estos VirtualHost en Internet funcionan gracias al DNS pero en un entorno de desarrollo se pueden utilizar 'substituyendo' el DNS por entradas en el fichero /etc/hosts tanto en el servidor como en el cliente.

Normalmente los VirtualHost se definen en un fichero propio del directorio sites-available/ y se activan con el comando a2ensite cuando es necesario.

La definición de un VirtualHost basado en nombre sencillo puede ser:

<VirtualHost *:80>
    ServerName moodle.elpuig.xeill.net

    DocumentRoot /var/www/moodle
</VirtualHost>

La directiva ServerName se utiliza para indicar el dominio para el que responderá este sitio, y *:80 indica el puerto en el que escuchará (de cualquier interfaz).

Web segura con HTTPS

En la actualidad prácticamente cualquier servicio web debe atender a los clientes con la seguridad que proporciona el protocolo HTTPS. Este protocolo emplea TLS para cifrar la información que se transmite por la red utilizando criptografía asimétrica. En el servidor debe instalarse el certificado web que podrá ser autogenerado o generado por una autoridad de certificación reconocida para evitar alertas en los clientes.

Durante la instalación de Apache HTTP Server se ha generado un certificado autofirmado para probar HTTPS. Se puede ver su uso en sites-available/default-ssl.conf.

Aquí se muestra el contenido del fichero sin comentarios:

<IfModule mod_ssl.c>
	<VirtualHost _default_:443>
		ServerAdmin webmaster@localhost

		DocumentRoot /var/www/html

		ErrorLog ${APACHE_LOG_DIR}/error.log
		CustomLog ${APACHE_LOG_DIR}/access.log combined

		SSLEngine on

		SSLCertificateFile	/etc/ssl/certs/ssl-cert-snakeoil.pem
		SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

		<FilesMatch "\.(cgi|shtml|phtml|php)$">
				SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
				SSLOptions +StdEnvVars
		</Directory>
	</VirtualHost>
</IfModule>

Las directivas más relevantes son:

• <IfModule mod_ssl.c> rodea la definición del sitio porque es preciso que el módulo mod_ssl esté activo.
• El servidor esperará las conexiones de los clientes en el puerto 443.
• SSLEngine on activa el soporte SSL/TLS.
• SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem certificado autogenerado por el paquete ssl-cert.
• SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key clave privada del certificado anterior generada por el paquete  ssl-cert.

Aunque los certificados autogenerados pueden utilizarse de manera segura en Internet no se suelen utilizar porque los navegadores web muestran una advertencia al usuario cuando encuentran un certificado que no ha sido generado por una autoridad de certificación reconocida (por ellos). La mayoría de las autoridades de certificación reconocidas por los navegadores tienen un negocio basado en la venta de certificados, así que para el cliente obtener un certificado que no asuste a los usuarios puede suponer un desenbolso que no es despreciable.

Sin embargo existe una autoridad de certificación que permite obtener cerficados web reconocidos por los navegadores de manera gratuita. Se trata de Let's Encrypt. Utilizando su herramienta certbot —u otro de los clientes— es posible obtener un certificado y renovarlo de manera automática.

Naturalmente la configuración de TLS tiene multitud de parámetros que quedan fuera de esta introducción y hoy en día no se puede considerar segura cualquier configuración que ofrezca HTTPS. Por esta razón resulta inestimable la ayuda de estos dos recursos:

• Mozilla SSL Configuration Generator: Una aplicación web en la que indicando la versión del servidor web utilizado, la versión de OpenSSL y el tipo de configuración que se espera obtener presenta una configuración razonable.
• SSL Server Test: Una aplicación que permite valorar la seguridad de un servidor HTTPS.

Certificado autofirmado

Como se ha explicado en el punto anterior un certificado autofirmado puede ser seguro pero mostrará una advertencia a los usuarios pues los navegadores no reconocerán la autoridad de certificación que lo creó. Para cualquier servicio web público es recomendable obtener un certificado de Let's Encrypt. Sin embargo un certificado autofirmado puede ser de utilidad para servicios internos en los que se quiere asegurar la comunicación y no hay problema en configurar los agentes de usuario que acceden al servidor para que acepten el certificado que este está utilizando.

Se puede crear un certificado autofirmado utiizando openssl con un solo comando:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

Este comando generará los ficheros:

• /etc/ssl/private/apache-selfsigned.key es la clave que se referenciará en la configuración de Apache HTTP Server con la directiva SSLCertificateKeyFile.
  
• /etc/ssl/certs/apache-selfsigned.crt es el certificado que se referenciará en la configuración de Apache HTTP Server con la directiva SSLCertificateFile.
  

El certificado será válido durante 365 días y en el momento de generarlo será necesario contestar algunas preguntas.

Por ejemplo:

Country Name (2 letter code) [AU]:ES
State or Province Name (full name) [Some-State]:Spain
Locality Name (eg, city) []:Santa Coloma de Gramenet
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Institut Puig Castellar
Organizational Unit Name (eg, section) []:ElPuig
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

Se pueden encontrar más información en la traducción del artículo de Bryan Boucheron "Cómo crear un certificado SSL autofirmado para Apache en Ubuntu 18.04".

Rendimiento con HTTP/2

HTTP/2 es la última versión del protocolo HTTP e introduce muchos cambios orientados a conseguir un mejor rendimiento. En el documento http2 explained de Daniel Stenberg —traducido a múltiples idiomas— se puede leer sobre las razones que han llevado al desarrollo de esta nueva versión, los cambios que introduce y sus características de una manera clara y precisa.

La nueva versión del protocolo está disponible combinada con TLS y sin TLS, pero los navegadores únicamente aceptan la versión cifrada. Así que en la práctica, para un servidor web, utilizar HTTP/2 quiere decir utilizar también TLS.

Los nombres que reciben estos protocolos son:

• h2: versión del protocolo cifrada con TLS.
• h2c: versión del protocolo en texto claro sin cifrar.

Naturalmente el servidor web Apache HTTP Server soporta la última versión del protocolo HTTP (h2 y h2c). Para utilizar h2 será necesario:

1. Activar el módulo mod_ssl.
2. Activar el módulo mod_http2.
3. Utilizar la directiva Protocols para indicar los protocolos soportados. Por ejemplo Protocols h2 http/1.1 permitirá atender con HTTP/2 cifrado a los clientes que lo soporten y con HTTP/1.1 a los que no lo soporten.

Así un VirtualHost mínimo con soporte para HTTP/2 podría ser:

<VirtualHost _default_:443>
	ServerAdmin webmaster@localhost
	DocumentRoot /var/www/html

        Protocols h2 http/1.1
	SSLEngine on
	SSLCertificateFile	/etc/ssl/certs/ssl-cert-snakeoil.pem
	SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
</VirtualHost>

Apache como proxy inverso

Cuando Apache funciona como un proxy inverso parece el servidor que publica los contenidos pero, en realidad, cada petición recibida se traslada a otro servidor web —oculto para los clientes—  que devuelve el contenido solicitado.

La razón más habitual para tener un proxy inverso es la seguridad, por ejemplo para publicar con HTTPS o HTTP/2 una aplicación web interna que solo ofrece HTTP.

Otra razón puede ser mejorar el rendimiento al balancear las peticiones de los clientes entre un grupo de servidores internos.

El módulo básico para hacer de proxy es mod_proxy. Pero este módulo necesitará que también se active mod_proxy_http si se va a contactar al servidor interno con HTTP/0.9, HTTP/1.0 o HTTP/1.1 y mod_proxy_http2 si se va a utilizar HTTP/2.

Por ejemplo, suponiendo que queremos preparar un VirtualHost para servir con HTTP/2 y HTTPS una aplicación web HTTP/1.1 que se encuentra en el servidor 172.16.0.19 podríamos utilizar esta configuración básica:

<VirtualHost *:443>
	ServerAdmin webmaster@localhost

        Protocols h2 http/1.1
	SSLEngine on
	SSLCertificateFile	/etc/ssl/certs/ssl-cert-snakeoil.pem
	SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

	ProxyPass "/"  "http://172.16.0.19/"
	ProxyPassReverse "/" "http://172.16.0.19/"
</VirtualHost>

Aunque dependiendo de la aplicación pueden ser necesarios otros ajustes.