Thank you, but the worker code should not change. The bar.domain2.com is already written as a general-purpose standalone service. The foo.domain1.com is supposed to be able to just setup a DNS record & nothing more.
This would have been the case had bar.domain2.com been a standard server instead of a worker script.
I think the redirect from foo.domain1.com is triggering a GET request on bar.domain2.com, which could be a Worker to Worker trigger. I would try this, tell the browser to make the redirect based on 302 or 301 header, by using a worker on foo.domain1.com.
Something like this:
addEventListener('fetch', event => {
event.respondWith(Redirect(event.request))
})
/**
* Fetch and log a given request object
* @param {Request} request
*/
async function Redirect(request) {
return new Response('', {
status: 302,
headers: {
'Location': 'https://bar.domain2.com'
}
})
}
There is no redirect. There is nothing running in domain1.com except for DNS records.
Ooh, sorry, I read too quickly.
Yeah, it’s not possible to point to Cloudflare domains with CNAME records unless you are on the Enterprise plan.
Maybe an Admin can move this to it’s own topic, since it’s irrelevant to Worker-to-worker requests?
Ah, that’s kinda brutal haha. Not sure how that makes sense when you can CNAME to CNAME across zones for any non-worker behavior. But then adding a $5 subscription item forces you to use the $5k/month plan in order to maintain that behavior… Ouch
Thanks for the help and link & sorry for the noise. There were parts of this issue that made it sound like a DNS access issue. I don’t mind having this move to its own issue.
Yeah, I feel the pain. CNAME was one of the reasons I committed to Workers.
Hi @harris, I’m facing this issue too. I’m wanting to set up a separate identity server via a cloudflare worker. Any updates?
Hi @brandon9, I believe you’re referring to the original topic, same-zone worker-to-worker composition? If so, no, we don’t have any updates to share at this time. Workers can invoke one another across zones, but not on the same zone.
Ok, thanks for the update. I am going to have these two workers set up at different subdomains, so I think I am able to work around it by having them in different zones. The issue I am seeing now is every time I deploy the 2nd worker, the DNS propagation takes long enough that I see substantial downtime at the 2nd zone. Is there anything that can be done to improve this? It seems odd that every deployment of a worker causes the DNS to stop pointing to it for a period of time.
That’s unexpected – deploying a worker on a zone shouldn’t interact with DNS settings at all. I’d suggest filing a support ticket and/or starting a new thread with more details of how to reproduce the problem.
Thanks. If it continues, I will. I was changing some of the tls/ssl security settings, so that might have been impacting things. It seems to have stabilized in the last day or so. If it shows up as a problem again, I’ll post to another thread or a support ticket. Appreciate the support!
Feature request: a brief explanation of this behavior be added to the fetch API docs, the worker routes docs, or ideally both.
Hi @harris just to be sure: within a single account, a Worker for zone A can do a subrequest fetch to a Worker for Zone B?
Emphasis on the within a single account.
If the Worker’s URL is not on the same zone. You would need to jump between two zones or the zone and the workers.dev subdomain.
That’s correct. Whether or not the zones are on the same account shouldn’t make any difference.
However, we recently learned of a bug that may be relevant to your question: a worker cannot call itself, even if it is deployed to multiple zones. For example, a worker named my-worker deployed to both my-worker.me.workers.dev and my-domain.com/* cannot subrequest to itself by fetch()ing the other zone. We’d like to fix this, but it may be a while, since it could represent a breaking change for some currently working configurations.
So basically, two identical workers on two different paths (or one on the zone and one on the workers.dev subdomain).
Thanks, It save a lot of time!
If you want to call one worker, e.g. CSS, from another, e.g. HTML (main page), set a header for your CSS worker - newHeaders.set("Access-Control-Allow-Origin", "*");
not necessarily secure
OR the secure method:
newHeaders.set("Access-Control-Allow-Origin", "https://example.org");
restricts the resource so that only the origin listed is permitted to make use of the resource
newHeaders.set("Cross-Origin-Resource-Policy", "cross-origin");
Which tells the UA that the resource is to be made available cross-origin
newHeaders.set("Cross-Origin-Embedder-Policy", "require-corp");
which tells the UA that the requesting origin must have a viable Cross-Origin-Resource-Policy
Ex: https://html.why.workers.dev calls its style sheet from https://css.why.workers.dev . It’s a single page from a larger site.
I am facing the same issue; getting worker-to-worker requests to work.
I have a main worker-proxy server, that directs traffic to all other endpoints. One of these endpoints is a seperate worker project (serving an react app).
The proxy works fine when the traffic it redirects is outside of Cloudflare; e.g. our backend server. However, when the request goes to another worker, we get the 522 error.
I’ve been playing around with this for a while now, and my current workaround is to use the workers.dev domain instead of using our own hostname. This seems to solve the issue.
I am not sure if there is any unforeseen side effects with this though.
Previously this same proxy worked fine when using Cloudflare Pages (which I assume is also Workers), but after migrating to our own Cloudflare Worker setup, this issue arrived.
This is the current workaround, alternate custom domain to the workers.dev subdomain.
You’ll be interested in this.
They are sort-of Workers, but the issue is only in same account’s Workers. If you have different accounts (not zones) the requests are treated just the same as if you were calling it from any other location.