Help please.. HyperErrorLegacy

Beginners
1

Can anyone help me with this please.. 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”)))

2

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:

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:

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:

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:

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:

3

The usage example for feature extraction fails with this error

from huggingface_hub import InferenceClient
client = InferenceClient()
client.feature_extraction("Hi, who are you?")

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

5

Thank you! But, hmm, I tried a few things from a Colab Free environment, but I still cannot reproduce this…

I tested the reported InferenceClient.feature_extraction(...) path from Google Colab Free.

Platform: Linux-6.6.122+-x86_64-with-glibc2.35
Python:   3.12.13

Results:

huggingface_hub Token Result
1.17.0 yes OK
1.17.0 no normal 401 Unauthorized
0.36.2 yes OK
0.36.2 no normal 401 Unauthorized

With HF_DEBUG=1, the default call:

from huggingface_hub import InferenceClient

client = InferenceClient()
client.feature_extraction("Hi, who are you?")

resolved to the expected router path:

GET  https://huggingface.co/api/tasks
GET  https://huggingface.co/api/models/facebook/bart-base
POST /static-proxy?url=https%3A%2F%2Frouter.huggingface.co%2Fhf-inference%2Fmodels%2Ffacebook%2Fbart-base%2Fpipeline%2Ffeature-extraction

With a token, this worked and returned an ndarray of shape:

(8, 768)

Without a token, the same router URL returned a normal:

401 Unauthorized

So I cannot reproduce:

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

from Colab.

I also tested explicit models:

Model Provider Result
sentence-transformers/all-MiniLM-L6-v2 hf-inference OK, shape (384,)
ibm-granite/granite-embedding-97m-multilingual-r2 hf-inference OK, shape (384,)
thenlper/gte-large hf-inference local ValueError; task metadata says sentence-similarity, not feature-extraction

The thenlper/gte-large result seems unrelated to HyperErrorLegacy; it fails before the router POST.

Relevant docs:

My current guess is that this was either transient, environment-specific, proxy/gateway-specific, region/backend-shard-specific, or related to an endpoint override such as HF_INFERENCE_ENDPOINT / HF_ENDPOINT.

Could the reporter share:

import os
import sys
import huggingface_hub

try:
    import requests
except Exception:
    requests = None

try:
    import httpx
except Exception:
    httpx = None

print("python:", sys.version)
print("huggingface_hub:", huggingface_hub.__version__)
print("requests:", getattr(requests, "__version__", None))
print("httpx:", getattr(httpx, "__version__", None))
print("HF_TOKEN_present:", bool(os.environ.get("HF_TOKEN")))
print("HF_ENDPOINT:", os.environ.get("HF_ENDPOINT"))
print("HF_INFERENCE_ENDPOINT:", os.environ.get("HF_INFERENCE_ENDPOINT"))
print("HF_HUB_DISABLE_IMPLICIT_TOKEN:", os.environ.get("HF_HUB_DISABLE_IMPLICIT_TOKEN"))
print("HTTP_PROXY:", bool(os.environ.get("HTTP_PROXY")))
print("HTTPS_PROXY:", bool(os.environ.get("HTTPS_PROXY")))
print("ALL_PROXY:", bool(os.environ.get("ALL_PROXY")))

and, if possible, rerun with:

HF_DEBUG=1 python repro.py

Please redact any token before posting. The most useful detail would be the HF_DEBUG=1 output showing the exact URL being called.