4 ms·

Big fans of Workers here. It has made our developmental, operational, and deploymental nightmares go away. ...but we've consistently seen users complain about

Big fans of Workers here. It has made our developmental, operational, and deploymental nightmares go away. ...but we've consistently seen users complain about latency and we have observed Cloudflare does not run Workers in the nearest location to the user. This can been semi-confirmed via https://cloudflare-test.judge.sh https://cloudflare-test.judge.sh Our endpoints are always routed to a destination which is not the nearest whilst other enterprise and business domains get served from a nearer location. This can also be confirmed using Coudflare's own https://www.cloudflare.com/cdn-cgi/trace https://www.cloudflare.com/cdn-cgi/trace endpoint (substitute www.cloudflare.com with any of your Workers endpoint to see how differently it is routed. I've been told it might be fickleness of anycast routing and it could be). Disappointing since it is hard to get customer service reps to look at your support tickets when you're on a "free account" (despite paying for Workers). We have no use for Cloudflare's other products and so it doesn't make sense to purchase pro/business subscriptions. That said, I'd still recommend using it since it so darn fast. Edit: Apologies to everyone for an unrelated rant. It was impulsive. I'm unable to delete this comment.

foota 6y ago
This isn't terribly surprising to me, they might not have the compute deployed in all their sites to serve the more expensive worker requests.
kentonv 6y ago
To clarify: - Workers run in the colo that received the request. We currently literally have no capability to forward Workers requests to other colos. (It's possible we'll introduce that in the future, but it's not the case today.) - Enabling Workers does not affect how your traffic is routed to colos. So if you're seeing Workers requests not going to the closest colo today, then regular non-Workers requests wouldn't either. It sounds like the issue here is that your base Cloudflare plan is the "free" plan (confusingly-named because you're separately paying $5/month for workers on top of that). When we have a colo that doesn't have enough capacity to handle all the local traffic, we often route free-plan traffic away from it, and they end up landing at the next-closest colo. This is completely unrelated to Workers -- it applies to any kind of Cloudflare traffic. If you upgrade to a higher plan level (e.g. pro at $20/month), you should see this happen much less often, if ever. Sorry that this is confusing! We should probably document this better. (I'm the lead engineer on Workers.)
- gravyboat 6y ago
  Hey Kenton. I recently migrated a few of my static sites to Workers and was hoping you could clarify what the teams plan is around security headers. The only documentation I could find was some random blog post from 2 years ago that didn't help as the way workers function has changed since then and it's no longer as simple as just dropping in a few lines of code. I'd love to easily configure security headers so my sites are getting good ratings again, but I couldn't find it in the documentation and it doesn't seem like there's been any update to support this. Is your team working on making security headers easier to enable for workers or is there something I missed for setting this up?
  - kentonv 6y ago
    Hi! Hmm, not sure I understand. In a Worker, you can set whatever headers you want on the response, in code. What problem are you running into exactly? What do you mean when you say "the way workers function has changed"?
    - gravyboat 6y ago
      Sorry if I wasn't clear. Yes I understand I can set whatever headers I want in a response via the edit options for my workers. The problem I'm running in to is that I created a worker for a static site and it has a massive 1 line JS blob for the script section that I have to go through to set this. I never created this, it's just what was set up when I used Wrangler to deploy my static site. This is fine except it's a huge hassle to modify and I'm actually a bit surprised that by default workers don't use secure headers. I figured they would since they're pretty standard now and I'd rather have to disable them if I needed then to manually configure them. If someone isn't familiar with security headers there's also a good chance they would deploy their site and never enable them which makes sites running on workers less secure by default. I'm going off this several year old blog post: https://scotthelme.co.uk/security-headers-cloudflare-worker/ https://scotthelme.co.uk/security-headers-cloudflare-worker/ that talks about how to set this up and it seems like functionality has changed a bit since then, or maybe I am misunderstanding their screenshots. Outside of this I can't find any documentation from Cloudflare about setting these headers that is more recent, or what I would need to set for a new worker that has recently been created to get this functionality. So I guess my question is two fold, are there plans to make it easier to enable secure headers than to manually modify the worker itself? My plan is to do that currently once I stop slacking and decide to just parse this giant JS blob. My second question is are there any plans to add documentation around functionality such as this? I was really shocked to see that secure headers weren't something that's simply enabled by default and even more so when I looked through the docs and didn't see any examples on how to set them up. Maybe my use case is niche, but I thought secure headers were pretty standard at this point.

foota 6y ago

This isn't terribly surprising to me, they might not have the compute deployed in all their sites to serve the more expensive worker requests.

kentonv 6y ago

To clarify: - Workers run in the colo that received the request. We currently literally have no capability to forward Workers requests to other colos. (It's possible we'll introduce that in the future, but it's not the case today.) - Enabling Workers does not affect how your traffic is routed to colos. So if you're seeing Workers requests not going to the closest colo today, then regular non-Workers requests wouldn't either. It sounds like the issue here is that your base Cloudflare plan is the "free" plan (confusingly-named because you're separately paying $5/month for workers on top of that). When we have a colo that doesn't have enough capacity to handle all the local traffic, we often route free-plan traffic away from it, and they end up landing at the next-closest colo. This is completely unrelated to Workers -- it applies to any kind of Cloudflare traffic. If you upgrade to a higher plan level (e.g. pro at $20/month), you should see this happen much less often, if ever. Sorry that this is confusing! We should probably document this better. (I'm the lead engineer on Workers.)

gravyboat 6y ago
Hey Kenton. I recently migrated a few of my static sites to Workers and was hoping you could clarify what the teams plan is around security headers. The only documentation I could find was some random blog post from 2 years ago that didn't help as the way workers function has changed since then and it's no longer as simple as just dropping in a few lines of code. I'd love to easily configure security headers so my sites are getting good ratings again, but I couldn't find it in the documentation and it doesn't seem like there's been any update to support this. Is your team working on making security headers easier to enable for workers or is there something I missed for setting this up?
- kentonv 6y ago
  Hi! Hmm, not sure I understand. In a Worker, you can set whatever headers you want on the response, in code. What problem are you running into exactly? What do you mean when you say "the way workers function has changed"?
  - gravyboat 6y ago
    Sorry if I wasn't clear. Yes I understand I can set whatever headers I want in a response via the edit options for my workers. The problem I'm running in to is that I created a worker for a static site and it has a massive 1 line JS blob for the script section that I have to go through to set this. I never created this, it's just what was set up when I used Wrangler to deploy my static site. This is fine except it's a huge hassle to modify and I'm actually a bit surprised that by default workers don't use secure headers. I figured they would since they're pretty standard now and I'd rather have to disable them if I needed then to manually configure them. If someone isn't familiar with security headers there's also a good chance they would deploy their site and never enable them which makes sites running on workers less secure by default. I'm going off this several year old blog post: https://scotthelme.co.uk/security-headers-cloudflare-worker/ https://scotthelme.co.uk/security-headers-cloudflare-worker/ that talks about how to set this up and it seems like functionality has changed a bit since then, or maybe I am misunderstanding their screenshots. Outside of this I can't find any documentation from Cloudflare about setting these headers that is more recent, or what I would need to set for a new worker that has recently been created to get this functionality. So I guess my question is two fold, are there plans to make it easier to enable secure headers than to manually modify the worker itself? My plan is to do that currently once I stop slacking and decide to just parse this giant JS blob. My second question is are there any plans to add documentation around functionality such as this? I was really shocked to see that secure headers weren't something that's simply enabled by default and even more so when I looked through the docs and didn't see any examples on how to set them up. Maybe my use case is niche, but I thought secure headers were pretty standard at this point.