You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Race direct vs proxy for shareurl loads, go with “whatever succeeds”
Joe says:
Constraints:
- Don't want to proxy everything (be kind to our servers)
- Don't want to wait a long time for the direct request to fail (flaky network,
weird school blocker)
So we kick off both the proxy and the direct request the first time we have a
proxy-able candidate.
- If the direct request succeeds, cancel the proxy request to CPO and do direct
requests for that domain from this page
- If the direct request fails, use only proxy requests for that domain for this
page
A direct request counts as success if it returns 200 OK and text/plain (making
sure we don't weirdly accept 200 OK with like... a HTML login page because of a
school SSO portal)
I think this is a good balance of server load and letting working clients do
their thing.
Claude says:
Responding to Ben's PR feedback to do better than always-proxy. The
first fetch to an allowlisted host now runs direct + /load-shareurl in
parallel; whichever returns first that verifies (direct = 2xx
text/plain) is served to the caller, and the outcome of the direct
request locks per-host shouldProxy state for the rest of the page-load.
So unrestricted networks pay the proxy hop only once and rapidly switch
to direct; blocked networks see direct fail and switch to proxy.
Header-only verification (rather than body comparison) lets us abort
the in-flight proxy fetch as soon as direct is trusted, keeping server
load near zero on the healthy path. proxyStreamFetch now also tears
down the upstream connection when the client disconnects, so the abort
actually saves bandwidth on the server side too.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments