Bug: Fetch() returns nonsense 307 when called under a pages domain
Fun bug for you. foo.domain.com is a pages domain - works great btw!
I mounted a worker at foo.domain.com/api that does a fetch - the fetch target is a digital ocean load balancer at foo-api.domain.com
In this case, domain.com is managed by cloudflare but foo-api.domain.com has NS pointed to digital ocean.
My fetch returns, from cloudflares servers
"307 https://foo-api.domain.com" -- it is 307'd to itself.
This behavior doesn't happen if i use the workers.dev domain for my worker, then the fetch works fine. But when the worker lives under foo.domain.com (pages domain) it behavses this way.
1 Reply
Here's a ray Id of an example if it helps:
8dc4ad61f7d5bcc6-ATL
I tried moving my domain management away from cloudflare to godaddy but no luck.
Leo; I'm sorry, I don't quite understand; I'm not that familiar with the cloudflare settings
Do you mean to change settings on the pages domain 'foo.domain.com' , which has the worker mounted under it, or foo-api.domain.com, which the worker is fetching?
Either way, I don't quite see the relationship. If you are thinking this is a 307 redirect to force http->https; that shouldnt be happening becasue both requests are being explicitly made with https:// protocols, that would only make since if the
fetch request were ignoring the protocol , as my Request object is being explicitly stated as https://foo-api.domain.com
That would indicate a bug in my opinion - if fetch were indeed making an http request and getting 307'd, and an even bigger bug that the Request object fails to follow the redirect - if I set redirec follow the request fails with "too many redirects" which means it has gotten itself into a loop.
What!? You're saying a setting that I didn't know existed was forcibly removing encryption and security from my stack without me knowing??
Let me find this setting...
And this setting is Flexible by default!?!?
Wow that worked
If I had sent username:password in that request, thinking it was encrypted because it was to https://
Cloudflare would have actually turned that off and sent my request across the internet in the clear.
This is actually a pretty bad thing, yeah?