3

私の問題は次のとおりです。ゲートウェイとして機能し、リクエストをバックエンドサーバーまたは別のサーバーにルーティングするコードがあります。このコードは、実際には IHttpHandler に実装されており、404 でトリガーされます。

疑似コードは次のとおりです。

    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)
        {
            ...
        }
    }

私の問題は、このコードに到達する queryString に、暗号化 (およびエンコード) されたパラメーターがいくつかあることです。残念ながら、値を暗号化する方法をあまり制御できず、暗号化された値の中には連続したスラッシュが含まれているものがあります。例: website/12345?params=o//go4lia0%3d

IIS が要求を受け取ると、二重スラッシュが最初にエンコードされます (%3d%3d)。

論理的には、IIS は対応するドキュメントを見つけられず (これは予想されます)、上記のハンドラーを呼び出します。問題は、この段階でクエリ文字列が IIS によってデコードされ、2 つの連続するスラッシュが 1 つのスラッシュに変換されることです。その結果、クエリ文字列の復号化に失敗します。

IIS に伝える方法はありますか: ダブル スラッシュはそのままにしておいてください。

いくつかの説明: - この機能は、エンドユーザーに送信されるリンクを生成して、画面上のいくつかのフィールドに自動的に入力することです。MVCコントローラーでそれを処理する方が簡単かもしれないことはわかっています... 404をトリガーする代わりに、それを行うことになるかもしれません.

  • 暗号化された値を生成するコードを変更して、スラッシュを生成しないようにすることができます (最初は良い考えでしたが、間違ったリンクが送信された電子メールが既に送信されているため、手遅れです...

ありがとう

4

1 に答える 1

2

この問題は解決しましたか？IIS に二重スラッシュをそのままにしておくように指示できるかどうかはわかりませんが、このサーバー変数にアクセスすることで、変更されていない元の URL を解析して、変更されていないクエリ文字列の値を取得できます。

HttpContext.Current.Request.ServerVariables["UNENCODED_URL"]

試してみましたが、HttpContext.Current.Request.RawUrl で二重スラッシュが消えますが、HttpContext.Current.Request.ServerVariables["UNENCODED_URL"] にはまだ残っています。

于 2012-08-31T14:31:51.300 に答える