Actually they take off any legitimate ddoses from your bill š
Actually 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?
Jno error code nothing, I tried realtime logging and tail and whatever I could find. Whenever it fetches the whole try/catch block with fetch is ignored.
JAnd, locally running my nextJS app everything works fine, whenever I build it on cf pages it stops working
Cgotta be something somewhere lol
Cwhat does cloudflare return in the response to the worker, when it fails?
Jall the log events come back until the fetch call, then it does nothing, no error code, just a 200 ok but with lot's of expected log events missing
