用于 404 和 Sitefinity 的 IIS 7 URL 重写答案

【问题标题】：IIS 7 URL Rewrite for 404 and Sitefinity用于 404 和 Sitefinity 的 IIS 7 URL 重写
【发布时间】：2015-08-11 20:32:39
【问题描述】：

我们有一个新的 Sitefinity 网站正在取代我们的营销网站。切换发生在上周五，今天我们发现了一个问题：旧站点上的内容（pdfs，jpgs）不再可以访问，并且没有将其纳入内容迁移计划。最重要的是，管理层已将回滚作为选项删除。

所以，我想出的解决方案是使用 IIS 7 的 url 重写模块来指向托管旧站点的新 url，以便可以访问内容。这是我想出的 web.config 中的 xml：

<rewrite>
        <rules>
            <rule name="RedirectFileNotFound" stopProcessing="true">
                <match url=".*" />
                <conditions logicalGrouping="MatchAll">
                    <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                    <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />                    
                    <add input="{URL}" negate="false" pattern="/\.*$" />
                </conditions>
                <action type="Redirect" url="http://www.oldsite.com{REQUEST_URI}" appendQueryString="true" />
            </rule>
        </rules>
    </rewrite>

它会尝试测试 URL 是否解析为文件或文件夹，并确保我们正在请求带有扩展名的内容。如果规则通过，它将重定向到旧站点上的相同位置。理想情况下，这意味着以前链接到旧网站的任何内容都可以单独放置。

问题是，没有任何东西被重定向。

通过修改规则，我已经验证了该模块是可操作的，即我可以将它设置为重写所有内容，并且它可以工作。但这些规则不起作用。

我的理论是，由于 Sitefinity 使用数据库存储，它会以某种方式短路“IsFile”匹配类型。完全猜测，但我现在有点不知所措。

如何使用 urlrewriting 以这种方式重定向 404？

【问题讨论】：

{URL} 的最后一个条件是什么？
匹配具有扩展名的请求。 Sitefinity 使用重写会产生类似 www.site.com/page 的名称，最后一次检查假定所有这些都正常，并且不会尝试重定向它们。但是，对于我要解决的问题来说，这是不必要的。

标签： iis-7 url-rewriting sitefinity

【解决方案1】：

我不确定重写器是如何实现的，但那些规则似乎太笼统了。 Sitefinity 使用路由引擎并注册一系列它处理的路由。根据定义，这些路由是按顺序解释的，因此如果在更具体的规则之前存在更通用的规则，则后者将不起作用。

我怀疑可能发生的情况是 Sitefinity 规则在重写器有机会重定向之前已经处理了请求。我可以建议的是要么实施更具体的重写/重定向规则，要么只使用不同的方法处理整个问题。迁移后无法访问旧文件的原因是什么？您能否提供一个无法返回文件的特定 URL，以便我们可以处理一个场景？

【讨论】：

其实问题恰恰相反。 URLRewriter 在路由器之前执行，因此任何 Sitefinity 生成的内容都不存在，而且从技术上讲，无论如何在物理意义上永远不会存在

【解决方案2】：

这只是在黑暗中拍摄，但您是否在库的 sitefinity 高级设置中启用了“文件系统回退”？也许模块正在拦截请求并且不让它继续到文件系统......

【讨论】：

这适用于内容库，因为现在它的所有数据库存储，但不仅仅是图像和文件 - 任何对页面的请求在技术上仍然不存在。

【解决方案3】：

感谢你们的帮助，但事实证明这是动态服务内容的一般问题。

假设所有请求实际上都由 Default.aspx 页面处理。这不是 Sitefinity 的工作方式，但它是 DotNetNuke 的工作方式，并且很好地说明了问题。

url 重写 isfile 和 isdirectory 标志检查文件的物理存在。在这种情况下，实际上只有 Default.aspx 实际存在。所有其他动态提供的内容都是在请求周期的后期生成的，并且没有任何物理存在。

因此，isfile 标志将始终失败，并且重定向规则将始终执行。

我采用的解决方案是允许 IIS 和 .NET 自己处理 404，这样可以正确尊重生成的内容。并将其路由到自定义错误页面 404redirection.aspx。该页面上有重定向到我的旧站点的代码，该内容可能是托管的。然后，该站点具有额外的 404 处理，该处理路由回 404NotFound.aspx 页面，因此对任一系统中都不存在的文件的请求会进行往返，并且看起来它们从未去过任何地方。这也有一个很好的副作用，即在旧服务器上找不到的页面可以在新服务器上显示我们新的、漂亮的、重新命名的 404。

简单地说，我没有尝试先发制人的内容生成和错误处理，而是采取了更“顺其自然”的方法，然后在更合适的时间转移了流程。

【讨论】：