Redirect loop on default page

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable default page:
<system.webServer>
    <defaultDocument enabled="true">
      <files>
        <add value="AppMenu.aspx" />
      </files>
    </defaultDocument>
...
</system.webServer>
2. Enable securityswitch for entire site:
<securitySwitch mode="On">
    <paths>
      <add path="~/" />
    </paths>
  </securitySwitch>
3. Visit mysite.com/myroot

What is the expected output? What do you see instead?
When I run locally, I get redirected properly to https://mysite.com/myroot.
However, on the webserver I get a redirect loop error. 

I have strict transport security headers turned on, maybe that's related? 

Via fiddler, it looks like my browser makes a request to 
https://mysite.com/myroot and receives a 301 redirect back to the http version. 
I'm attaching one of the requests - it's definitely made over https (I'm 
leaving out the left panel for security). Any idea why that would be happening?

What version of the product are you using? On what operating system?
The latest via nuget (installed yesterday). I believe the server is Windows 
Server 2003, and IIS 7/ .NET 4.5

Please provide any additional information below.
I'm probably missing something really dumb - I'm learning as I go about this 
https stuff.

Original issue reported on code.google.com by karla...@gmail.com on 3 Jul 2014 at 1:22

Attachments:

• [https redirect loop.png](https://storage.googleapis.com/google-code-attachments/securityswitch/issue-53/comment-0/https redirect loop.png)

[GoogleCodeExporter]

Well, I had to remove the strict transport security header for an independent 
reason (turns out it affects the whole domain, and some of our other pages 
don't work in https. Whoops!) and it fixed the problem. So, I'm not sure if the 
issue is actually with this package, although I'm still curious why it was 
redirecting to the non-secure version. But now you know!

Original comment by karla...@gmail.com on 3 Jul 2014 at 2:20

[GoogleCodeExporter]

That is odd. This could fall into the same category as the IIS feature "Require 
SSL". When that is enabled, IIS prevents the request from even reaching this 
module. Were you using the OWASP recommended IIS module for strict transport 
security?

Original comment by vent...@gmail.com on 4 Jul 2014 at 2:06

[GoogleCodeExporter]

Original comment by vent...@gmail.com on 24 Aug 2014 at 10:35

• Changed state: Invalid