URL Rewrite causes "This page can’t be displayed"
Asked Answered
F

1

1

I have implemented URL Rewriting at the server level as I wanted to redirect all HTTP and HTTPS requests that matches a certain rule to my actual site, and redirection should only take place if the users are hitting my actual site. The rules works fine initially. However, triggering CTRL+R repeatedly on my actual site seems to render my site unaccessible. The error "This page can't be displayed" is then returned to the user. This test was done on IE 11 browser on Windows x64, and my web server is IIS 8.5 on Windows Server 2012 R2. The HTTP response code returned for redirect is configured as 307.

When I turn on Failed Request Routing on my IIS server, I see a warning message on REWRITE_DISABLED_KERNEL_CACHE in the Failed Request Logs. This was the time when the page returns "This page can't be displayed".

Disabling my URL Rewrite rule would immediately render both my HTTP and HTTPS sites accessible once again, and I've verified that redirect no longer works. Enabling the same rule thereafter but on my HTTPS site only would work.

As follows is my redirection rule

<system.webServer>
    ...
    <rewrite>
        <globalRules>
            <clear />
            <rule name="HTTPS to HTTP" enabled="true" stopProcessing="true">
                <match url="^(downloads?/?)?$" />
                <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                    <add input="{REQUEST_URI}" pattern="http://.*?/downloads/" negate="true" />
                </conditions>
                <action type="Redirect" url="http://{HTTP_HOST}/downloads/" appendQueryString="false" redirectType="Temporary" />
            </rule>
        </globalRules>
        <outboundRules>
        </outboundRules>
    </rewrite>
    ...
</system.webServer>

Basically, if the request hits any of the following example URLs, I will redirect them:

1) http://fqdn/download

2) http://fqdn/download/

3) https://fqdn/downloads

4) https://fqdn/downloads/

5) https://fqdn/download

6) https://fqdn/download/

I will not redirect, if the request hits my site directly:

When I hit my actual site, I realise that the redirection rule is still being applied. So I suspect there could be 2 different issues over here.

1) An infinite redirection rule being applied when requests are sent to http://fqdn/downloads/

2) Some unknown problem with REWRITE_DISABLED_KERNEL_CACHE

Fenton answered 16/9, 2016 at 3:16 Comment(0)
I
0

You're in trouble with infinite redirects because of your wrong assumptation about REQUEST_URI and the lack of HTTPS check.

{REQUEST_URI} contains URL's path, including the query string with a leading slash (never been welldocumented), never contains uri scheme or hostname. So, you have a false positive.

http(s)://<host>:<port>/<path>?<querystring>

Here's a self-explanatory rule.

<rule name="Force Http downloads page" stopProcessing="true">

    <!-- If the url starts with download or downloads with an optional trailing slash -->
    <match url="^downloads?/?$" />

    <!-- Redirect -->
    <action type="Redirect" url="http://{HTTP_HOST}/downloads/" appendQueryString="false" redirectType="Temporary" />

    <!-- When -->
    <conditions logicalGrouping="MatchAny">
        <!-- REQUEST_URI does not start with "/downloads/" -->
        <add input="{REQUEST_URI}" pattern="^/downloads/" negate="true" />

        <!-- Or -->

        <!-- HTTPS is not off -->
        <add input="{HTTPS}" pattern="^off$" negate="true" />
    </conditions>
</rule>

Hope it helps.

Irv answered 16/9, 2016 at 4:45 Comment(4)
Wao you're a life saver! But I did a bit of change. Instead of using REQUEST_URI, I have switched to using URL so at least I'm using a variable that's a bit more well documented.Fenton
@louisxie since there's no query string job, it's a good call.Irv
For some reason, the new rule doesn't successfully redirect https://<host>/<path> and https://<host>/ to my intended site. This is because IIS evaluates the {URL} condition applied as true, but the {HTTPS} condition as false. So I removed all conditions applied, and replaced it <add input="{CACHE_URL}" pattern="^http://(?:.+?)/downloads/$" negate="true" />Fenton
Could your solution help my problem here? His rules are a bit different than mine, but I'm getting a 404 for what could be a similar reason. Unfortunately, however, your (very good) reply leaves me in the dust. Could you break it down a bit for me? Thanks :-)Kaiserdom

© 2022 - 2024 — McMap. All rights reserved.