External Publication
Visit Post

Help please.. HyperErrorLegacy

Hugging Face Forums [Unofficial] June 3, 2026
Source

Hmm??? I have no idea what path led to this or why it happened, but apparently there is a known fix?:

Practical diagnosis

The important part of the error is probably not the outer HyperErrorLegacy(...) wrapper, but this inner Rust/hyper error:

hyper_util::client::legacy::Error(
    Connect,
    ConnectError("invalid URL, scheme is not http")
)

That message usually means:

Some Rust HTTP client stack is trying to connect through a connector that only accepts http:// URIs, while the target is probably https://... or otherwise not an http URI.

So this is probably not a normal browser-side error in the Chrome/Safari/Firefox sense. A regular browser usually would not expose a Rust hyper_util::client::legacy error directly. It is more likely coming from some server-side fetcher, proxy, crawler, agent, hosted “browser” feature, Space/app backend, or library wrapper that uses Rust hyper / hyper-util / reqwest internally.

Why this specific error happens

The relevant type is hyper_util::client::legacy::connect::HttpConnector.

The docs describe it as:

A connector for the http scheme.

Also, its enforce_http option says:

Option to enforce all Uris have the http scheme. Enabled by default.

The source contains the exact error string:

static INVALID_NOT_HTTP: &str = "invalid URL, scheme is not http";

Source: hyper-util http.rs

And the scheme check is essentially:

if config.enforce_http {
    if dst.scheme() != Some(&Scheme::HTTP) {
        return Err(ConnectError {
            msg: INVALID_NOT_HTTP,
            addr: None,
            cause: None,
        });
    }
}

Source: hyper-util source around the scheme check

So https://example.com may be a perfectly valid URL, but it is invalid for that particular connector configuration.

Common causes and fixes

Symptom / setup Likely cause Fix
Fetching https://... with raw hyper / hyper-util fails with scheme is not http Using plain HttpConnector, which is for http:// Use an HTTPS-capable connector such as hyper-rustls or hyper-tls
A reqwest client fails on HTTPS with this error TLS support may have been disabled with default-features = false or missing TLS feature flags Enable default-tls, rustls, or the appropriate TLS feature
A library using reqwest internally fails, even though your own reqwest config looks okay Cargo feature unification / dependency feature mismatch; the inner library’s reqwest may not have TLS enabled Enable that library’s reqwest/rustls/TLS feature, not just your direct reqwest feature
OTLP / OpenTelemetry exporter fails when exporting to an HTTPS endpoint Exporter HTTP client lacks TLS backend Enable the exporter’s reqwest-client / reqwest-rustls feature depending on crate version
A hosted “browser” or link-fetching feature fails across many unrelated sites The hosted proxy/fetcher/backend may be configured with an HTTP-only connector User probably cannot fix locally; service operator must fix the fetcher/client configuration
URL really is malformed Missing scheme, missing host, unsupported scheme such as file://, ftp://, etc. Normalize/validate the URL before passing it to the client

If you are using reqwest

reqwest normally supports HTTPS. Its docs say:

  • Client uses TLS by default for HTTPS destinations
  • default-tls is enabled by default and provides TLS support for HTTPS
  • The TLS module documents the available TLS backends: default-tls, native-tls, rustls
  • The feature list shows default-tls among default features: reqwest feature flags

A common breakage is accidentally disabling default features:

# Risky if you still need HTTPS:
reqwest = { version = "0.13", default-features = false, features = ["json"] }

Use one of these instead:

# Simpler: keep reqwest defaults, including TLS.
reqwest = { version = "0.13", features = ["json"] }

# Or: keep default-features=false, but explicitly enable a TLS backend.
reqwest = { version = "0.13", default-features = false, features = ["json", "rustls"] }

Depending on the exact reqwest version and dependency tree, the feature names may differ slightly, so check the current reqwest feature list and reqwest::tls docs for your version.

If you are using hyper / hyper-util directly

A plain HttpConnector is for HTTP:

use hyper_util::client::legacy::connect::HttpConnector;

let http = HttpConnector::new();

That is not enough for https://....

Use an HTTPS connector instead. With hyper-rustls, the shape is roughly:

use http_body_util::Empty;
use hyper::body::Bytes;
use hyper_util::client::legacy::Client;
use hyper_util::rt::TokioExecutor;

let https = hyper_rustls::HttpsConnectorBuilder::new()
    .with_native_roots()
    .expect("no native root CA certificates found")
    .https_or_http()
    .enable_http1()
    .build();

let client: Client<_, Empty<Bytes>> =
    Client::builder(TokioExecutor::new()).build(https);

Relevant docs:

  • hyper-rustls
  • HttpsConnectorBuilder
  • hyper-util legacy client
  • HttpConnector

If you manually wrap a custom HttpConnector under a TLS connector, also check whether you need:

http.enforce_http(false);

The reason is that HttpConnector::enforce_http is enabled by default. If it remains enabled in the wrong layer, it can reject https://... before the TLS layer gets a chance to handle it.

