Hi Everyone,
This is a slightly strange request, I want to have control over exactly what headers are returned via a request that uses a webworker. I have script performing everything I want but when it’s returned Cloudflare is injecting it’s own headers that I want to remove such as CF-Ray.
Is this possible?
Thanks
Maybe removing CF headers could become a feature, however I suspect it would require enterprise or a custom solution. See the following article, most of the headers are necessary for Cloudflare to function and ensure it can track bad behaviour and reliably assign IP reputation.
So I understand Cloudflare needs these headers for tracking and billing purposes but for my use-case I need to simulate a client environment on the edge by using workers as a proxy to destination server.
It may sound convoluted but the short explantion is that I have to protect both client's integrity and server's identity while providing added utility through workers as middleware.
Consequently, I need to ensure, the destination server is unaware that request is proxied through the Cloudflare network. This means stripping away request headers like CF-Worker and others. Would it not be possible to remove these after the request leaves the Cloudflare network?
Aside: CDN-Loop header is probably tricky to remove but makes me wonder how Cloudflare handles requests bouncing between a worker and external proxy which removes the cdn-loop header 
The alternative is to have an external proxy between worker and destination server which strips away the cf-* headers but at that point I’m missing out on all the benefits of globally distributed load balancing; might as well transition away from workers altogether 
Even if all headers are removed the Origin server will see that the request is coming from Cloudflares network.
You could try a Header Modification Rule.
I doubt that CF will let you remove any diagnostic headers without an Enterprise plan, and even then it might be unlikely. Honestly, the way this is described sounds like you are up to no good. Is there a way to describe your use case without it sounding like you are trying to MITM the client and origin?
Thanks @michael for your quick response!
Hahaha, I can see how it’s coming across very malcious. But I want to protect client’s integrity so the server does not instantly start flagging them (and potentially deniying them service all together). Secondly, server’s identity(among others things) is not directly known to users (they may extract it but its difficult). Last thing I want is to make this info easily accessible and open up the server to direct abuse (potentially bringing down the service for all users). Easiest solution is to deploy the middleware on the edge. I can assure you the purpose is to only provide a harmless utility plugin of sorts 
Yea the IP alone likely gives away that info, but at least it’s enough to create a resonable doubt; client could be using a VPN which happens to be routed directly or indirectly through cloudflare.
This seems like a nice utility for some future use-cases. I don’t suppose its applicable to standalone workers (on workers.dev domain) without a linked website?
Enterprise plan is likely very expensive at this stage. If it wasn’t for the headers, workers woud’ve seamlessly fit into the solution. I might just get in touch with the service to check if they have any issues with clients accessing their servers in this controlled alternative way. In an ideal world, they might even let me embed this plugin on their servers directly 
I am very sure you won’t be able to scrub the inbound headers (except possibly on an Enterprise plan, though even that is highly unlikely).
Nope. WARP uses a different set of IP addresses than what’s posted at IP Ranges, for very good reasons.
Yea that makes sense, thanks for clarifying!
Welp, it seems forcing workers integration into this project is a dead end. But I have been playing around with them for other small projects and its been an absolutely lovely experience! So thank you for that and all the help regarding this issue 
CF Reverse Proxy to Origin Req headers can not be removed for security reasons so a server admin can always selectively block an abusive 3rd party worker, vs banned the entire Cloudflare ASN by a IP firewall rule on origin. Servers should NOT know what Cf-* headers are and should not change behavior. If your server has an absurd security policy, including the ORDER of HTTP headers in HTTP 1.1, case sensitive header names, and blocking clients with unknown headers. The next monthly Chrome released by Google will statistically get blocked sooner or later. With a worker you CAN scurb/remove all eyeball headers, but you can’t make a CF HTTP req byte wise identical to a Chrome/Safari/FF req to origin.