Hace unos días me llamó un cliente diciendo que no podía entrar en http://support.microsoft.com. Yo podía entrar perfectamente desde mi enlace, así que este cliente podía tener un problema con su propio enlace o con su solución de filtrado de contenido web. El está utilizando un firewall que tiene instalado un Squid como proxy/cache, y además, está autenticando a sus usuarios vía NTLM, así que me dediqué a chequear los logs en busca de algo que me iluminara.
Los logs no indicaban ningún problema evidente, así que me decanté por una captura de tráfico en la interfaz lan del firewall para poder "ver" qué podía estar pasando entre el navegador del usuario y el proxy. Todo aparentaba estar normal cuando se intentaba acceder al sitio, pero entonces ví que el sitio contestaba de una forma bastante peculiar.
El RFC-2616 (HTTP/1.1) especifica que los servidores web pueden declarar una directiva denominada transfer-encoding en la cabecera de los mensajes para especificar que es necesaria una transformación de los mismos (NO del contenido transportado DENTRO de los mensajes, sino de los mensajes en sí) para asegurar el transporte seguro de estos a través de la red. Esto significa que si el servidor hace una modificación del mensaje para codificarlo de alguna manera, el mismo debe declarar que dicho mensaje fué modificado y especificar dicha transformación, de forma tal que los clientes puedan reconstruir o decodificar el mensaje para poder extraer su contenido posteriormente.
Básicamente, el sitio de soporte de Microsoft trata de forzar el encoding de sus mensajes siempre, independientemente de que la consulta se haga vía HTTP/1.0 (que es la forma en la que Squid hace sus consultas). O sea, a ver si queda claro: el servidor de Microsoft fuerza el transfer-encoding a pesar de que según el RFC (ver sección 3.6.1 del RFC-2616), declarar el transfer-encoding hacia clientes HTTP/1.0 está explícitamente prohibido (¿Microsoft rompiendo standares? ¡Increíble!)
Claro, los usuarios que utilizan Squid como proxy/cache creerán que el problema es de Squid, aunque la realidad es que el problema es del servidor de los "Genios de Seattle"TM...
Para resolver este problema, hay dos opciones posibles:
- Si el usuario utiliza Internet Explorer, puede ir a las Opciones de Internet, y en Avanzadas, y desmarcar la opción que dice "Usar HTTP1.1 para conexiones a través de proxy" (lo cual no es muy bien visto por los administradores de redes de más de dos o tres equipos...)
- Modificar la configuración de Squid para que deniegue el encoding que intenta forzar el servidor, para lo cual hay dos opciones:
- Si está utilizando Squid 2.6.X, deberá agregar una configuracion similar a esta:
acl msbroken dstdomain support.microsoft.com
header_access Accept-Encoding deny msbroken - Si está utilizando Squid 3.X, deberá agregar una configuración similar a esta:
acl msbroken dstdomain support.microsoft.com
reply_header_access Accept-Encoding deny msbroken
request_header_access Accept-Encoding deny msbroken
- Si está utilizando Squid 2.6.X, deberá agregar una configuracion similar a esta:
La razón de la diferencia entre versiones es que la directiva header_access de la versión 2.6.X se reemplazó por las directivas reply_header_access y request_header_access (ver http://wiki.squid-cache.org/Squid-3.0.PRE4-ReleaseNotes) en las versiones 3.X.
Tomen en cuenta que para poder utilizar estas directivas, no se debe configurar la compilación del Squid con la opción --disable-http-violations, ya que sino, dichas directivas no estarán disponibles para ser configuradas e intentar agregarlas a la configuración de Squid generará errores.
Happy hacking!
No hay comentarios:
Publicar un comentario