Known similar reports

This error is not unique to Hugging Face. Similar error strings appear in other Rust-based stacks when HTTPS is attempted without the right TLS connector/features.

Project / context Example What it suggests
OpenTelemetry Rust error trying to connect: invalid URL, scheme is not http HTTPS OTLP endpoint + client feature/config issue
OpenTelemetry Rust issue #1302 A comment points to adding the reqwest-rustls feature when using reqwest-client with HTTPS
Atuin / Postmark postmark email request failed ... hyper_util::client::legacy::Error(Connect, "invalid URL, scheme is not http") reqwest/hyper-util error surfaced through an application wrapper
Apollo MCP Server changelog Fix OTLP HTTP exporter failing to connect to HTTPS endpoints Dependency/TLS feature mismatch left an internal exporter without a TLS backend, causing this exact error for HTTPS telemetry endpoints
Unleash Rust SDK invalid URL, scheme is not http Another example where an HTTPS URL still produced this lower-level connector error
General hyper explanation The HTTP crash course nobody asked for Demonstrates the same general class of hyper HTTPS/TLS confusion

How I would triage this specific report

The original report says:

I have a few sites and all are returning this when trying to visit on browser..
Error: HyperErrorLegacy(hyper_util::client::legacy::Error(Connect, ConnectError("invalid URL, scheme is not http")))

That leaves the actual environment ambiguous.

Questions that would clarify the cause:

Question Why it matters
What exactly is “browser” here? Chrome/Firefox/Safari, a Hugging Face-hosted browsing feature, a Space, an agent, a crawler, or a web preview tool? A normal browser should not usually expose hyper_util internals. A hosted browser/proxy/fetcher might.
Are the target sites https://...? The most common trigger is passing HTTPS URLs into an HTTP-only connector.
Is this happening in a custom Hugging Face Space/app? Then the app’s Rust/HTTP client dependencies and features are the likely place to fix it.
Is this happening in a Hugging Face-provided browsing/link-fetching feature across multiple unrelated sites? Then it may be a server-side service configuration issue, not something the end user can fix.
Was anything recently upgraded? reqwest, hyper, hyper-util, opentelemetry-otlp, or workspace dependency changes can affect TLS features.
Does the same URL work with curl -v https://... from the same runtime/container? Helps distinguish URL/site/network problems from application-client configuration problems.

Minimal checks to run

If this is your own app or Space, I would check these first.

1. Confirm the URL is normal

https://example.com/path

Not:

example.com/path
//example.com/path
http:/example.com
file:///tmp/file
ftp://example.com

2. If using reqwest, inspect Cargo features

Look for things like:

default-features = false

Then make sure TLS is intentionally enabled.

# Example only; check your reqwest version's actual feature names.
reqwest = { version = "0.13", default-features = false, features = ["json", "rustls"] }

3. If using OpenTelemetry OTLP over HTTP

Check whether the exporter/client feature is the one that supports HTTPS/TLS. For example, related reports mention reqwest-client and reqwest-rustls in opentelemetry-otlp:

  • opentelemetry-rust discussion #1198
  • opentelemetry-rust issue #1302
  • Apollo MCP Server changelog entry

4. If using hyper-util directly

Check whether your connector is plain HTTP-only:

let connector = hyper_util::client::legacy::connect::HttpConnector::new();

For HTTPS, use an HTTPS connector:

let https = hyper_rustls::HttpsConnectorBuilder::new()
    .with_native_roots()
    .expect("no native root CA certificates found")
    .https_or_http()
    .enable_http1()
    .build();

Docs:

  • hyper-rustls
  • HttpsConnectorBuilder
  • HttpConnector

What this probably is not

This is probably not :

  • a DNS-only problem
  • a certificate-only problem
  • a random website outage
  • a normal browser cache/cookie problem
  • proof that all the target sites are invalid

It can look like a URL problem because the message says invalid URL, but the more precise interpretation is:

The URL scheme is not acceptable to the connector being used.

A valid https://... URL can still trigger this if the code path only accepts http://....

Short answer

Most likely fix:

  • If this is a Rust app: enable HTTPS/TLS support in the HTTP client.
  • If using reqwest: check default-features = false and TLS feature flags.
  • If using hyper/hyper-util: do not use plain HttpConnector for HTTPS; use hyper-rustls or another HTTPS connector.
  • If this happens inside a hosted browser/fetcher/proxy across several unrelated sites: the service operator probably needs to fix the backend fetcher configuration.

Key references:

  • hyper-util::client::legacy::connect::HttpConnector
  • HttpConnector::enforce_http
  • hyper-util source containing “invalid URL, scheme is not http”
  • hyper-rustls
  • reqwest TLS docs
  • reqwest feature flags
  • OpenTelemetry Rust discussion #1198
  • OpenTelemetry Rust issue #1302

Discussion in the ATmosphere

Loading comments...