Repository navigation
Explain that Functions outbound requests leave from shared addresses - #74
Conversation
Explain that fetch() from a worker leaves from Cloudflare's shared network addresses rather than a dedicated or fixed IP per space, so an API that limits by IP can answer 429 on the first request. List the options that work today: per-key authentication, retry with backoff, caching in env.DB, and calling CORS-enabled APIs from the browser.
|
@indent please review this PR and post any findings as review comments. Please don't push commits to the branch. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
No issues found.
All required CI checks passed on
Select any unchecked box below to run or rerun that agent. Passed (1)Full resultsIndent Review Agent
|
|
I've started the review of this PR. I won't push any commits to the branch. Any findings will show up in the review banner. |
|
The review of PR #74 found no defects. The agent checked the shared-egress claims against the Functions host code. It also confirmed the |
The Functions page now says that a worker's outbound requests come from shared addresses, so a third-party API can answer
429on the first call, and lists what to do about it.Summary
fetch()leaves through the same Cloudflare host worker. There is no proxy, static IP, or per-space routing in between.env.DB, and calling CORS-enabled APIs from the browser.Testing
verify:generated,check,validate,build,test:docs,audit,verify:public-safety,verify:prose, andverify:routes.