the way i'm doing it with a subpath is fine though, right?
the way i'm doing it with a subpath is fine though, right?
IA subpath is fine but it won't pre-warm. So like,
example.com/*example.com/foo/*/barIf it can't be sure it will hit the Worker, it won't prewarm.
Da cloudflare employee with unrestricted server access can just read
That said, the number of people with that kind of access is very small.
/proc/[pid]/memThat said, the number of people with that kind of access is very small.
IIt's still going to be fast though. Just not as fast.
ITrue! But at that point it becomes a "who do you trust" kinda thing.
IIf you had an OVH box they could do the same, or an AWS EC2 VM or Lambda... etc.
Dwhere is
cf.zone.nameThe available fields when setting an HTTP request header value using an expression are the following:
Cyea some are there and not on the overall page, and some aren't on either
Dwhat's the diff between
cf.worker.upstream_zonecf.zone.nameIdentifies 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.
Cit 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
D'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)
Dright, also can't do that lol
Cif 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
cf.colo.id <- id of colo, unique for cache
cf.metal.id <- unique metal id in that colo
cf.zone.name
Danything else?
CThe convention of adding
x-I think you could get the worker via
http.request.headers["cf-worker"][0]what's wrong with the uppercase? 
Aren't they converted anyway? I see them as lowercase in my Worker logs
Aren't they converted anyway? I see them as lowercase in my Worker logs
KHTTP/2 lowercases them
Ddoesn't seem to do anything
Care you requesting it via a worker?
Doh
Dno
CI mean that would already be passed to your origin in the cf-worker header anyway if that's a request header rule
DI do the
x-x-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_portI'll make them lower case though, good point
Dgood idea, added!
D
Cmetal and colo id can be genuinely helpful at identifying cache stuff
Cwell not really metal, but colo
Dyeah, so for context this is for long term error logging
Dsince Azure support sucks
Kcf.verified_bot_category is cool tooDweird, I got
"x-client-port": "0", on my first attempt
HIs there a
verified_bot_name?Cdid you already have a connection established?
Knop
DD^ example of part of the stuff I'm logging
DI opened one with curl
HDarn
HDo you have to have a dedicated UA, or just not spoof someone else's?
HBecause I feel like I've seen some crawlers with pretty generic UAs
Dyeah, already logging
verifiedBotCategory since I do a json.stringify on the cfYeah, so if you have IP verify + regex, then you may have two crawlers with similar/same UA, that are differentiated by their IPs, no?
Danything else? 
Dhang on, isn't this pointless since I already log the request headers in my Worker?
C