CODEWITHSUNDEEP
http-redirectiishttpsweb-config
Ferenc Moisi
Ferenc Moisi

Reputation: 1

IIS: ERR_TOO_MANY_REDIRECTS with HTTPS Redirect Rule in Web.Config

I'm hosting a website (as a proxy with ARR) on an IIS server, and I want to redirect all HTTP traffic to HTTPS. However, when I enable the redirect rule in my web.config file, the browser returns ERR_TOO_MANY_REDIRECTS.

I've tried troubleshooting this issue, but I can't seem to resolve it. Here are the details:

This is the rule I am using in my web.config file for the redirect:

<rule name="http to https" enabled="true" stopProcessing="true">
    <match url="(.*)" />
    <conditions>
        <add input="{HTTP_HOST}" pattern="^(www.)?example\.com$" />
        <add input="{HTTPS}" pattern="^OFF$" />
    </conditions>
    <action type="Redirect" url="https://example.com/{R:1}" redirectType="Found" />
</rule>

What I've Tried:

  1. Checked the SSL Certificate: It's valid and working properly.
  2. Disabled the redirect rule: Disabling the rule allows the site to load without redirection, but only for HTTP.
  3. Verified DNS: A record is pointing to the correct IP address. ping and nslookup return the expected IP address.
  4. Cleared browser cache and cookies.

What could be causing the ERR_TOO_MANY_REDIRECTS error with the HTTPS redirect in IIS? How can I fix the configuration to ensure proper redirection without causing a redirect loop?

Any help or suggestions would be greatly appreciated!

Upvotes: 0

Views: 75

Answers (2)

Joel Coehoorn
Joel Coehoorn

Reputation: 416101

I think what is happening is the rule is always matching, even if the traffic is already HTTPS.

This, in turn, causes a redirect, which is a new request to the server. A new request means it process the rule again, which — again — will always match. So it redirects... which is a new request, which processes the rule again, which is another redirect, and so on.

You need to build the rule so it does not match if the traffic is already HTTPS.

But what about the <add input="{HTTPS}" pattern="^OFF$" /> entry in the conditions section?

Honestly, I'm not sure. I checked one of my own servers it looks like this instead:

<add input="{HTTPS}" pattern="off"/>

But I checked another server, and it matched your ^OFF$" pattern. I do know regex patterns generally are case-sensitive by default. If you really wanted to be sure, you could do this 😁:

<add input="{HTTPS}" pattern="[Oo][Ff]{2}"/>

But what I really think is breaking this is the the multiple conditions. The <conditions> element supports a logicalGrouping attribute, and we want to be sure it's set to MatchAll:

<conditions logicalGrouping="MatchAll">
    <add input="{HTTP_HOST}" pattern="^(www.)?example\.com$" />
    <add input="{HTTPS}" pattern="^OFF$" />
</conditions>

The documentation here isn't clear what happens if the attribute is omitted, whether MatchAll or MatchAny is used. If it's MatchAny, that would exactly explain your observed behavior.

The alternative is removing the {HTTP_HOST} input condition from this section, and instead accomplishing that filter as part of the url attribute in the initial match element. That's probably also slightly more efficient, since it removes one pass through the input data, though I doubt it's enough improvement to make a meaningful difference.

Upvotes: 0

Xudong Peng
Xudong Peng

Reputation: 2370

Please check if you used the HTTP Load Balancing in ARR, if these the case, maybe you need set the HTTP_X_FORWARDED_PROTO variable , something like:

<add input="{HTTP_X_FORWARDED_PROTO}" pattern="https" negate="true" />

Upvotes: 0

Related Questions