Version

hyper-util 0.1.20 (also present in 0.1.16, 0.1.19)

Platform

Windows

Summary

On Windows, Matcher::from_system() reads the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer and assigns its raw string verbatim to builder.http and builder.https. This only works for the
single-proxy form. The per-scheme WinINET form (e.g. http=127.0.0.1:8080;https=127.0.0.1:8443;socks=127.0.0.1:1080) is not parsed, which results in malformed proxy URIs like http://socks=127.0.0.1 being produced downstream.

Code Sample

Configure Windows system proxy with per-scheme entries, so the registry contains, for example:

ProxyServer = socks=127.0.0.1:1080

(This is what Windows writes when only a SOCKS proxy is configured via the Internet Settings UI in some setups, and the same format applies when multiple schemes are configured: http=...;https=...;socks=....)

Then build a client that uses system proxies (e.g. reqwest with the system-proxy feature, which calls hyper_util::client::proxy::matcher::Matcher::from_system()).

Expected Behavior

• socks=host:port should be routed as a SOCKS proxy for all schemes (WinINET semantics: SOCKS applies to all).
• http=host:port should populate the HTTP proxy.
• https=host:port should populate the HTTPS proxy.
• Other tokens (ftp=..., etc.) should be ignored without breaking the rest.

Actual Behavior

The full registry string (e.g. socks=127.0.0.1:1080) is assigned verbatim to both builder.http and builder.https. parse_env_uri() then parses it with http::Uri, finds no scheme, and defaults to http, producing an effective URI like

http://socks=127.0.0.1:1080 — not a usable proxy.

Additional Context

No response