我在开始新工作后继承了旧系统，以前的开发人员都不再在这里工作，也没有人记录这么多。娱乐时间。
该系统使用旧的、已失效的 CMS，而我刚刚完成了一场大考验，我一生都无法弄清楚路由是如何工作的（客户想要更改 URL）。后来发现，以前的开发人员一直在使用一个完全独立的程序，称为“Helicon ISAPI rewrite”，并从那里完成了网站的所有 URL 管理。
我的问题是：我怎么能更快地弄清楚这一点（例如，有没有我可以使用的外部工具或我不知道的日志会揭示这个路由是如何工作的）？
我花了整整一个下午的时间来挑选价值 10 年的代码，而答案还没有出现！现在我觉得我没有机会快速解决这个问题，但我想知道我是否遗漏了什么。
我想我明白你在问什么，首先要发现重写。如果您事先了解 ISAPI_Rewrite，Tony 的回答是正确的，但事后看来是 20-20。我是 ISAPI_Rewrite 和 Helicon Ape 的忠实粉丝，所以我可能对此有所怀疑。但是，如果重写是由 IIS7 的 .NET web.config 完成的，我就不会在那里查看（尽管我猜 web.config 应该是任何 IIS-screwy 的起点）。使用旧版 CMS 或 WordPress 之类的东西，我不知道从哪里开始，所以我可能会像你一样从代码开始。
我想真正的起点是 IIS 的顶部，甚至在请求到达 Web 代码之前。
在 IIS7 中环顾四周，我看到 Handler Mappings，里面有一大堆东西，拦截各种请求。这些都可以在请求到达网站之前“做一些事情”。例如，我看到 Microsoft 的 ExtensionlessUrlHandler... 在升级到 .NET 4.0 时，它给我们带来了麻烦，因为它是一个重大变化。我们不得不为此挖掘，想知道是什么将 eurl.axd 放入我们的网址中。
IIS6 在网站属性上有一个 ISAPI 过滤器选项卡。我的里面有 ISAPI_Rewrite 和 ASP.NET_2.0....。还有一个带有 MIME 类型的 HTTP Headers 表，这可能是转移请求的罪魁祸首。
现在知道了这一点，也许所有重写软件的列表会很方便。只需在系统中搜索已安装的任何一个 - 可能是获得第一条线索的最快方法。
实际上，如果您在 10 年的代码中花费了一个下午，那还不错！因此，您可能没有机会快速弄清楚这一点 - 任何遗留系统都会隐藏秘密。
如果是 ISAPI_Rewrite v3，您可以通过输入以下行来启用 ISAPI_Rewrite 安装文件夹中的 httpd.conf 日志记录：
RewriteLogLevel 9
LogLevel debug
然后在您提出一些测试请求后，rewrite.log 和 error.log 文件将出现在 ISAPI_Rewrite 安装文件夹中。error.log 显示一般问题，而 rewrite.log 显示如何应用规则以及是否应用规则以及生成的 URL 是什么。