Apologies for the missing documentation on `resolveOverride`; it seems they were accidentally lost during our recent rewrite of the docs. I actually fixed this last week (in response to a support request which I imagine came from you?). You can now find the feature properly documented here:

https://developers.cloudflare.com/workers/runtime-apis/reque...

The reason we don't allow setting the `Host` header different from the hostname used for routing purposes has nothing to do with "The Web Platform", but rather is important to protect the security of other Cloudflare customers specifically.

Cloudflare customers rely on Cloudflare to block attacks directed at their origin server. This only works if the attacker cannot simply bypass Cloudflare and talk to the origin directly. So, origins need to verify that requests actually came through Cloudflare. The best way to do that is to use Argo Tunnel or Authenticated Origin Pulls (with a unique customer-provided keypair). However, many customers instead rely on firewalling their origin so that it only accepts traffic from Cloudflare's IP ranges.

The problem with this is that anyone can sign up for a Cloudflare account and plug in your origin's IP address as their own. Then, when they send requests to their domain through Cloudflare, those requests will be sent to your origin -- coming from Cloudflare IPs! We have no way to authenticate that the origin IP address actually belongs to the customer.

The main thing that mitigates this attack is that the requests will end up having the `Host` header set to the attacker's domain, not yours. So if your origin server only accepts requests with a `Host` header it recognizes, then you are OK.

Now enter Workers. Workers allow customers to make requests to anywhere on the internet -- from Cloudflare IPs! If the request is directed to another Cloudflare customer, though, we'll treat it as a request coming from the internet, and apply that other customer's security settings. So this does not allow an attacker to bypass Cloudflare's security protections on other customers' domains. But if the attacker could make a request to their own origin, while rewriting the `Host` header to match the victim's hostname, then they could set the victim's origin as their own as described above, while bypassing the `Host` header mitigation. We can't allow that.

`resolveOverride`, however, only works when fetching to hostnames within your own zone, essentially allowing you to rewrite your host's DNS mapping on the fly. Since you already have the power to modify your own DNS, this does not give an attacker any new capabilities. Meanwhile, it solves most use cases where people want to rewrite the `Host` header.

==========================

All that said, it's not clear to me if your use case needs Workers. Could you have configured the DNS entry for www.peergrade.io to be a CNAME of peergrade.wpengine.com? That would cause Cloudflare to forward requests to peergrade.wpengine.com while still having `Host: www.peergrade.io`, which seems like what you want?

==========================

FWIW, the reason we chose "The Web Platform" instead of Node is because web APIs are described by standards that are intended to have multiple implementations, whereas Node's APIs are defined by their implementation. We can't literally use Node.js's implementation because it isn't a sandbox and it doesn't scale to support thousands of tenants on a single machine, which are both critical to the edge compute use case. So, to support Node, we would have to re-implement the Node APIs from scratch. This is something we're considering doing in the future, but it was much easier to get started implementing standardized web APIs.