Thank you! How much can workers that are run on whole domain decrease page speed ( the workers are p

Thank you! How much can workers that are run on whole domain decrease page speed ( the workers are pretty simple, like changing H1 to H3?
Can i avoid sending requests to static files?

Vvakno Thank you! How much can workers that are run on whole domain decrease page speed...

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

if you have static files, I recommend using Cloudflare Pages + Workers, if you don't want to pay for a Worker on the static file requests.

https://www.ai.moda/en/blog/do-not-use-custom-domains-for-workers <- this is how my team sets up Workers to play nice with Pages for static files

you can see how it looks in action at https://auth.ai.moda/pages/v1.0.0/login

^ we don't pay for any of the requests except for ones to /api/v0.0.1/*/api/v0.0.1/*

ai.moda

Don't use custom domains for Cloudflare Workers (but do)

Workers costs money, Pages are free on every request. You can't use a

SSO - ai.moda

SSO for ai.moda.

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

I recommend versioning your Workers' routes for things you will have to maintain compatibility with long-term. That way if you want to refactor/rewrite your Worker in the future, you don't have to be scared about breaking things in production for existing users on the older Workers.

Isaac McFadyen•1/29/24, 5:24 PM

I'd also just add that Workers on the whole domain actually increase the startup time of the Worker because of this optimization: https://blog.cloudflare.com/eliminating-cold-starts-with-cloudflare-workers

kian•1/29/24, 5:47 PM

Cloudflare does, since they control the end which is the Worker

kian•1/29/24, 5:47 PM

If you mean you're encrypting stuff yourself, i.e PGP, then theoretically anything your Worker can do then Cloudflare could do.

Isaac McFadyen•1/29/24, 5:55 PM

If you're using your own keys and doing your own encryption then yeah, CF can't see that data.

Isaac McFadyen•1/29/24, 5:55 PM

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 McFadyen•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 McFadyen•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 McFadyen•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 McFadyen•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 McFadyen•1/29/24, 9:03 PM

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

Isaac McFadyen•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.namecf.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_zonecf.worker.upstream_zone and cf.zone.namecf.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?

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

The convention of adding x-x- for custom headers is gone/deprecated and the fact those are uppercase also hurts

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

I think you could get the worker via http.request.headers["cf-worker"][0]http.request.headers["cf-worker"][0], not sure if it would be set that point though hmm

CChaika The convention of adding `x-` for custom headers is gone/deprecated and the fact...

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

what's wrong with the uppercase?

Aren't they converted anyway? I see them as lowercase in my Worker logs

kian•1/29/24, 9:20 PM

HTTP/2 lowercases them

CChaika I think you could get the worker via `http.request.headers["cf-worker"][0]`, not...

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

doesn't seem to do anything

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

are you requesting it via a worker?

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

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

I mean that would already be passed to your origin in the cf-worker header anyway if that's a request header rule

CChaika The convention of adding `x-` for custom headers is gone/deprecated and the fact...

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

I do the x-x- so these headers stand out, and we don't use x-x- in any of our applications (so this avoids ever having an accidental conflict of header names)

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

I think you have most of the useful stuff though, you could grab the edge client port for fun if you wanted too cf.edge.client_portcf.edge.client_port, something you can only get by passing it down.

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

I'll make them lower case though, good point

CChaika I think you have most of the useful stuff though, you could grab the edge client...

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

good idea, added!

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