Azure で ASP.NET 4 を実行しています。サーバーが URL エンコーディングを完全に無視する Microsoft のこの素晴らしい新機能に出くわしました。
最初は %26 に問題があり、& 記号が許可されていないというエラーが発生していました。%26 は & ではなく、%26 を持つことの全体的なポイントは、URL で安全に渡すことができるため、これは明らかにバグです。
www.example.com/this-is-me-%26-microsoft/
これをWeb構成に追加することでこれを解決できました：
<httpRuntime requestValidationMode="2.0" executionTimeout="20" requestPathInvalidCharacters="" />
<pages validateRequest="false"/>
これで %26 の問題は修正されましたが、エンコードされた %23 は %23 ではなく #
www.example.com/%23this-should-work/
これを恒久的に解決する必要があります。この完全に間違ったリクエストの検証は必要ありません。この狂気について語っているこのリンクを見つけましたが、Web アプリでこの URL_ESCAPE_SEGMENT_ONLY を利用する方法がわかりません。
編集：
2009年からこのリンクを見つけました：この問題はしばらくの間起こっているようですが、Microsoftが気にしないため、注意が払われています...
EDIT2!!!:
これに丸一日取り組み、インターネットで見つかったすべての可能な解決策/回避策を試した後 (本全体を書くのに十分です)、私はこれを非常に具体的なバグであると分離しました。運が良かったのは、テスト ケースの URL のセグメントの先頭にこのように %23 が含まれていたことです。
http://www.example.com/%23eleven/
%23 がセグメントの先頭にある場合、自動的にエスケープ解除されて # として処理され、これを変更する方法はありません。
これを説明するには、次を実行します。
Response.Write(Request.Url.GetComponents(UriComponents.SerializationInfoString, UriFormat.UriEscaped));
流れる URL のあるページで
http://www.example.com/%23elevenand%23noteleven/
応答書き込みは次を出力します。
http://www.example.com/#elevenand%23noteleven/
また、次の場合：
Response.Write(Request.Url.GetComponents(UriComponents.Fragment, UriFormat.Unescaped));
結果は次のようになります。
elevenand#noteleven/
PSこの特定のバグはさておき、これをデバッグする丸一日の間に私が学んだことは、.NETでのURLのエンコードとデコード全体が、すべてのレガシー（.NET 4より前）だけでなく、すべての新しいものの両方で完全な災害であることです. .NET 4 の変更は、火にガスを追加するようなさらに大きな災害です。ボードにはこれを報告するユーザーによる大量の投稿がありますが、Microsoft はすべてを無視し、報告されたバグを解決済みおよび重複としてクローズします。