I host a small web site at an external host provider. When I open it from my iPhone, I get different results depending on how my iPhone is connected to the internet:
On mobile Safari:
Safari cannot open the page because too many redirects occurred.
On mobile Chrome:
This page isn't working / redirected you too many times.
On mobile Opera:
This site can't be reached / too many HTTP redirects.
As far as I can tell, the only difference that decides the outcome is the internet connection type - WiFi vs. Cellular. I cannot find any other differences.
Since the site works fine through WiFi network, I ruled out a redirect loop on my site (that is the most commonly mentioned cause of "too many redirects" error). I also tried turning off cross-site tracking prevention, but the results remained the same. Am I missing something? What could be the cause of this strange behavior?
In case it is relevant, here are a few things about the web site itself:
I finally stumbled upon a fix, although I still do not know why the error does not manifest itself on desktops and mobile WiFi connections. The issue has to do with hosting my web application on IIS using out-of-process mode, and calling UseHttpsRedirection()
during the setup.
What happens next is described in this answer: IIS, which connects to my out-of-process host (Kestrel) via http, gets redirected, and the browser on my phone somehow detects it. There is also a second redirection (the legitimate one) to the login page, which the phone browser counts as well. Now the phone browser sees two redirections, so it displays an error, because at most one redirection is allowed.
The fix was simply to remove the call to UseHttpsRedirection()
. It was unnecessary in out-of-process hosting scenario: IIS front is configured to require https, so clients get redirected anyway.
Doing application side https forcing behind a reverse proxy is tricky. Generally it is better to let the reverse proxy do the forcing, and set the proxy to communicate on https only to avoid any application side forcing. (If the application has https capabilities of course)
If you must do it from the application, then the proxy must include the necessary headers for the application to evaluate the original connection context. And it may have to know the original hostname and basepath if you rewrite that.
Please review the instructions for asp.net core Forwarded Headers Middleware. https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer
As to why that behaves differently depending on your type of internet connection is a bit of a mystery.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With