hyperium/hyper

hyper for a long time never bothered with clippy. Mostly for historical reasons and opinions. I've now come around to just turning clippy up to 11. What I'm currently leaning towards is keeping an allowlist, and otherwise denying pedantic and even restriction lints. Yes, I know there's a restriction lint against linting for the restriction group. An allowlist still makes a lot of sense to me. If after a bit it turns out to be just unbearable, we can convert it to a bigger deny list, I guess. The initial config is in place, with a CI job that enforce it, so we won't regress with new code. Now, we just need to evaluate all the undecided lints, and either choose to allow them for sure, or fix them. How to help Look at the list of lints that need to be decided upon in the Cargo.toml (it's around there, the line might move slightly). Pick a lint. If it seems obviously an improvement: Fix up the code from the lint. It might be as simple as cargo clippy --fix --features full. It might be o

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 hype