如何檢測ISAPI重寫是否發生

Question

我在開始新工作後繼承了舊系統，以前的開發人員都不再在這裏工作，而且沒有任何一個人記錄了這麼多。娛樂時間。

該系統採用一個古老的，倒閉的CMS和我剛剛完成一個大的考驗，由此我不能爲我的生活弄清楚如何路由工作（客戶希望一個URL變化）。後來事實證明，以前的開發人員一直在使用一個名爲「Helicon ISAPI重寫」的完全獨立的程序，並從那裏開始執行所有網站的URL管理。

我的問題是：我怎麼會更快地想通了這一點（例如是我可以用有外部工具或日誌，我不知道這會透露了這一路由是如何工作的）？

我花了整整一個下午到10年價值的代碼採摘時的回答甚至沒有在那裏！現在我覺得我沒有機會很快搞清楚，但我想知道我是否錯過了一些東西。

Answer 1

我想我明白你在問什麼，首先發現重寫。託尼的回答是正確的，如果你事先知道ISAPI_Rewrite，但後見之明是20-20。我是ISAPI_Rewrite和Helicon Ape的忠實粉絲，所以我可能會懷疑它。但是，如果重寫是通過IIS7的.NET web.config完成的，那麼我不會在那裏查看（儘管我猜web.config應該是一個可以啓動IIS的任何東西的地方）。使用舊版CMS或類似WordPress的東西，我不知道從哪裏開始，所以我可能會像您一樣從代碼開始。

我想真正的出發點是IIS的頂部，前請求甚至已經開始在網頁代碼。

在IIS7環顧四周，我看到的處理程序映射，並在有一大堆的東西，攔截各種請求。這些可能會在請求訪問該網站之前對請求做「事情」。例如，我看到微軟的ExtensionlessUrlHandler ......這給了我們在升級到.NET 4.0時作爲突破性變化的麻煩。我們不得不爲此琢磨，想知道是什麼把eurl.axd放入我們的網站。

IIS6在網站屬性上有一個ISAPI過濾器選項卡。我有ISAPI_Rewrite和ASP.NET_2.0 ....在其中。還有一個帶有MIME類型的HTTP Headers tabl，可能是轉移請求的罪魁禍首。

現在知道了，也許所有重寫軟件的列表都會很方便。只要搜索系統中的任何一個安裝 - 可能是獲得第一個線索的最快方法。實際上，如果你在10年的代碼中度過了一個下午，那還不錯！所以你可能沒有機會很快找出這個問題 - 任何遺留系統都會隱藏祕密。

Answer 2

如果它的ISAPI_Rewrite V3，則可以通過以下行啓用中的ISAPI_Rewrite安裝文件夾中的httpd.conf記錄：

RewriteLogLevel 9 
LogLevel debug 

然後你做一些測試要求，rewrite.log和error.log後文件將出現在ISAPI_Rewrite安裝文件夾中。 error.log顯示一般問題，而rewrite.log顯示如何以及是否應用規則以及生成的URL是什麼。