IIS httpErrors ExecuteURLは、500; http：//mysite.com/failed-pageなどの奇妙なクエリ文字列をターゲットURLに追加します

IISエラーページの奇妙な動作に気づきました。私はこの設定を持っています：

<httpErrors errorMode="Custom" existingResponse="Replace">
 <remove statusCode="500" />
  <error statusCode="500" responseMode="ExecuteURL" path="/error-page" />
</httpErrors>

クエリ文字列が長すぎるためにASP.NETエラーが発生した場合、エラーページのURLを実行しようとすると、すぐに2番目のエラーが発生します。IISが次のようにエラーページのURLに元のURLを追加するという事実まで、問題を追跡しました。

Original: http://example.com/someurl?id=some_very_long_query_string_causing_security_exception
Error: /error-page?500;http://example.com/someurl?id=some_very_long_query_string_causing_security_exception

これは大きな問題です。クエリ文字列が長すぎるために元のURLが失敗した場合、それに追加されたものを含むエラーページも、クエリ文字列がさらに長いため失敗します。

これはIISの最も愚かなバグだと思います。そのためのサービスパックのパッチがあったかどうか誰かが知っていますか？今までに何も修正されていない場合の最悪のシナリオ、この動作を無効にする方法、またはIISがエラーページに一方的なものを追加するのを停止するトリックはありますか？カスタムエラーページのメカニズム全体を壊すからです。

パスに末尾のスラッシュを追加すると（たとえば、path = "/ error-page /"）、エラーコードとURLの追加が停止されます。元の失敗したURLが保持されることに注意してください。

• 末尾にスラッシュがない場合、エラーページのコンテンツは次のURLで表示されます：http : //example.com/error-page?500 ; http : //example.com/failingpage
• 末尾にスラッシュがある場合、エラーページのコンテンツは次のURLで表示されます：http : //example.com/failingpage

私はずっと前に同様の問題を抱えていましたが、問題のシステムはそのために静的エラーページを使用しています。

これをdefaultResponseModeでfileに設定すると、単一の静的ページが返されます。

httpErrors要素IIS設定スキーマ

ここにも同様の問題があります