mirror of
https://github.com/pnpm/pnpm.git
synced 2026-07-14 09:42:37 -04:00
c4acfadd86
On a cache miss the proxy buffered the whole tarball into the cache, verified its SRI, and only then streamed the finished file — a head-of-line stall on every cold fetch: the client waited for the full upstream fetch plus a verify pass before the first byte, with no overlap. Buffer-then-verify is the wrong model for a streaming proxy. Stream the upstream response to the client while teeing it into the cache and hashing it (stream_verified_to_cache); promote the cache entry only once the full body matches dist.integrity. A mismatched/truncated/oversize body is never cached and the client re-verifies what it receives, so a bad upstream tarball can't poison a later client — it just can't be turned into a BAD_GATEWAY, since SRI is only known after the body is already streamed. Converge the namespaced /~<uplink>/ route onto the same model (the integrity is known from the packument either way), removing the now-dead uplink integrity sidecar machinery. Stop forwarding the upstream Content-Length on streamed responses (attacker-controlled, unverifiable before streaming; kept only for the internal early oversize check). Add a cold-pnpr-cache benchmark scenario that actually exercises the cold download/serve path (every other scenario warms the mock); it runs frozen so resolution variance doesn't mask the serve-path delta. The measured speedup on that scenario is modest and within noise (this fixture is small tarballs over a latency-bound link); the change is a correctness fix, and the benchmark confirms no regression. Out of scope: packuments with no usable dist.integrity (pnpm/pnpm#12727).