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
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?
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.
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.
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).