Redirect Rules mis-identify SSL-connections as Non-SSL

What is the name of the domain?

example.com

What is the issue you’re encountering

Redirect Rules mis-identify SSL-connections

What are the steps to reproduce the issue?

This issue is hard to reproduce, because it only happens occasionally.
My browser will send a request to https://example.com/path/file.php?someparameter=something&another=parameter (note: on https, and confirmed in dev tools)
and I will receive a response like

cf-ray: 90b4fb4a49d262f2-HAM
date: Sat, 01 Feb 2025 21:19:46 GMT
location: https://example.com/path/file.php
server: cloudflare

I’m fairly sure that it’s coming from a redirect rule which matches traffic (http.host eq "www.example.com") or ((http.host eq "example.com") and (not ssl)) with a dynamic action concat("https://example.com", http.request.uri.path) - if I check “Preserve query string”, the redirect still happens occasionally, but the parameters stay in tact which suggests that this is the cause.

The request that results in a redirect does not get forwarded to the origin, and does not have the cf-cache-status response header. It affects document requests and static files (images, css, js). An additional problem is that the response does not include a cache-control or expires header, which can cause the client to cache the redirect, and then end up in a redirect loop.

I’ve observed this issue on various zones across multiple account that I am a manager on. I’ve had colleagues from different countries observe the same, so it doesn’t appear related to my local access point.

I’ve disabled “Always use HTTPS” and “Automatic HTTPS Rewrites” with no change.

Why would this rule be triggered in the first place if I am already using https?
I’ve had these rules for a long time, and this behavior only started recently – I want to say in the past 3 months with the frequency increasing recently which caused me to finally investigate the reason.

Has the expected behavior for these rules changed recently?

1 Like

Hi, I can replicate that bug on my own zone.

It seems this is the same bug that was supposed to be fixed last week here:

I’ve asked someone to take another look at it, thanks for reporting!

3 Likes

We are still seeing this problem in Singapore. Maybe this description helps someone to understand different symptoms of this bug

We observed

  • random requests without authentication header from our iOS app
  • random requests with the wrong request type (GET instead PUT or PUSH) from our Android app

This request are cause by this redirect

  • App sends a legitimet request
  • App get a 301 redirect from CF
  • App ‘repeats’ the request as GET request (Android) or without credentials header (iOS) (Don’t ask me about the GET request on Android, I didn’t study that yet)

Turning off the corresponding rule in CF solved the problem immediately.

I’ve been told that a fix for this bug should be out sometime today.

1 Like

It appears there is no fix yet.

To mitigate the damage somewhat, a response header transform rule on status > 300 helps.
Setting Cache-control: private, no-cache, no-store and Expires: Wed, 21 Oct 2015 07:28:00 GMT does set these headers, so at least there is no redirect loop unless the client happens to hit the issue multiple times in a row.

1 Like

I’ve been told there was an issue with the fix and to expect it today instead.

This bug might not seem huge, but for mobile apps it’s a big problem. The routes are hardcoded in the app.

When a 301 (Permanent Redirect) is returned, the OS on iOS/Android devices sometimes caches that redirect (potentially indefinitely as it’s a permanent redirect).

Subsequently, the OS serves this request from cache (without hitting the network at all) immediately leading to too many redirects.

To be clear, the phone “never” retries the original network route again within a reasonable time period.

So, we need to update our apps to purge the OS-level cache (something we cannot do server-side).

Compared to a website where you could just append a query string like Example Domain to every invocation. This will bypass the OS level cache and at least hit the network…

Like this you can “repair” your features as soon as CF fixed the bug (or just wait for a cache refresh).

The bug no longer happens for me, so I believe it was fixed yesterday. Can you confirm that?

1 Like