received corrupt message of type InvalidContentType

reqwest shows it at the end of "error sending request for url (…): client error (Connect): received corrupt message of type InvalidContentType"; ureq as "io: received corrupt message of type InvalidContentType". OpenSSL-based clients report the same situation as "wrong version number".

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

What it means

rustls read the first byte of the server's reply as a TLS record content type and found a value that no TLS record can have. The peer is not speaking TLS: typically an HTTP server answering "HTTP/1.1 …" on a port reached with https://, a plaintext gRPC server, or a proxy expecting plain HTTP.

Why it happens

• https:// to a plain-HTTP port

  common

  Local development servers, sidecars or internal ports without TLS.

• A plain proxy reached with TLS

  occasional

  HTTPS_PROXY set to an https:// URL for a proxy that only speaks plain HTTP to clients.

• A gRPC client with TLS against a plaintext server

  occasional

  tonic channels created from https:// endpoints (or with TLS config) against servers started without TLS.

How to fix it

1. 1.

   Find out what the port speaks

   If plain HTTP answers, use http:// or the server's TLS port.

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

2. 2.

   Match the endpoint scheme to the server

   Use http:// endpoints for plaintext gRPC servers on trusted networks and https:// with TLS configuration otherwise.

   // 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?;

← Browse the full signature error database