feat(http): centralize HTTP client with proxy and custom-CA support#1686
Draft
fengmk2 wants to merge 2 commits into
Draft
feat(http): centralize HTTP client with proxy and custom-CA support#1686fengmk2 wants to merge 2 commits into
fengmk2 wants to merge 2 commits into
Conversation
Builds a single shared reqwest::Client in vite_shared that honors HTTPS_PROXY / HTTP_PROXY / NO_PROXY, loads PEM bundles from SSL_CERT_FILE and NODE_EXTRA_CA_CERTS, and exposes a VP_INSECURE_TLS diagnostic opt-in. Routes every existing reqwest::get / Client::new site in vite_install and vite_js_runtime through it so vp can traverse TLS-intercepting tools like Socket Firewall Free (sfw) and corporate MITM proxies. Adds an install-e2e-test-sfw job (Linux/macOS/Windows) that downloads the upstream sfw binary and runs `sfw vp i -g pnpm@9.15.0` plus `sfw vp install` against vitejs/vite. Gated on the `test: sfw` label for PRs, unconditional on push-to-main. Carries VP_INSECURE_TLS=1 until sfw upstream ships the EKU fix (SocketDev/sfw-free#30, #43); flip removed once that lands to also exercise CA injection. Refs voidzero-dev/setup-vp#73
✅ Deploy Preview for viteplus-preview canceled.
|
fengmk2
added
test: sfw
test: e2e
vite-plus
@voidzero-dev/vite-plus-core
@voidzero-dev/vite-plus-prompts
@voidzero-dev/vite-plus-test
@voidzero-dev/vite-plus-cli-darwin-arm64
@voidzero-dev/vite-plus-cli-darwin-x64
@voidzero-dev/vite-plus-cli-linux-arm64-gnu
@voidzero-dev/vite-plus-cli-linux-arm64-musl
@voidzero-dev/vite-plus-cli-linux-x64-gnu
@voidzero-dev/vite-plus-cli-linux-x64-musl
@voidzero-dev/vite-plus-cli-win32-arm64-msvc
@voidzero-dev/vite-plus-cli-win32-x64-msvc
@voidzero-dev/vite-plus-darwin-arm64
@voidzero-dev/vite-plus-darwin-x64
@voidzero-dev/vite-plus-linux-arm64-gnu
@voidzero-dev/vite-plus-linux-arm64-musl
@voidzero-dev/vite-plus-linux-x64-gnu
@voidzero-dev/vite-plus-linux-x64-musl
@voidzero-dev/vite-plus-win32-arm64-msvc
@voidzero-dev/vite-plus-win32-x64-msvc
commit: |
- Replace `.expect()` on Client::build() with `output::error` + exit(1). Pre-PR, build failure (malformed HTTPS_PROXY, TLS init error) returned Err and was propagated; the OnceLock wrapper turned it into a panic that would re-fire on every subsequent call. Now a clean error and exit instead of a stack trace. - Surface CA-bundle read/parse failures via `output::warn` instead of `tracing::warn!`. tracing is silent unless VITE_LOG is set, hiding the misconfiguration from end users. - Parse SSL_CERT_FILE / NODE_EXTRA_CA_CERTS block-by-block via `Certificate::from_pem`. reqwest's `from_pem_bundle` fails the whole bundle on the first non-cert PEM block (e.g. a private key in the same file), dropping every cert silently. Now per-block: bad blocks warn, good blocks are added. - Use `std::env::var_os` so non-UTF-8 cert paths on Unix are honored. - Skip whitespace-only env values. - Enable reqwest's `system-proxy` feature so macOS System Settings and Windows registry proxies are honored, not just HTTPS_PROXY/HTTP_PROXY. - Add `stream` and `json` reqwest features to vite_shared so the API owner declares them (feature unification still keeps consumers working when their crates redeclare). - Add `error_for_status()?` to download_text so 4xx/5xx becomes an error instead of returning the error body as the "text". - Document SSL_CERT_FILE's additive semantics (differs from OpenSSL). - CI: move VP_INSECURE_TLS from job-level env to the single sfw step so unrelated build/setup steps don't run with cert verification off. - CI: add `--remove-on-error` to the sfw curl so a failed download doesn't leave a 0-byte file that the next step tries to exec.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Track B of voidzero-dev/setup-vp#73 — makes
vp's HTTP client compatible with Socket Firewall Free (sfw) and other TLS-intercepting proxies.Today
vpuses barereqwest::get(url)calls with no sharedClient, no proxy honored, no CA injection. As a result,setup-vp's newsfwinput had to fall back to plainvp installwith a warning on macOS/Windows.This PR:
vite_shared::shared_http_client()— a process-widereqwest::Clientbuilt once viaOnceLock.HTTPS_PROXY/HTTP_PROXY/NO_PROXY(built-in to reqwest 0.13 — no Cargo-feature change needed).SSL_CERT_FILEandNODE_EXTRA_CA_CERTSviaCertificate::from_pem_bundle+add_root_certificate. Parse / read failures log atracing::warn!and fall through.VP_INSECURE_TLS(any value) flipsdanger_accept_invalid_certs(true)and emits a loud stderr warning at startup. Diagnostic only — never recommended for production.reqwest::get/reqwest::Client::newinvite_install(1 site) andvite_js_runtime(3 sites) with the shared client.install-e2e-test-sfw(Ubuntu / macOS / Windows) downloads the upstreamsfwbinary, then runssfw vp i -g pnpm@9.15.0andsfw vp installagainstvitejs/vite. Gated ontest: sfwlabel for PRs, unconditional on push-to-main. CarriesVP_INSECURE_TLS=1until sfw upstream ships the EKU fix (SocketDev/sfw-free#30, #43); removing that flag in a follow-up converts it into a full CA-injection test.Explicitly out of scope: switching macOS/Linux from the baked Mozilla bundle to
rustls-native-certs(Track B step 5 in the upstream issue — separate PR).Test plan
cargo check --all-targetscleancargo clippy --all-targets -- -D warningscleancargo fmt --checkcleancargo test -p vite_shared -p vite_install -p vite_js_runtime— all 647 tests pass (no behavior change for plain HTTPS)test: sfwlabel on this PR to exercise the new CI job across all three OSesmitmproxy:HTTPS_PROXY=http://127.0.0.1:8080 \ SSL_CERT_FILE=~/.mitmproxy/mitmproxy-ca-cert.pem \ vp i -g pnpm@9.15.0warn:line):Follow-ups
VP_INSECURE_TLS=1from the new CI job to validate the CA-injection path end-to-end.rustls-native-certson macOS/Linux so OS-installed CAs work without any env var.Refs voidzero-dev/setup-vp#73