received corrupt message of type InvalidContentType

O reqwest o mostra no fim de “error sending request for url (…): client error (Connect): received corrupt message of type InvalidContentType”; o ureq, como “io: received corrupt message of type InvalidContentType”. Clientes baseados no OpenSSL relatam a mesma situação como “wrong version number”.

rustls (via reqwest, ureq, tonic) — rustls::Error::InvalidMessage(InvalidContentType): the peer's reply is not TLS

O que significa

O rustls leu o primeiro byte da resposta do servidor como o tipo de conteúdo de um registro TLS e encontrou um valor que nenhum registro TLS pode ter. O outro lado não está falando TLS: normalmente é um servidor HTTP respondendo “HTTP/1.1 …” em uma porta acessada com https://, um servidor gRPC em texto claro ou um proxy que espera HTTP não criptografado.

Por que acontece

• https:// para uma porta que serve HTTP não criptografado

  comum

  Servidores locais de desenvolvimento, sidecars ou portas internas sem TLS.

• Um proxy sem TLS acessado via TLS

  ocasional

  HTTPS_PROXY definido com uma URL https:// para um proxy que só fala HTTP não criptografado com os clientes.

• Um cliente gRPC com TLS e um servidor em texto claro

  ocasional

  Canais do tonic criados a partir de endpoints https:// (ou com configuração TLS) apontados para servidores iniciados sem TLS.

Como corrigir

1. 1.

   Descobrir o que a porta fala

   Se a porta responder em HTTP não criptografado, use http:// ou a porta TLS do servidor.

   curl -si http://127.0.0.1:8080/ | head -1      # plain HTTP answers -> use http:// or the TLS port

2. 2.

   Ajustar o esquema do endpoint ao servidor

   Use endpoints http:// para servidores gRPC em texto claro em redes confiáveis e, nos demais casos, https:// com configuração TLS.

   // tonic: use an http:// endpoint for plaintext servers, https:// + TLS config for TLS servers
   let channel = tonic::transport::Channel::from_static("http://127.0.0.1:50051").connect().await?;

← Ver toda a base de erros de assinatura