我的問題如下: 我有一段代碼充當網關,將請求路由到一臺後端服務器或另一臺服務器。這段代碼實際上是在一個IHttpHandler中實現的,它在404上被觸發;IIS在queryString中修改雙斜槓爲單斜槓
僞代碼如下:
public void ProcessRequest(HttpContext context)
{
try
{
var absoluteUri = context.Request.Url.AbsoluteUri;
//... clean URL to get the part that we need
string RedirectTo = ...;
context.Response.Redirect(RedirectTo, false);
}
catch (Exception ex)
{
...
}
}
我的問題是,在到達這個代碼查詢字符串存在被加密的(和編碼)一些參數。 不幸的是,對值進行加密的方式並沒有太多的控制,並且一些加密的值包含連續的正斜槓。 ex:website/12345?params = o // go4lia0%3d
當IIS獲得請求時,雙斜線最初被編碼(%3d%3d)。
邏輯上,IIS找不到相應的文檔(這是預期的)並調用上述處理程序。問題在於,在這個階段,查詢字符串已被IIS解碼,並且連續的兩個斜槓轉換爲單個斜槓。這導致解密查詢字符串失敗。
有什麼辦法可以告訴IIS:請單獨留下雙斜線?
幾點說明: - 這個功能是生成發送給最終用戶的鏈接,以便自動填充屏幕上的某個字段。我知道這可能是更容易處理,在一個MVC控制器......也許我會落得這樣做,而不是觸發404
- 生成的加密值的代碼可以修改,以便它不產生斜槓(這將是在第一個地方是個好主意,但已經有發出不正確的鏈接的電子郵件,因此它是一種爲時已晚...
感謝
不幸的是,這個值給了我與RawUrl或AbsoluteUri類似的結果... 無論如何非常感謝,我想我會嘗試所有的ServerVariables,儘管我相當確信它是IIS在刪除雙斜線之前URL到達HttpHandler。 – Etienne
其實我認爲我知道什麼是錯的......雙斜槓不在查詢字符串中,所以這就是爲什麼IIS擺脫它,我應該早點注意到這一點。 – Etienne
如果它不在QueryString中,我不確定是否有解決方案。我遇到過類似的問題,所以我使用了上述的UNENCODED_URL服務器變量,它解決了這個問題。但是,發生這種情況的鏈接是通過電子郵件發送的,使用Outlook作爲郵件客戶端的用戶仍然遇到問題,因爲Outlook會清理電子郵件中的URL並剝離雙斜線。實際上它做得太多了。 –