これは古い投稿ですが、Tomcat 7.0.67以降、context.xmlファイルに次の属性を追加する必要があります。
<Context mapperContextRootRedirectEnabled="true">...</Context>
7.0.67の変更ログによると：
末尾の/がマッパーからDefaultServletに追加されるコンテキストルートとディレクトリのリダイレクトを提供する機能を移動します。これにより、リダイレクトが行われる前に、このような要求を構成済みのバルブとフィルターで処理できるようになります。この動作は、以前の動作を復元するために使用できるコンテキストのmapperContextRootRedirectEnabled属性とmapperDirectoryRedirectEnabled属性を介して構成できます。
そして、Tomcatコンテキストドキュメントでは：
mapperContextRootRedirectEnabled：有効にすると、Webアプリケーションコンテキストルートのリクエストは、必要に応じて、デフォルトのサーブレットではなくマッパーによってリダイレクトされます（末尾にスラッシュが追加されます）。これはより効率的ですが、コンテキストパスが存在することを確認するという副作用があります。指定しない場合、デフォルト値のfalseが使用されます。
アプリケーションのweb.xmlにはへのマッピングがあるよう"/*"です。サーブレットマッピング"/*"により、TomcatはリクエストをそのままWebアプリケーションに渡します（つまり、リダイレクトしません）。
"/*"正しくリダイレクトするには、マッピングをちょうどに変更する必要があり"/"ます。後者はデフォルトのサーブレットを意味します。
Tomcatは末尾にスラッシュを自動的に追加します。Tomcatに付属のサンプルアプリケーションでテストするだけです。
特別な構成のためにそうでない場合は、クエリ文字列を調べてアプリケーションの必要に応じてリダイレクトするフィルターを作成します。多くの場合、これはとにかく必要です（http-> httpsリダイレクトなどを実行します）
TomcatでURLRewriteを試してみましたか？
これは役立つかもしれません：http ：//code.google.com/p/urlrewritefilter/
それでも問題が解決しない場合は、次をご覧ください。tomcatweb.xmlでのURLの書き換え
パットの優れた答えは、私がこれについてさらにいくつかの詳細を掘り下げるのに役立ちました。これは、Tomcatの一部のバージョン（7.0.67以降のTomcat 7、および8.29〜8.37のTomcat 8）のいくつかの癖に関連しているようです。これは、セッションCookieとURLリダイレクトに関係しています。
結論として、Javaサーバーがパス固有のセッションCookieを作成し、最後にスラッシュが付いている場合（ "/ app_name /"など）、サーバーは自動初期リダイレクト（/ app_name-> / app_name）も実行する必要があるようです。 /）...それ以外の場合、セッションCookieはリクエストとともに送信されず、有効なセッションがあるようにサーバーを参照することはありません。これにより、アプリから認証へのリダイレクトループが発生する可能性があります。
Tomcatには両方の動作を制御する構成がありますが、私が知る限り、これらのバージョンでは基本的に同期がとれておらず、リダイレクトを取得せずに末尾のスラッシュを含むCookieを取得する可能性があります。Tomcatの変更ログにはいくつかの関連する問題/変更があります： https ：//tomcat.apache.org/tomcat-8.0-doc/changelog.html
Patがすでに述べたように、これは、この属性をアプリのContext要素に追加することで解決されます。
<Context mapperContextRootRedirectEnabled="true">