Como todo programador web que se precie, más temprano que tarde acabarás por utilizar el inspector de tráfico de Google Chrome o cualquier otro analizador de protocolos como por ejemplo el magnífico Fiddler. Estas utilidades sirven para inspeccionar todo el tráfico web saliente y poder ver exactamente qué datos se intercambian, poder modificar peticiones y respuestas, etc... lo cual es de gran ayuda para depurar las aplicaciones Web.

Si inspeccionas tráfico generado por Google Chrome verás una cabecera muy rara en casi todas las peticiones dirigidas a través de HTTP:

Upgrade-Insecure-Requests

¿Qué es esta cabecera "Upgrade-Insecure-Requests"?

Se trata de la implementación en Chrome de la especificación del mismo nombre creada por el World Wide Web Consortium (W3C). Se trata de un mecanismo que trata de generar conexiones más seguras para los usuarios.

Así, cuando un navegador u otro cliente Web se conecta a un canal que no considera suficientemente seguro, puede solicitar al servidor un cambio a un protocolo más seguro antes de lanzar la verdadera petición y que por lo tanto no se transmita información de manera no-segura.

Para ello envía la petición con una cabecera especial, que es la que hemos visto en la figura anterior, llamada Upgrade-Insecure-Requests.

Según dice la especificación:

The Upgrade-Insecure-Requests HTTP request header field sends a signal to the server expressing the client’s preference for an encrypted and authenticated response, and that it can successfully handle the upgrade-insecure-requests directive in order to make that preference as seamless as possible to provide.

Si el servidor está de acuerdo con esto y puede atender la petición con un protocolo más seguro (normalmente HTTPS, claro), lo que hará será contestar con una redirección al mismo recurso, pero usando el protocolo seguro en lugar del inseguro.

O sea, el proceso es:

  1. El navegador solicita un recurso web a través de HTTP (no-securizado), por ejemplo, http://www.miservidor.com/carpeta/recurso/ e incluye una cabecera "Upgrade-Insecure-Requests" con valor 1 para indicar que prefiere un protocolo seguro
  2. El servidor al ver esa cabecera, si tiene disponibilidad de usar un protocolo seguro (SSL/TSL en este caso), debería redirigir al navegador hacia una versión segura de la URL (por ejemplo https://www.miservidor.com/carpeta/recurso/), así que devuelve una cabecera de redirección (con estatus 307 de movido temporalmente)
  3. El navegador se dirige a la nueva URL segura y continua con la navegación.

El esquema del tráfico sería algo similar a esto:

El servidor solicita la página a través de HTTP tal y como le indica el usuario, pero incluye la cabecera de subir el nivel de seguridad:

GET /Carpeta/Recurso HTTP/1.1
Host: www.miservidor.com
Upgrade-Insecure-Requests: 1

El servidor recibe la petición y si es capaz de entender la cabecera, en lugar de devolver el recurso lo que hace es devolver un código de estado 307 y redirige al navegador a la versión segura del recurso, en este caso la misma dirección pero con HTTPS:

HTTP/1.1 307 Moved Temporarily
Location: https://www.miservidor.com/Carpeta/Recurso
Vary: Upgrade-Insecure-Requests

Además, y esto es importante, incluye una cabecera de tipo "Vary" indicando el motivo de la variación (que es la cabecera anterior) para evitar que algún proxy intermedio pueda servir la página desde una caché en lugar de solicitarla ala nueva dirección.

No es obligatorio que el servidor responda de esta manera y genere una versión segura del recurso, pero sí que es recomendable y seguramente a medio/largo plazo será muy recomendable, ya que basta que Google decida que los servidores que no lo hagan bajen el ranking en las búsquedas, para que todo el mundo deba hacerlo. Además, realmente la especificación dice claramente que el servidor debería responder de esta manera.

Hoy por hoy no ocurre nada si no lo haces, pero Chrome lo hace por defecto en todas las peticiones :-S

Conseguir que el servidor se responda a esta cabecera es relativamente fácil. En un posterior post explicaré cómo conseguirlo con Internet Information Server.

Nota de interés: En la versión 44 de Chrome que salió en verano de 2015, en lugar de utilizar esta cabecera usaron simplemente una llamda "HTTPS" para indicar que prefieren una conexión segura. El problema es que, de repente, solo por ese pequeño cambio miles de sitios web empezaron a romper por todo Internet. En especial sitios con Wordpress y software similar de este tipo hecho con PHP. Solo WooCommerce está en cerca de un millón de sitios web, y rompía con Chrome por culpa de esto. El motivo es que la mayor parte del software escrito con PHP interpreta esa variable de servidor ($_SERVER['HTTPS'];) como que la petición se está ejecutando a través de un protocolo seguro, cuando no era el caso, y las aplicaciones rompían. Sacaron un parche en unos días y en la siguiente versión 45 lo corrigieron y lo cambiaron por esta cabecera propia de la especificación del W3C.

¡Espero que te sirva de ayuda!

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor