IIS錯誤地解碼了包含系統區域外部字符的URL

如果URL包含UTF-8編碼字符（它不受當前系統區域設置支持），IIS似乎錯誤地將請求URL傳送到Web應用程序。所有「不支持」的字符都被問號（'？'）取代。IIS錯誤地解碼了包含系統區域外部字符的URL

示例：系統語言環境設置爲挪威語。以下網址工作正常：

/myapp/Blåbærsyltetøy/

以下URL不起作用：

在這兩個網址，非ASCII字符編碼成UTF-8，然後％的編碼，所以實際的URL看起來像這樣：

/myapp/Bl%C3%A5b%C3%A6rsyltet%C3%B8y/ 
/myapp/%D1%87%D0%B5%D1%80%D0%BD%D0%B8%D1%87%D0%BD%D1%8B%D0%B9-%D0%B4%D0%B6%D0%B5%D0%BC/

該應用程序使用處理請求的方法有兩種：

wfastcgi + Python的
ISAPI + C++

兩者都來自同一個問題的痛苦，都沒有問題，如果URL僅包含由系統語言環境支持的字符。

在ISAPI的情況下，看起來EXTENSION_CONTROL_BLOCK::lpszPathInfo已經提供百分比解碼的URL，其中所有「不支持」的字符已被問號替換。 EXTENSION_CONTROL_BLOCK::lpszPathInfo屬性是一個多字節字符串，並且沒有該結構的寬字符字符串版本。

有沒有辦法獲得原始的百分比編碼的URL或防止IIS解碼URL來解決問題？

來源

2017-10-19 Florian Winter

請參見ISAPI，解決的辦法是從服務器變量'HTTP_URL'獲取URL，而不是'PATH_INFO'。這提供了原始的百分比編碼的URL，然後可以正確解碼。在wfastcgi腳本中，「HTTP_URL」不可用，並且嘗試在Python中訪問它會導致「KeyError」。 –

爲wfastcgi嘗試了此變通辦法：https://support.microsoft.com/zh-cn/help/2277918/fix-a-php-application-that-depends-on-the-request-uri-server-variable - 結果：網址不再包含問號。相反，它們包含百分比編碼的字節，在解釋爲UTF-8時會變成亂碼。 –

更正我以前的評論：此處描述的修補程序和註冊表變量https://support.microsoft.com/en-us/help/2277918/fix-a-php-application-that-depends-on-the-request- uri-server-variable實際上解決了wfastcgi的問題。 –

解決方案ISAPI

從服務器變量HTTP_URL而非PATH_INFO獲得請求的URL。這提供了原始的百分比編碼的URL，然後可以正確解碼（通過百分比解碼爲字節數組並將該字節數組解釋爲UTF-8編碼的字符串）。

此變量包含查詢字符串和URL重寫之前的原始路徑，這可能是不需要的，因此可能需要一些額外的處理。

此外，用於錯誤處理程序的請求，此變量包含以類似於

<DLL_PATH>?<STATUS_CODE>;<ORIGINAL_HTTP_URL>

的格式，其需要被解析的字符串。但它包含所有PATH_INFO包含的信息，除非沒有錯誤的解碼。

注：獲得Path_INFO使用GetServerVariable，而不是從EXTENSION_CONTROL_BLOCK結構並沒有解決的編碼問題。

解決方案wfastcgi

服務器變量所使用的系統區域設置（在Python稱爲'mbcs'）默認編碼。這種行爲可以通過設置註冊表項進行更改：

reg add HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\w3svc\Parameters /v FastCGIUtf8ServerVariables /t REG_MULTI_SZ /d REQUEST_URI\0PATH_INFO

注意，這會影響到同一臺服務器上的所有wfastcgi應用和可能會破壞不希望變量是現有的應用程序UTF-8編碼的（而不可能，因爲任何使用非ASCII URL的理智應用程序都會使用UTF-8編碼...）。

也https://support.microsoft.com/en-us/help/2277918/fix-a-php-application-that-depends-on-the-request-uri-server-variable

來源

2017-10-19 11:03:37

IIS錯誤地解碼了包含系統區域外部字符的URL

回答

相關問題