> Fetch requests in Cloudflare Workers use http by default, even if you explicitly specify https, which can often cause redirect loops.

This is whack as hell but doesn't seem to be the default? This issue was caused by the "Flexible" mode, but the docs say "Automatic" is the default? (Maybe it was the default at the time?)

> Automatic SSL/TLS (default)

https://developers.cloudflare.com/ssl/origin-configuration/s...

▲

motorest 6 days ago | parent | next [-]

> This is whack as hell but doesn't seem to be the default?

I don't think so. If you read about what Flexible SSL means, you are getting exactly what you are asking for.

https://developers.cloudflare.com/ssl/origin-configuration/s...

Here is a direct quote of the recommendation on how this feature was designed to be used:

> Choose this option when you cannot set up an SSL certificate on your origin or your origin does not support SSL/TLS.

Furthermore, Cloudflare's page on encryption modes provides this description of their flexible mode.

> Flexible : Traffic from browsers to Cloudflare can be encrypted via HTTPS, but traffic from Cloudflare to the origin server is not. This mode is common for origins that do not support TLS, though upgrading the origin configuration is recommended whenever possible.

So, people go out of their way to set an encryption mode that was designed to forward requests to origin servers that do not or cannot support HTTPS connections, and then are surprised those outbound connections to their origin servers are not HTTPS.

▲

jrasm91 6 days ago | parent | next [-]

It was the default at the time so we had no idea this behavior would be applied to a fetch request in a worker. That combined with no other indication that it was happening made it a real PITA to debug.

▲

maxbond 6 days ago | parent | prev [-]

I get that it's a compatibility workaround (I did look at the docs before posting) but it's a.) super dangerous and b.) apparently was surprising to the authors of this post. I'm gunnuh keep describing "communicate with your backend in plain text and get caught in infinite redirect loops mode" whack but reasonable people may disagree.

I would like to know how this setting got enabled, however. And I don't think the document should describe it as a "default" if it isn't one.

▲

motorest 6 days ago | parent [-]

> I get that it's a compatibility workaround (...) but it's a.) super dangerous (...)

It's a custom mode where you explicitly configure your own requests to your own origin server to be HTTP instead of HTTPS. Even Cloudflare discourages the use of this mode, and you need to go way out of your way to explicitly enable it.

> (...) apparently was surprising to the authors of this post.

The post is quite old, and perhaps Cloudflare's documentation was stale back then. However, it is practically impossible to set flexible mode being aware of what it means and what it does.

> I would like to know how this setting got enabled, however.

Cloudflare's docs state this is a custom encryption mode that is not set by default and you need to purposely go to the custom encryption mode config panel to pick this option among half a dozen other options.

Perhaps this was not how things were done back then, but as it stands this is hardly surprising or a gotcha. You need to go way out of your way to configure Cloudflare to do what amounts to TLS termination at the edge, and to do so you need to skip a bunch of options that enforce https.

	▲	maxbond 6 days ago \| parent [-]
		It seems like you think I'm operating under a misunderstanding as a result of not having looked at the docs. I looked at them before commenting, and described them accurately if tersely in my original comment. We just disagree. I didn't mean "I would like to know" in some sort of conspiratorial way, I just thought there was a story to be told there.

▲

bo0tzz 6 days ago | parent | prev [-]

It was indeed the default at the time.