Fiz uma solicitação POST para um site HTTP (não HTTPS), inspecionei a solicitação nas Ferramentas do desenvolvedor do Chrome e descobri que ele adicionava seu próprio cabeçalho antes de enviá-lo ao servidor:

Upgrade-Insecure-Requests: 1

Depois de fazer uma pesquisa Upgrade-Insecure-Requests, só consigo encontrar informações sobre o servidor que está enviando este cabeçalho:

Content-Security-Policy: upgrade-insecure-requests

Isso parece relacionado, mas ainda muito diferente, pois no meu caso, o CLIENTE está enviando o cabeçalho na solicitação , enquanto todas as informações que encontrei são relativas ao SERVIDOR enviando o cabeçalho relacionado em uma resposta .

Então, por que o Chrome (44.0.2403.130 m) está sendo adicionado Upgrade-Insecure-Requestsà minha solicitação e o que faz?

Atualização 2016-08-24:

Desde então, esse cabeçalho foi adicionado como uma recomendação de candidato do W3C e agora é oficialmente reconhecido.

Para quem acabou de se deparar com essa pergunta e está confuso, a excelente resposta de Simon East explica bem.

O Upgrade-Insecure-Requests: 1cabeçalho costumava estar HTTPS: 1 no rascunho de trabalho anterior do W3C e foi renomeado silenciosamente pelo Chrome antes que a alteração fosse oficialmente aceita.

(Essa pergunta foi feita durante essa transição quando não havia documentação oficial nesse cabeçalho e o Chrome foi o único navegador que enviou esse cabeçalho.)

Resposta curta: está intimamente relacionada ao Content-Security-Policy: upgrade-insecure-requestscabeçalho da resposta, indicando que o navegador suporta (e de fato o prefere).

Levei 30 minutos de busca no Google, mas finalmente a encontrei enterrada na especificação W3.

A confusão veio porque o cabeçalho da especificação era HTTPS: 1, e foi assim que o Chromium a implementou, mas depois disso quebraram muitos sites que eram mal codificados (principalmente WordPress e WooCommerce), a equipe do Chromium pediu desculpas:

"Peço desculpas pela quebra; aparentemente subestimei o impacto com base no feedback durante o desenvolvimento e o beta".
- Mike West, na edição 501842 do Chrome

A solução foi renomear Upgrade-Insecure-Requests: 1e, desde então, as especificações foram atualizadas para corresponder.

De qualquer forma, aqui está a explicação da especificação W3 (como apareceu na época) ...

O HTTPScampo do cabeçalho de solicitação HTTP envia um sinal ao servidor, expressando a preferência do cliente por uma resposta criptografada e autenticada, e que ele pode lidar com êxito com a diretiva upgrade-insegure-orders , a fim de tornar essa preferência o mais uniforme possível.

...

Quando um servidor encontra essa preferência nos cabeçalhos de uma solicitação HTTP, DEVE redirecionar o usuário para uma representação potencialmente segura do recurso solicitado.

Quando um servidor encontra essa preferência nos cabeçalhos de uma solicitação HTTPS, deve incluir um Strict-Transport-Securitycabeçalho na resposta se o host da solicitação for HSTS-safe ou condicionalmente HSTS-safe [RFC6797].

Isso explica a coisa toda:

A diretiva de atualização insegura de solicitações de política de segurança de conteúdo HTTP (CSP) instrui os agentes do usuário a tratar todos os URLs inseguros de um site (aqueles veiculados por HTTP) como se tivessem sido substituídos por URLs seguros (veiculados por HTTPS). Esta diretiva é destinada a sites com um grande número de URLs herdados inseguros que precisam ser reescritos.

A diretiva upgrade-insegure-orders é avaliada antes do conteúdo de bloco com todos os mistos e, se for definido, o último é efetivamente um no-op. É recomendável definir uma diretiva ou outra, mas não as duas.

A diretiva upgrade-insecure-orders não garantirá que os usuários que visitam seu site por links em sites de terceiros sejam atualizados para HTTPS para a navegação de nível superior e, portanto, não substituem o cabeçalho Strict-Transport-Security (HSTS), que ainda deve ser definido com uma idade máxima apropriada para garantir que os usuários não estejam sujeitos a ataques de remoção de SSL.

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