在ASP.NET中，假如你操縱了URL重寫，經由過程HttpContext.Request獲得到的是重寫後的地址。假如這個地址要返回給客戶端（比如Redirect），我們一般但願是重寫前的友愛地址。
凡是的操縱處景是當我們有某個頁面需要用戶登錄才能拜候時，我們會在代碼中鑒定當前拜候用戶是不是登錄，假如未登錄，則重定向至登錄頁面，並將當前網址經由過程Url參數傳遞給登錄頁面。假如操縱了URL重寫，並經由過程Request.Url.AbsoluteUri獲得當前網址，用戶登錄後打開的就是重寫後的地址，這固然不影響正常操縱，但從用戶體驗及URL同一的角度，我們更但願是重寫前的地址。
之前，我們在開辟中也被這個標題問題困擾，只能盡可能經由過程js重定向至登錄頁面（經由過程location.href獲得當前網址）或在代碼中手動寫返回地址。
此刻，我們找到體會決編制，可以從Request.Headers中找到重寫前的網址。
1）假如重寫組件用的是ISAPI_Rewrite，則拜候被重寫的網址時，Headers中會增加一項數據：Key為X-Rewrite-URL，值為重寫前的網址。
2）假如重寫組件用的是IIS自帶的URL Rewrite模塊，則Headers中增加的信息的Key為X-Original-URL。
如許我們就可以夠輕松獲得重寫前的網址，示例代碼以下：
以下為援引的內容：
if (Request.Headers["X-Rewrite-URL"] != null)
{
Response.Write("http://" + Request.Url.Host + Request.Headers["X-Rewrite-URL"]);
}
else if (Request.Headers["X-Original-URL"] != null)
{
Response.Write("http://" + Request.Url.Host + Request.Headers["X-Original-URL"]);
}
題外話：
ISAPI_Rewrite與IIS的URL Rewrite模塊有個很小的辨別，卻給從ISAPI_Rewrite遷徙至URL Rewrite帶來了很年夜麻煩。比如：對http://www.cnblogs.com/cmt/這個網址，ISAPI_Rewrite是用“/cmt/”進行匹配，而URL Rewrite模塊卻用“cmt/”進行匹配，相差一個斜槓，卻造成遷徙時要點竄在ISAPI_Rewrite中寫的每條正則表達式。並竊冬URL Rewrite還供給了從ISAPI_Rewrite導進法則的功能，卻沒有考慮這類環境。
