Hice una solicitud POST a un sitio HTTP (no HTTPS), inspeccioné la solicitud en las Herramientas para desarrolladores de Chrome y descubrí que agregaba su propio encabezado antes de enviarlo al servidor:

Upgrade-Insecure-Requests: 1

Después de buscar Upgrade-Insecure-Requests, solo puedo encontrar información sobre el servidor que envía este encabezado:

Content-Security-Policy: upgrade-insecure-requests

Esto parece relacionado, pero sigue siendo muy diferente, ya que en mi caso, el CLIENTE está enviando el encabezado en la Solicitud , mientras que toda la información que he encontrado se refiere al SERVIDOR que envía el encabezado relacionado en una Respuesta .

Entonces, ¿por qué Chrome (44.0.2403.130 m) se agrega Upgrade-Insecure-Requestsa mi solicitud y qué hace?

Actualización 2016-08-24:

Este encabezado se ha agregado desde entonces como una Recomendación del candidato del W3C y ahora se reconoce oficialmente.

Para aquellos que acaban de encontrar esta pregunta y están confundidos, la excelente respuesta de Simon East lo explica bien.

El Upgrade-Insecure-Requests: 1encabezado solía estar HTTPS: 1 en el borrador de trabajo anterior del W3C y Chrome le cambió el nombre en silencio antes de que el cambio fuera aceptado oficialmente.

(Esta pregunta se hizo durante esta transición cuando no había documentación oficial sobre este encabezado y Chrome fue el único navegador que envió este encabezado).

Respuesta corta: está estrechamente relacionada con el Content-Security-Policy: upgrade-insecure-requestsencabezado de respuesta, lo que indica que el navegador lo admite (y de hecho lo prefiere).

Me tomó 30 minutos de búsqueda en Google, pero finalmente lo encontré enterrado en la especificación W3.

La confusión se debe a que el encabezado en la especificación era HTTPS: 1, y así es como Chromium lo implementó, pero después de esto rompió muchos sitios web que estaban mal codificados (particularmente WordPress y WooCommerce) el equipo de Chromium se disculpó:

"Pido disculpas por la ruptura; aparentemente subestimé el impacto basado en los comentarios durante el desarrollo y la versión beta".
- Mike West, en Chrome Issue 501842

Su solución fue cambiarle el nombre Upgrade-Insecure-Requests: 1y la especificación se ha actualizado para que coincida.

De todos modos, aquí está la explicación de la especificación W3 (como apareció en ese momento) ...

El HTTPScampo de encabezado de solicitud HTTP envía una señal al servidor que expresa la preferencia del cliente por una respuesta encriptada y autenticada, y que puede manejar con éxito la directiva de actualización de solicitudes inseguras para que esa preferencia sea lo más fluida posible.

...

Cuando un servidor encuentra esta preferencia en los encabezados de una solicitud HTTP, DEBE redirigir al usuario a una representación potencialmente segura del recurso que se solicita.

Cuando un servidor encuentra esta preferencia en los encabezados de una solicitud HTTPS, DEBE incluir un Strict-Transport-Securityencabezado en la respuesta si el host de la solicitud es seguro para HSTS o condicionalmente seguro para HSTS [RFC6797].

Esto explica todo:

La directiva HTTP-Content-Security-Policy (CSP) actualizar-inseguras-solicitudes instruye a los agentes de usuario a tratar todas las URL inseguras de un sitio (aquellas servidas sobre HTTP) como si hubieran sido reemplazadas por URL seguras (aquellas servidas sobre HTTPS). Esta directiva está destinada a sitios web con un gran número de URL heredadas inseguras que deben reescribirse.

La directiva de actualización de solicitudes inseguras se evalúa antes de bloquear todo el contenido mixto y, si se establece, esta última es efectivamente una no operativa. Se recomienda establecer una directiva u otra, pero no ambas.

La directiva de actualización de solicitudes inseguras no garantizará que los usuarios que visiten su sitio a través de enlaces en sitios de terceros se actualicen a HTTPS para la navegación de nivel superior y, por lo tanto, no reemplacen el encabezado Strict-Transport-Security (HSTS), que aún debe establecerse con una edad máxima adecuada para garantizar que los usuarios no estén sujetos a ataques de eliminación de SSL.

Fuente: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests