Sure, it should be pretty fast. Just keep in mind that any data that reaches the Client's Worker is
Sure, it should be pretty fast. Just keep in mind that any data that reaches the Client's Worker is theoretically something they have access to
NI have a question regarding protection against denial of wallet for public worker/function endpoints. In case an attacker found some way to get thousand of ip addresses and used them to send billions of requests to the public endpoint (which is quite common these days), what are some possible approaches/implementations that could turn off your worker automatically if a monthly threshold is exceeded (the threshold could be either the global number of requests or a specific bill amount)?
I believe that in such a scenario for an organisatiton with limited funds, the only thing that you can do is turn off the worker and the availability of its online service (since the bill amount has exceeded you budget or bank account balance). Please correct me if there's other strategies to handle this.
I believe that in such a scenario for an organisatiton with limited funds, the only thing that you can do is turn off the worker and the availability of its online service (since the bill amount has exceeded you budget or bank account balance). Please correct me if there's other strategies to handle this.
CUnderstood, I know it’s something they would be able to see but for the use case it’s slightly better if they don’t have all of the data together, both to protect it but also for updates so we would control data in one place rather than multiple KVs, I’ll look into it!
NOh that would be nice, is there any official documentation for that?
NIt is, but that doesn't mean I wouldn't have to pay the bill if the attacker succeded the ddos...
BActually they take off any legitimate ddoses from your bill 
NThis would be awesome from Cloudflare, but is there any official reference for this that I can share with my collaborators?
BThere's only this message from someone with a role in the server here, it's more of a support policy they have than an official "feature" that would be documented.
https://discord.com/channels/595317990191398933/909458221419356210/1041778929654055026
https://discord.com/channels/595317990191398933/909458221419356210/1041778929654055026
BAll account analytics are accessible over GraphQL if you wanted to build your own kill-switch too: https://developers.cloudflare.com/analytics/graphql-api/
Cloudflare Docs
The GraphQL Analytics API provides data regarding HTTP requests passing through Cloudflare’s network, as well as data from specific products, such as …
BThis is on their site too under the DDoS Page
NThanks a lot for the information 
MIs workers for plattforms already available as a pay-as-you-go option? Docs are still talking about that happening "on April 16th". :|
CC#workers-for-platforms
C
Momg totally missed that, thx!
OIt seems like there's a pretty drastic deviation from the URL spec that might be a recent change?
Adding the
new URLSearchParams({ 'a[]': 'b' }).toString()a%5B%5D=bAdding the
url_original
UHmm interesting. Did you happen to change a compat date or any other flags or did it start erroring without any changes on your end?
OI didn't even make a new deployment
UI see thats quite bad I will see if I can escalate that issue
OAlthough it's possible that the external API that's throwing an error because of this was lenient before
Oso can't pin it down exactly
Oit started happening sometime around the 19th
UAh I see so the issue might be a result of an api change to a 3rd party unrelated to cloudflare?
Kada-url was bumped to 2.7.8 2 weeks ago (11/04) so if that has just hit production then there could be a regression there
K(workerd uses ada-url when using url_standard)
K
KLooks like it's fixing that regression where it didn't escape them - https://github.com/cloudflare/workerd/pull/2008/files#diff-9890fee256b551c112b657b7d25a5d7003705caddf3df8ff7ef1afe17813b340
KIt's possible that hasn't hit production yet, so you're seeing the bad behaviour from before the ada-url bump.
Ono, but the issue might have been hidden before if the 3rd party api is no longer accepting invalid url encoding that they once did
KIt's fixed in workerd, likely just waiting for a rollout.
K@jasnell_ or @kenton might be able to give more insight into that.
Ogreat to hear, have something dependent on this scheduled for this Friday so would love if there's insight on when that rollout will happen 
Kcc @Brendan Irvine-Broque too - hopefully one of them can give you a better answer
KThanks James!
MI keep asking here, but keep getting ignored. Could someone from CF PLEASE respond to these two mothballed threads I raised? I would be most grateful:
HDo you have a repo you can share?
JHey all, I'm stuck on the following. I'm running a local API made accesible via CF tunnel, and linked to a subdomain in the DNS. All works fine, postman works fine. Now when I try to fetch it in a CF worker/page it just times out. From reading up I see that fetching other workers in the same domain can cause problems and that's why service bindings where introduced. But that's where I get stuck. I'm not sure how to bind my tunnel to my page so I can access the API endpoint from my page/worker. Any pointers highly appreciated (new to most of this).
IIt sounds like the api is hosted locally, and just tunneled through CF network. I don’t think service bindings are for that, I think that’s for directly calling functions in other workers
CFrom reading up I see that fetching other workers in the same domain can cause problems and that's why service bindings where introducedA Tunnel isn't a worker though, unless you have another worker in front of it or anything?
You're fetching the subdomain right, and not the raw cfargotunnel hostname?
JAgreed, been reading up in the meantime too. So my focus is not on that.
Here's to workflow I''m trying to achieve: (pseudo names)
not using the cfargotunnel, I have dns cname in place.
Here's to workflow I''m trying to achieve: (pseudo names)
- User uploads a file with a client side POST request using XMLHttpRequest to -> example.com/api/files
- example.com/api/files does in turn do POST request to tunnel.example.com/localapi/files
not using the cfargotunnel, I have dns cname in place.
Cshould be https (although I'm guessing that's not a straight copy from your code)
not using the cfargotunnel, I have dns cname in place.cname is proxied right? Do you get the exact error code it returns (ex: 502, 520, etc)
JSo the weird thing that throws me off is this. If I use postman to call example.com/api/files it works fine files get uploaded to the tunneled API, but when I use XMLHttpRequest call it doesn't. And I don't understand why
Coh, that sounds more like a browser issue, cors or something
JCould be, but what throws me off even more is that I also make calls to supabase for metadata storage in the page/api endpoint, and that works fine. It just refuses to call my tunneled API in the fetch action. Not even a 404 or whatever, just a timeout
Cwell what times out, exactly, with what error code?
CThe browser calling your worker? Your worker calling the tunnel?