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