But Cloudflare could theoretically see your key. They don't. But it's possible, if someone were to

But Cloudflare could theoretically see your key. They don't. But it's possible, if someone were to pull the memory of an ongoing Worker (very difficult and I'm not even sure if it's possible)

Isaac McFadyenOP•1/29/24, 5:56 PM

They'd need to pull the memory of the worker, parse it somehow and extract the key, and then also have access to all the traffic that the Worker accepts (which is encrypted with TLS with Cloudflare's own keys) in order to decrypt it

IIsaac McFadyen I'd also just add that Workers on the whole domain actually increase the startup...

dave•1/29/24, 9:00 PM

the way i'm doing it with a subpath is fine though, right?

Ddave the way i'm doing it with a subpath is fine though, right?

Isaac McFadyenOP•1/29/24, 9:02 PM

A subpath is fine but it won't pre-warm. So like, example.com/*example.com/* will prewarm (because it knows anything for example.com will hit the Worker) but example.com/foo/*example.com/foo/* will not, because only /foo/* hits the worker and /bar/bar wouldn't

Isaac McFadyenOP•1/29/24, 9:02 PM

If it can't be sure it will hit the Worker, it won't prewarm.

IIsaac McFadyen But Cloudflare could *theoretically* see your key. They don't. But it's possible...

dave•1/29/24, 9:02 PM

a cloudflare employee with unrestricted server access can just read

/proc/[pid]/mem

/proc/[pid]/mem

.

That said, the number of people with that kind of access is very small.

Isaac McFadyenOP•1/29/24, 9:02 PM

It's still going to be fast though. Just not as fast.

Ddave a cloudflare employee with unrestricted server access can just read `/proc/[pid]...

Isaac McFadyenOP•1/29/24, 9:03 PM

True! But at that point it becomes a "who do you trust" kinda thing.

Isaac McFadyenOP•1/29/24, 9:04 PM

If you had an OVH box they could do the same, or an AWS EC2 VM or Lambda... etc.

CChaika you could have a transform rule modify request header and include it:

dave•1/29/24, 9:10 PM

where is

cf.zone.name

cf.zone.name

documented again? Trying to see what else I can add

dave•1/29/24, 9:10 PM

ah https://developers.cloudflare.com/rules/transform/request-header-modification/reference/fields-functions/

Available fields and functions for HTTP request header modification...

The available fields when setting an HTTP request header value using an expression are the following:

Ddave where is `cf.zone.name` documented again? Trying to see what else I can add

Chaika•1/29/24, 9:11 PM

yea some are there and not on the overall page, and some aren't on either

dave•1/29/24, 9:13 PM

what's the diff between

cf.worker.upstream_zone

cf.worker.upstream_zone

and

cf.zone.name

cf.zone.name

Chaika•1/29/24, 9:13 PM

Identifies whether a request comes from a worker or not.

When a request comes from a worker, this field will hold the name of the zone for that worker. Otherwise cf.worker.upstream_zone is empty.

Chaika•1/29/24, 9:14 PM

it should be that if a worker running on cookies.com fetches pineapple.org, and you were running this transform rule/etc on pineapple.org cf.zone.name would be pineapple.org, and upstream_zone would be cookies.com

dave•1/29/24, 9:17 PM

'cf.worker.upstream_zone' is not a valid value for expression because the use of field cf.worker.upstream_zone is not allowed (Code: 20087)

dave•1/29/24, 9:17 PM

right, also can't do that lol

Ddave where is `cf.zone.name` documented again? Trying to see what else I can add

Chaika•1/29/24, 9:17 PM

if you're just looking for useful headers to add, I would add
cf.colo.id <- id of colo, unique for cache
cf.metal.id <- unique metal id in that colo
cf.zone.name

CChaika if you're just looking for useful headers to add, I would add cf.colo.id <- id o...

dave•1/29/24, 9:18 PM

anything else?