So probably a problem with whatever Nitro is doing in the build.
So probably a problem with whatever Nitro is doing in the build.
JPotentially
JRollup also uses rust
JI found this in source code for rollup
J
Jseems to be the error
Jbut I have absolutely no idea how to mitigate it from my source code
J
JI think the issue might be specific to cloudflare. When I run
npx nuxt build on my machine, it works.JNevermind
Jnpx nuxi build --preset=cloudflare_pages fails on my machineJfound the issue - it was in one of my libraries
VHow many routes are limited for workers? I have a webshop where i need to change SEO of a lot of urls 1000+
Is
Sorry this might be a stupid question.
Is
*.domainname/*Sorry this might be a stupid question.
K1,000 routes per zone, and
*.domainname/*
VThank 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?
Can i avoid sending requests to static files?
Dif 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
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/*ai.moda
Workers costs money, Pages are free on every request. You can't use a
SSO for ai.moda.
DI 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.
II'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
KCloudflare does, since they control the end which is the Worker
KIf you mean you're encrypting stuff yourself, i.e PGP, then theoretically anything your Worker can do then Cloudflare could do.
IIf you're using your own keys and doing your own encryption then yeah, CF can't see that data.
IBut 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)
IThey'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
Dthe 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 logsKHTTP/2 lowercases them
