The "default document" is not being forced to SSL

[GoogleCodeExporter]

What steps will reproduce the problem?

http://myip/Default.aspx
vs
http://myip/

The default document is Default.aspx

What is the expected output? What do you see instead?

When using the /Default.aspx my page is protected as expected, however when 
using the "default document" method, the page is not protected

What version of the product are you using? On what operating system?
Version 4.2, Windows 2008 server

Please include the securitySwitch configuration section from your
web.config file.

Original issue reported on code.google.com by vamich...@gmail.com on 9 Mar 2013 at 12:50

[GoogleCodeExporter]

<securitySwitch bypassSecurityWarning="true" mode="RemoteOnly">
    <paths>
        <add path="~/Default.aspx" />       
        <add path="~/Install" />
    </paths>
</securitySwitch>

Original comment by vamich...@gmail.com on 9 Mar 2013 at 12:50

[GoogleCodeExporter]

Short version: You'll have to add another path to your configuration for the 
site root's (or a sub-directory's) default page to get a proper URL match. Be 
sure to specify a matchType of "Exact" or the entire site will be redirect to 
HTTPS (not what you want). Try this:

<securitySwitch bypassSecurityWarning="true" mode="RemoteOnly">
    <paths>
        <add path="~/" matchType="Exact" />
        <add path="~/Default.aspx" />
        <add path="~/Install" />
    </paths>
</securitySwitch>

Long version: The module actually matches requests on the URL, not the 
page/file being executed. This was done to support just about any scenario you 
can think of with regards to friendly URLs. For example, if you were to use 
routing/friendly URLs for your web pages, this module would have no way of 
knowing you setup a route for a particular page. In addition, routing is 
dynamic and may decide to execute one page vs. another based on some arbitrary 
factor (i.e. time of day, a value in a database, etc.).

My point here is, this module works for standard Web Pages, MS MVC, Web Pages 
with routing/friendly URLs, IIS Rewritten URLs, 3rd party MVC frameworks that 
run over ASP.NET, and more, by matching the URL and not the "executing page".

Lastly, it is highly recommended that you redirect canonical requests to a 
consistent URL for SEO purposes 
(http://www.mattcutts.com/blog/seo-advice-url-canonicalization/). You can use 
IIS Rewrite or implement it yourself. In this case, you can either redirect 
requests for /Default.aspx to / or vice versa. Whichever you choose, you can 
then remove the redirected URL from this module's configuration.

Original comment by vent...@gmail.com on 9 Mar 2013 at 2:18

• Changed state: Invalid

[GoogleCodeExporter]

Well, that sort of works.

<securitySwitch bypassSecurityWarning="true" mode="RemoteOnly" 
offloadedSecurityHeaders="X-Forwarded-Proto=https">
    <paths>
        <add path="~/" matchType="Exact" />
        <add path="~/Default.aspx" matchType="Exact" />
        <add path="~/Install" />
    </paths>
</securitySwitch>

The problem I'm having now is that html elements at the root are protected if 
the user manually requests them protected. 

Additionally I have a directory right below the root that has a WCF service as 
the default document.  If I specify the full path 
http://myip/wcf/myservice.svc, it will get served up in either http or https, 
depending on how it was requested.  It also will *always* serve the page in 
https if I request the page with http://myip/wcf/

Basically I only want SSL working for the install directory and Default.aspx, 
no other pages should be allowed to use SSL.

Thanks again!

Original comment by vamich...@gmail.com on 10 Mar 2013 at 11:03

[GoogleCodeExporter]

I'm not quite following what you mean by, "html elements at the root". Could 
you give an example of what you mean by that?

As for the WCF service, I'm really surprised it is allowing HTTPS and forcing 
it when requested how you mention. There may be a latent bug with the root 
match; I'll dig around. For now, see if you can add another entry (make it the 
first one) to ensure that is not SSL enabled.

...
<paths>
    <add path="~/wcf" security="Insecure" />
    ...
</paths>
...

Original comment by vent...@gmail.com on 11 Mar 2013 at 1:39

[GoogleCodeExporter]

By at the root, I mean files that are at the top level of my web app.  For 
example, I have a file called test.htm that is in the same directory as 
Default.aspx. 

Original comment by vamich...@gmail.com on 11 Mar 2013 at 1:48

[GoogleCodeExporter]

Okay, files in the root. Got it. I'll look around and see if there is something 
weird with matching the root (seems like it).

Original comment by vent...@gmail.com on 11 Mar 2013 at 3:24

• Changed state: Considering

[GoogleCodeExporter]

I've tested this scenario quite a bit now. I cannot reproduce the problem 
except in one specific case. I see you are using Windows Server 2008. Is the 
Application Pool that your site uses set up with a pipeline mode of Classic or 
Integrated?

Classic mode will only allow ASP.NET to process requests that are specifically 
.NET resources. For example, aspx pages, ashx handlers, etc. Images, style 
sheets, and plain old HTML files (i.e. test.htm) will be handled directly by 
IIS. That means this module will never get to evaluate such requests and cannot 
enforce its rules on them. I would guess your site's setup to use an app pool 
with Classic pipeline mode.

Integrated mode will send all requests through ASP.NET. If you want to prevent 
HTTPS on your test.htm file via this module, you'll have to make sure your 
site's app pool uses Integrated pipeline mode.

If you are using Integrated mode and still having these issues, I suspect 
something else at play. I tested your scenario and all worked well on Windows 7 
and Windows 2008 Server.

Original comment by vent...@gmail.com on 24 Mar 2013 at 2:47

[GoogleCodeExporter]

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

• Changed state: WontFix