1

単純な UrlRewriteFilter ルールを使用して、HTTP 要求を永続的に (301) リダイレクトし、末尾にスラッシュを付けずに、末尾にスラッシュを付けた同じ URL にリダイレクトします。

場合によっては、プレゼンテーション レイヤーにエンコードされた特殊文字 (ö の場合は %C3%B6 など) を含む URL が必要ですが、UrlRewriteFilter が含まれていない限り、これは正常に機能します。しかし、ルールが適用されると、リダイレクト中にエンコードされた文字が不正な形式になっていることがわかります。

www.mydomain.com/asdf%C3%B6asdf/--> 301 -->www.mydomain.com/asdf%F6asdf/

%F6有効な Unicode シーケンスではありません (urldecode 時に黒いひし形のクエスチョン マークとして終了します)。

アプリケーション全体で UTF-8 を使用します。これは、応答ヘッダーと HTML の<head>セクションで設定されています。不正なエンコーディングは、Windows および Linux マシンで発生します。書き換えルールは次のようになります

<rule enabled="true" match-type="regex" >
    <name>Force trailing slash</name>
    <note>...</note>
    <condition type="request-uri" operator="notequal">...>/condition> <!-- some URLs shall not be redirected -->
    <from>(^[^\?]*)(\?.*)?$</from>
    <to type="permanent-redirect" last="true" >$1/$2</to> <!-- adding trailing slash and query string, if present -->
</rule>

これを解決する方法を教えていただければ幸いです。decode-usingとの属性を試してみましたが、encode役に立ちませんでした。

4

2 に答える 2

1

同様の問題がありました。私がしたことは、デコードを null に設定することでした:

<urlrewrite decode-using="null">
于 2017-01-08T10:04:29.413 に答える
0

以下で説明する問題は、2010 年に提出され、それ以来変更されていないこのバグ レポートに関連しているようです。Javaを使用して「手動で」リクエストを処理することで、おそらくこれを回避する必要があります。ただし、他のアイデアは大歓迎です。

于 2013-01-30T11:40:23.667 に答える