C#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() should be a%5B%5D=b according to the URL spec, but as you can see here it does not escape the param namesAdding the
url_original compat flag fixes this, but that was changed in 2022 and this has started breaking my apps only recently.
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
Cso you have a nextjs app running on Pages, and the client when it goes to upload a file, goes to a worker (not a function?) which sends it to a tunnel on a subdomain
Jit's an API route on Pages > nextJS\app\api\files\route.ts
Cok so that's a function
Care your inputs identical from what you test in postman as what your app sends to the function?
JYes, when I run the app locally it works, same env, keys everything matches (AFAIK)
JAnd indeed when I call the api function url from postman it also works, but not from the page itself.
Cwhen you say you test in postman, are you testing against the deployed endpoint or the local one?
