Cloudflare Developers•9mo ago

fetching openai?

CChaika fetching openai?

Avi•4/28/25, 7:08 PM

yes

Avi•4/28/25, 7:08 PM

literally just calling the moderation endpoint

Avi•4/28/25, 7:08 PM

i can't fetch it from our DOs, even though we are ensuring that the DOs aren't in Hong Kong (unsupported by OpenAI)

Avi•4/28/25, 7:10 PM

its like somehow cloudflare is looking at the incoming http request, keeping track of its geo info, and then automatically attaching that to my subrequests

Avi•4/28/25, 7:10 PM

which i dont want, and frankly, seems like a privacy issue

Avi•4/28/25, 7:11 PM

i just can't figure out which data that is... i'm looking at the http headers, and i'm not seeing which one is even being used to make this determination

ChaikaOP•4/28/25, 7:13 PM

going to test something quick but I think the key here is that openai's api is behind Cloudflare

Avi•4/28/25, 7:14 PM

yes, it does seem like something magical is happening because its a cf-to-cf request

ChaikaOP•4/28/25, 7:17 PM

yea like in this situation:
I have one domain (chaika.me) with a worker custom domain & Durable Object spun up in South Korea, ICN
I'm proxying a fetch request to it, cross-zone (to another zone same acct, tylerobrien.dev)
and on my other website, all the geolocation data came through

"EdgeColoCode": "ICN",
and
"ClientIP": "2a06:98c0:3600::103", (worker's ip)
but
"ClientCountry": "us",
"ClientDeviceType": "desktop",

"cf-ipcontinent": "NA",
"cf-ipcountry": "US",
"cf-region": "New York",
"cf-region-code": "NY",
"cf-timezone": "America/New_York",

ChaikaOP•4/28/25, 7:18 PM

this isn't cross-account, just cross-zone, but it's probably the same thing. The IP isn't preserved, by the geo data is

ChaikaOP•4/28/25, 7:19 PM

perhaps to prevent durable objects and workers being abused for this exact thing. It knows it can trust the geodata from the incoming request

CChaika yea like in this situation: I have one domain (chaika.me) with a worker custom d...

Hard@Work•4/28/25, 7:23 PM

Does that happen if you create a new request?

ChaikaOP•4/28/25, 7:24 PM

if you are to fetch something non-cloudflare, because it just has the IP, it's proper

ChaikaOP•4/28/25, 7:24 PM

but even on a diff acct of mine which returns cf's geoip headers, still wrong

HHard@Work Does that happen if you create a new request?

ChaikaOP•4/28/25, 7:24 PM

a whole new request in the durable object?

Avi•4/28/25, 7:24 PM

that's what i'm doing and it doesn't work, @Hard@Work

Avi•4/28/25, 7:25 PM

i even creating the request in a

setTimeout

setTimeout

Avi•4/28/25, 7:25 PM

in case there was some magic about the subrequest coming from that particular incoming fetch request

Avi•4/28/25, 7:25 PM

of course they could still attribute it somehow

Avi•4/28/25, 7:26 PM

what i'm discovering, though, is that despite my jurisdiction being set to

'eu'

'eu'

, the DO is still being created in

'HK'

'HK'

......

ChaikaOP•4/28/25, 7:26 PM

I remake the request I send to the Durable Object (not including the incoming headers) and the durable object just uses the url passed to it

CChaika a whole new request in the durable object?

Hard@Work•4/28/25, 7:27 PM

Yeah, I meant if the incoming Request has GeoIP attached, does it still pass it along if you create a new Request from scratch?

ChaikaOP•4/28/25, 7:28 PM

const newUrl = new URL("https://literallyanything/");
newUrl.searchParams.set("url", url.searchParams.get("url"));
var response = await durableObject.fetch(new Request(newUrl, { method: "GET" }));

Worker code

const url = new URL(request.url).searchParams.get("url");
if (!url) {
return new Response("url query parameter is required", { status: 400 });
}
return fetch(url, {
headers: {
"do-age":
${Date.now() - this.createdAt}
${Date.now() - this.createdAt}

}
});

in durable object

ChaikaOP•4/28/25, 7:28 PM

aw should have used proper markdown for code, anyway, no explicit headers being passed/not passing the request

AAvi what i'm discovering, though, is that despite my jurisdiction being set to `'eu'...

ChaikaOP•4/28/25, 7:29 PM

how are you making your DO IDs? Are you using

env.MY_DURABLE_OBJECT.jurisdiction("eu").idFromName("my-name");
env.MY_DURABLE_OBJECT.jurisdiction("eu").newUniqueId()

and such?

Avi•4/28/25, 7:30 PM

more or less, yes

Avi•4/28/25, 7:30 PM

i create the binding tied to the jurisdiction

Avi•4/28/25, 7:30 PM

then call

idFromName

idFromName

on that binding

Avi•4/28/25, 7:30 PM

hmmmmmm i guess, the issue could be that I clone the incoming request

Avi•4/28/25, 7:30 PM

when i pass to the DO

Avi•4/28/25, 7:31 PM

and that includes whatever incoming stuff there is

Avi•4/28/25, 7:31 PM

        const durableObjectStub = binding.get(durableObjectId);
        return await durableObjectStub.fetch(request.clone());

        const durableObjectStub = binding.get(durableObjectId);
        return await durableObjectStub.fetch(request.clone());

Avi•4/28/25, 7:35 PM

yeah, confirmed, i have the jurisdiction set and yet, the

loc

loc

i get from

cgi-bin/trace

cgi-bin/trace

shows

HK

HK

Avi•4/28/25, 7:35 PM

even weirder:

Avi•4/28/25, 7:35 PM

colo: IAD
loc: HK

Avi•4/28/25, 7:35 PM

in other words, we're running from a US data center (IAD), yet the location is still HK

AAvi in other words, we're running from a US data center (IAD), yet the location is s...

ChaikaOP•4/28/25, 7:36 PM

ignore the

loc

loc

, that's tied to GEOIP and is the same thing I was showing above (that original request geoip is what gets passed)

ChaikaOP•4/28/25, 7:38 PM

the

colo

colo

being IAD for an eu jurisdiction is more interesting, somehow your jurisdiction isn't being set properly, you'd probably want to look further up on your namespace setup