I’ve opened support ticket #1972356 for this, but lately the responses I’ve gotten from support have been unhelpful until I ask for escalation on the forums, so I’m posting here as well. The support representatives always assume it’s something naive on my end; I understand that’s probably the case for most support requests they receive, but they’re unable to recognize when an issue isn’t the result of customer error.
iOS 14 appears to be incompatible with Cloudflare Access. I reported the issue to Apple early in the beta; they’ve fixed most of the issues I’ve reported, but they’ve given no indication that they plan to fix compatibility with Cloudflare Access. Given that the anticipated iOS 14 stable release date is fast approaching, it may be worth looking into this on Cloudflare’s end.
Attempting to load a site behind Cloudflare Access on iOS 14 usually results in a blank page or 0-byte download. For example, the following pages are typically inaccessible on iOS 14:
A factory reset may temporarily work around the issue, but it will always return.
The issue is not related to the backend server. Our servers never even see the requests because the issue occurs as part of the redirect response returned by Cloudflare:
- User visits https://www.namepros.com/admin.php
- User hasn’t yet authenticated with Cloudflare Access, so Cloudflare attempts to return a 302 response with a redirect to https://namepros.cloudflareaccess.com/cdn-cgi/access/login/www.namepros.com?.…
- Safari doesn’t see the correct key for the Location header; it shows an empty string as the header key
Example response headers, as reported by Safari’s network inspector:
Set-Cookie: __cfduid=...; expires=Thu, 08-Oct-20 19:29:33 GMT; path=/; domain=.namepros.com; HttpOnly; SameSite=Lax; Secure Expires: Thu, 01 Jan 1970 00:00:01 GMT Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Date: Tue, 08 Sep 2020 19:29:33 GMT Access-Control-Allow-Credentials: true X-Content-Type-Options: nosniff Vary: Accept-Encoding : https://namepros.cloudflareaccess.com/cdn-cgi/access/login/www.namepros.com?... Alt-Svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400 cf-request-id: 0510caf8fb0000153a9da18200000001 Server: cloudflare expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" Strict-Transport-Security: max-age=31536000; includeSubDomains; preload cf-ray: 5cfb143b2fd3153a-EWR
Note the line between “Very” and “Alt-Svc”: it’s missing a header name.
There is a HAR attached to the support ticket, but I can’t upload it here, as it isn’t a permitted file type.
Update: If I try to manually navigate to the redirect URL, Safari “loads” indefinitely. The request doesn’t appear in the network inspector, so there’s no way for me to figure out what happened. To make matters more interesting, despite nothing appearing in the network tab, Safari shows’s address bar shows that I’ve been redirected from the original URL to https://www.namepros.com/cdn-cgi/access/authorized?.… If I wait long enough, sometimes the redirect chain eventually appears in the network inspector, though it usually gives up without any entry or just loads indefinitely. When it does appear, I see the following redirect chain:
- Attempt to redirect to https://namepros.cloudflareaccess.com/cdn-cgi/access/login/www.namepros.com?.…, although it never succeeds because the header name is empty instead of
Update 2: By manually visiting different URLs along the redirect chain, I can get slightly different behavior, but it always gives up at step 4. Nowhere along the way are the correct cookies set; the only
Set-Cookie header I ever receive is for
__cfduid, even when I get redirected back to https://www.namepros.com/admin.php. I’ve tried disabling any experimental features related to cookies.