IIS dekodiert fälschlicherweise URLs, die Zeichen außerhalb des Systemgebiets enthalten

Question

Es scheint, dass IIS die Anforderungs-URL fälschlicherweise an eine Webanwendung liefert, wenn die URL UTF-8-codierte Zeichen enthält, die vom aktuellen Systemgebietsschema nicht unterstützt werden. Alle "nicht unterstützten" Zeichen werden durch Fragezeichen ('?') Ersetzt.

Beispiel: Das Systemgebietsschema ist auf Norwegisch eingestellt. Die folgende URL funktioniert:

/myapp/Blåbærsyltetøy/ 

Die folgende URL nicht funktioniert:

/myapp/черничный-джем/ 

In beiden URLs werden nicht-ASCII-Zeichen codiert als UTF-8 und dann Prozent-codiert, so dass die tatsächlichen URLs wie folgt aussehen:

/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/ 

Die Anwendung nutzt zwei Wege im Umgang mit Anfragen:

• wfastcgi + Python
• ISAPI + C++

Beide sind unter dem gleichen Problem leiden, und beide haben kein Problem, wenn die URL nur Zeichen enthält, die vom System unterstützt werden locale.

Im Falle von ISAPI sieht es so aus, als ob EXTENSION_CONTROL_BLOCK::lpszPathInfo bereits eine prozent-decodierte URL liefert, wo alle "nicht unterstützten" Zeichen durch Fragezeichen ersetzt wurden. Das EXTENSION_CONTROL_BLOCK::lpszPathInfo Attribut ist eine Multi-Byte-Zeichenfolge, und es gibt keine Breitzeichenkettenversion dieser Struktur.

Gibt es eine Möglichkeit, die ursprüngliche, prozentcodierte URL zu erhalten oder zu verhindern, dass IIS URLs entschlüsselt, um das Problem zu umgehen?

Answer 1

Lösung für ISAPI

Holen Sie sich die Anforderungs-URL vom Server Variable HTTP_URL statt PATH_INFO. Dies liefert die ursprüngliche, prozentcodierte URL, die dann korrekt decodiert werden kann (durch Dekodieren in Prozent zu einem Array von Bytes und Interpretieren dieses Array von Bytes als eine UTF-8-codierte Zeichenfolge).

Diese Variable enthält die Abfragezeichenfolge und den ursprünglichen Pfad vor dem Umschreiben der URL, was unerwünscht sein kann. Daher ist möglicherweise eine zusätzliche Verarbeitung erforderlich.

Auch für Fehlerbehandlungsanforderungen, enthält diese Variable eine Zeichenkette in einem Format ähnlich wie

<DLL_PATH>?<STATUS_CODE>;<ORIGINAL_HTTP_URL> 

, die analysiert werden muss. Aber es enthält alle Informationen, die PATH_INFO enthält, außer ohne falsche Decodierung.

Hinweis: Erster Path_INFOGetServerVariable, anstatt von der EXTENSION_CONTROL_BLOCK Struktur hat nicht die Codierung Problem zu lösen.

Lösung für wfastcgi

Servervariablen codiert werden, um das Systemgebietsschemas unter Verwendung von Standard ('mbcs' in Python genannt). Dieses Verhalten kann durch Festlegen eines Registrierungsschlüssels geändert werden:

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

Beachten Sie, dass dies Auswirkungen auf alle wfastcgi Anwendungen auf dem gleichen Server und kann brechen bestehende Anwendungen, die nicht erwarten, dass Variablen UTF-8-codiert sein (eher unwahrscheinlich , da jede normale Anwendung, die Nicht-ASCII-URLs verwendet, die UTF-8-Codierung verwenden würde ...).

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