{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihcjiujfzujsxlu6o4ka5pnegbpwfo6xb2ggfvnuhh3syotrvbpcm",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mne6sutrce32"
  },
  "path": "/t/help-please-hypererrorlegacy/176481#post_2",
  "publishedAt": "2026-06-03T03:09:26.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "hyper",
    "hyper-util",
    "reqwest",
    "hyper_util::client::legacy::connect::HttpConnector",
    "enforce_http",
    "hyper-util http.rs",
    "hyper-util source around the scheme check",
    "hyper-rustls",
    "hyper-tls",
    "Client uses TLS by default for HTTPS destinations",
    "default-tls is enabled by default and provides TLS support for HTTPS",
    "default-tls, native-tls, rustls",
    "reqwest feature flags",
    "reqwest feature list",
    "reqwest::tls",
    "HttpsConnectorBuilder",
    "hyper-util legacy client",
    "HttpConnector",
    "HttpConnector::enforce_http",
    "error trying to connect: invalid URL, scheme is not http",
    "1302",
    "postmark email request failed ... hyper_util::client::legacy::Error(Connect, \"invalid URL, scheme is not http\")",
    "Fix OTLP HTTP exporter failing to connect to HTTPS endpoints",
    "invalid URL, scheme is not http",
    "The HTTP crash course nobody asked for",
    "opentelemetry-rust discussion #1198",
    "opentelemetry-rust issue #1302",
    "Apollo MCP Server changelog entry",
    "hyper-util::client::legacy::connect::HttpConnector",
    "hyper-util source containing “invalid URL, scheme is not http”",
    "reqwest TLS docs",
    "OpenTelemetry Rust discussion #1198",
    "OpenTelemetry Rust issue #1302"
  ],
  "textContent": "Hmm??? I have no idea what path led to this or why it happened, but apparently there is a known fix?:\n\n* * *\n\n## Practical diagnosis\n\nThe important part of the error is probably not the outer `HyperErrorLegacy(...)` wrapper, but this inner Rust/hyper error:\n\n\n    hyper_util::client::legacy::Error(\n        Connect,\n        ConnectError(\"invalid URL, scheme is not http\")\n    )\n\n\nThat message usually means:\n\n> 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.\n\nSo 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.\n\n## Why this specific error happens\n\nThe relevant type is hyper_util::client::legacy::connect::HttpConnector.\n\nThe docs describe it as:\n\n> A connector for the `http` scheme.\n\nAlso, its enforce_http option says:\n\n> Option to enforce all `Uri`s have the `http` scheme. Enabled by default.\n\nThe source contains the exact error string:\n\n\n    static INVALID_NOT_HTTP: &str = \"invalid URL, scheme is not http\";\n\n\nSource: hyper-util http.rs\n\nAnd the scheme check is essentially:\n\n\n    if config.enforce_http {\n        if dst.scheme() != Some(&Scheme::HTTP) {\n            return Err(ConnectError {\n                msg: INVALID_NOT_HTTP,\n                addr: None,\n                cause: None,\n            });\n        }\n    }\n\n\nSource: hyper-util source around the scheme check\n\nSo `https://example.com` may be a perfectly valid URL, but it is invalid **for that particular connector configuration**.\n\n## Common causes and fixes\n\nSymptom / setup | Likely cause | Fix\n---|---|---\nFetching `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\nA `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\nA 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\nOTLP / 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\nA 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\nURL really is malformed | Missing scheme, missing host, unsupported scheme such as `file://`, `ftp://`, etc. | Normalize/validate the URL before passing it to the client\n\n## If you are using `reqwest`\n\n`reqwest` normally supports HTTPS. Its docs say:\n\n  * Client uses TLS by default for HTTPS destinations\n  * default-tls is enabled by default and provides TLS support for HTTPS\n  * The TLS module documents the available TLS backends: default-tls, native-tls, rustls\n  * The feature list shows `default-tls` among default features: reqwest feature flags\n\n\n\nA common breakage is accidentally disabling default features:\n\n\n    # Risky if you still need HTTPS:\n    reqwest = { version = \"0.13\", default-features = false, features = [\"json\"] }\n\n\nUse one of these instead:\n\n\n    # Simpler: keep reqwest defaults, including TLS.\n    reqwest = { version = \"0.13\", features = [\"json\"] }\n\n    # Or: keep default-features=false, but explicitly enable a TLS backend.\n    reqwest = { version = \"0.13\", default-features = false, features = [\"json\", \"rustls\"] }\n\n\nDepending 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.\n\n## If you are using `hyper` / `hyper-util` directly\n\nA plain `HttpConnector` is for HTTP:\n\n\n    use hyper_util::client::legacy::connect::HttpConnector;\n\n    let http = HttpConnector::new();\n\n\nThat is not enough for `https://...`.\n\nUse an HTTPS connector instead. With `hyper-rustls`, the shape is roughly:\n\n\n    use http_body_util::Empty;\n    use hyper::body::Bytes;\n    use hyper_util::client::legacy::Client;\n    use hyper_util::rt::TokioExecutor;\n\n    let https = hyper_rustls::HttpsConnectorBuilder::new()\n        .with_native_roots()\n        .expect(\"no native root CA certificates found\")\n        .https_or_http()\n        .enable_http1()\n        .build();\n\n    let client: Client<_, Empty<Bytes>> =\n        Client::builder(TokioExecutor::new()).build(https);\n\n\nRelevant docs:\n\n  * hyper-rustls\n  * HttpsConnectorBuilder\n  * hyper-util legacy client\n  * HttpConnector\n\n\n\nIf you manually wrap a custom `HttpConnector` under a TLS connector, also check whether you need:\n\n\n    http.enforce_http(false);\n\n\nThe 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.\n\n## Known similar reports\n\nThis 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.\n\nProject / context | Example | What it suggests\n---|---|---\nOpenTelemetry Rust | error trying to connect: invalid URL, scheme is not http | HTTPS OTLP endpoint + client feature/config issue\nOpenTelemetry Rust issue | #1302 | A comment points to adding the `reqwest-rustls` feature when using `reqwest-client` with HTTPS\nAtuin / 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\nApollo 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\nUnleash Rust SDK | invalid URL, scheme is not http | Another example where an HTTPS URL still produced this lower-level connector error\nGeneral hyper explanation | The HTTP crash course nobody asked for | Demonstrates the same general class of hyper HTTPS/TLS confusion\n\n## How I would triage this specific report\n\nThe original report says:\n\n\n    I have a few sites and all are returning this when trying to visit on browser..\n    Error: HyperErrorLegacy(hyper_util::client::legacy::Error(Connect, ConnectError(\"invalid URL, scheme is not http\")))\n\n\nThat leaves the actual environment ambiguous.\n\nQuestions that would clarify the cause:\n\nQuestion | Why it matters\n---|---\nWhat 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.\nAre the target sites `https://...`? | The most common trigger is passing HTTPS URLs into an HTTP-only connector.\nIs 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.\nIs 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.\nWas anything recently upgraded? | `reqwest`, `hyper`, `hyper-util`, `opentelemetry-otlp`, or workspace dependency changes can affect TLS features.\nDoes the same URL work with `curl -v https://...` from the same runtime/container? | Helps distinguish URL/site/network problems from application-client configuration problems.\n\n## Minimal checks to run\n\nIf this is your own app or Space, I would check these first.\n\n### 1. Confirm the URL is normal\n\n\n    https://example.com/path\n\n\nNot:\n\n\n    example.com/path\n    //example.com/path\n    http:/example.com\n    file:///tmp/file\n    ftp://example.com\n\n\n### 2. If using `reqwest`, inspect Cargo features\n\nLook for things like:\n\n\n    default-features = false\n\n\nThen make sure TLS is intentionally enabled.\n\n\n    # Example only; check your reqwest version's actual feature names.\n    reqwest = { version = \"0.13\", default-features = false, features = [\"json\", \"rustls\"] }\n\n\n### 3. If using OpenTelemetry OTLP over HTTP\n\nCheck 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`:\n\n  * opentelemetry-rust discussion #1198\n  * opentelemetry-rust issue #1302\n  * Apollo MCP Server changelog entry\n\n\n\n### 4. If using `hyper-util` directly\n\nCheck whether your connector is plain HTTP-only:\n\n\n    let connector = hyper_util::client::legacy::connect::HttpConnector::new();\n\n\nFor HTTPS, use an HTTPS connector:\n\n\n    let https = hyper_rustls::HttpsConnectorBuilder::new()\n        .with_native_roots()\n        .expect(\"no native root CA certificates found\")\n        .https_or_http()\n        .enable_http1()\n        .build();\n\n\nDocs:\n\n  * hyper-rustls\n  * HttpsConnectorBuilder\n  * HttpConnector\n\n\n\n## What this probably is not\n\nThis is probably **not** :\n\n  * a DNS-only problem\n  * a certificate-only problem\n  * a random website outage\n  * a normal browser cache/cookie problem\n  * proof that all the target sites are invalid\n\n\n\nIt can look like a URL problem because the message says `invalid URL`, but the more precise interpretation is:\n\n> The URL scheme is not acceptable to the connector being used.\n\nA valid `https://...` URL can still trigger this if the code path only accepts `http://...`.\n\n## Short answer\n\nMost likely fix:\n\n  * If this is a Rust app: enable HTTPS/TLS support in the HTTP client.\n  * If using `reqwest`: check `default-features = false` and TLS feature flags.\n  * If using `hyper`/`hyper-util`: do not use plain `HttpConnector` for HTTPS; use `hyper-rustls` or another HTTPS connector.\n  * If this happens inside a hosted browser/fetcher/proxy across several unrelated sites: the service operator probably needs to fix the backend fetcher configuration.\n\n\n\nKey references:\n\n  * hyper-util::client::legacy::connect::HttpConnector\n  * HttpConnector::enforce_http\n  * hyper-util source containing “invalid URL, scheme is not http”\n  * hyper-rustls\n  * reqwest TLS docs\n  * reqwest feature flags\n  * OpenTelemetry Rust discussion #1198\n  * OpenTelemetry Rust issue #1302\n\n",
  "title": "Help please.. HyperErrorLegacy"
}