Tomcat でサーブレット URL パターンを構成する際の問題の詳細な説明

tomcat の web.xml を構成する場合、サーブレットは比較的重要な問題です。ここでは、サーブレットのいくつかの問題点について説明します。

1. サーブレット URL パターン マッチングの問題
2. URLパターンの/と/*の違い
3. URLパターンの優先度の問題
4. ルートパス/マッチング問題

1 サーブレットurl-patternマッチングの問題

url-patternには、パス一致、完全一致、サフィックス一致の 3 つの一致モードがあります。

1.1 完全一致

<url-pattern>で設定された項目は、URL と完全に一致する必要があります。

コード例: point_down:

<サーブレットマッピング>
 <サーブレット名>MyServlet</サーブレット名>
 <url-pattern>/kata/detail.html</url-pattern>
 <url-pattern>/demo.html</url-pattern>
 <url-pattern>/テーブル</url-pattern>
</サーブレットマッピング>

ブラウザに次のURLを入力すると、サーブレットに一致します。

http://10.43.11.143/myapp/kata/detail.html
http://10.43.11.143/myapp/demo.html

http://10.43.11.143/myapp/table

知らせ：

http://10.43.11.143/myapp/table/は不正な URL であり、 http://10.43.11.143/myapp/tableとして認識されません。

さらに、上記のURLの後に、一致する任意のクエリ条件を続けることができます。

リクエストhttp://10.43.11.143/myapp/table?hello MyServlet に一致します。

1.2 パスマッチング

「/」文字で始まり「/*」で終わる文字列がパスのマッチングに使用されます。

コード例: point_down:

<サーブレットマッピング>
 <サーブレット名>MyServlet</サーブレット名>
 <url-pattern>*.jsp</url-pattern>
 <url-pattern>*.アクション</url-pattern>
</サーブレットマッピング>

パスは /user/ で始まり、パスの残りの部分は何でもかまいません。たとえば、次の URL が一致します。

http://localhost:8080/appDemo/user/users.html

http://localhost:8080/appDemo/user/addUser.action

http://localhost:8080/appDemo/user/updateUser.actionl

1.3 サフィックスマッチング

「*.」で始まる文字列はサフィックスの一致に使用されます。

コード例: point_down:

<サーブレットマッピング>
 <サーブレット名>MyServlet</サーブレット名>
 <url-pattern>*.jsp</url-pattern>
 <url-pattern>*.アクション</url-pattern>
</サーブレットマッピング>

すると、拡張子がjspまたはactionのURLリクエストが一致します。たとえば、次のURLが一致します。

http://localhost:8080/appDemo/user/users.jsp

http://localhost:8080/appDemo/toHome.action

注意: パスとサフィックスのマッチングは同時に設定できません

注意: パスと拡張子のマッチングは、次の3つのように同時に設定することはできません。これらはすべて不正です。設定すると、Tomcat サーバーの起動時にエラーが報告されます。

<url-pattern>/kata/*.jsp</url-pattern>

<url-pattern>/*.jsp</url-pattern>

<url-pattern>he*.jsp</url-pattern>

いくつかの例: point_down:、理解できない場合は、この記事の第3章を読んでください

2 URLパターンにおける/と/*の違い

<url-pattern>/</url-pattern>

<url-pattern>/*</url-pattern>

まずは/*についてお話しましょう。 /*は比較的わかりやすいです。パスマッチングの一種です。スコープの点では最も広いパスマッチングであり、すべてのリクエストがその要件を満たします。精度の点では、最も精度の低いパスマッチングです（注意！パスマッチングについて話しています）。パスマッチングの優先順位は長いものから短いものの順（詳細はこの記事の第3章を参照）なので、最も精度の低いパスマッチングです。多くのブログでは、その機能は*.jspと一致すると書かれています。これはナンセンスではないでしょうか? /*自体はパスマッチャーなので、 *.jspと確実に一致します。

また/ 、 /最も優先度の低い一致です。 URL がすべてのurl-patternに一致しない場合、 URL は/に一致します。 *.jsp制限はまったくありません。 / *.jspに一致しないが、 /*は*.jspに一致すると誰もが考える (客観的に見てそれは正しい) 理由は、 *.jspが tomcat/conf/web.xml で別途設定されているためです。詳細については、この記事の第 3 章を参照してください。

3 URLパターンの優先順位の問題

URL が複数のサーブレットの一致ルールに一致する場合、対応するサーブレットは「正確なパス > 最長パス > サフィックスの一致」の優先順位に従って一致します。

例 1: たとえば、servletA の URL パターンは /test で、servletB の URL パターンは /* です。このとき、アクセスする URL が http://localhost/test の場合、コンテナは最初に正確なパスの一致を実行し、/test が servletA と完全に一致することを検出します。この場合、servletB を気にせずに servletA が呼び出されます。

例 2: たとえば、servletA の URL パターンが /test/で、servletB の URL パターンが /test/a/の場合、http://localhost/test/a にアクセスすると、コンテナーは一致するパスが最も長いサーブレット (ここでは servletB) を選択します。

例 3: たとえば、servletA の URL パターンは *.action で、servletB の URL パターンは/ *です。このとき、アクセスした URL が http://localhost/test.action の場合、コンテナーは拡張子の一致ではなくパスの一致を優先して、servletB を呼び出します。

すると疑問が生じます。 /* *.jspに一致するのに、 / は*.jspに一致しないのはなぜですか?

理由は非常に簡単です。tomcat/conf/web.xmlに次の設定があります。

<サーブレットマッピング>
 <サーブレット名>デフォルト</サーブレット名>
 <url-パターン>/</url-パターン>
</サーブレットマッピング>

<!-- JSP サーブレットのマッピング -->
<サーブレットマッピング>
 <サーブレット名>jsp</サーブレット名>
 <url-pattern>*.jsp</url-pattern>
 <url-pattern>*.jspx</url-pattern>
</サーブレットマッピング>

:point_up_2: *.jspは jsp という名前のサーブレットのサフィックス一致であり、/* はパス一致であり、サフィックス一致よりも優先順位が高いため、サフィックス jsp を持つファイルを一致できることが明確にわかります。ただし、 /サフィックスの一致よりも低い最低レベルの一致であるため、jsp ファイルは / のurl-patternと一致しません。

4 ルートパス/マッチング問題

問題に気付いたかもしれません。つまり、URL パターンが /* の場合、http://localhost:8080/ にアクセスすると 404 が返されますが、http://localhost:8080/index.html にアクセスすると正常に動作します (もちろん、前提として、Spring コンテナーで<mvc:default-servlet-handler/>が構成されている必要があります)。 url-pattern が / の場合、http://localhost:8080/ は 404 なしで http://localhost:8080/index.html に自動的に転送されます。理由は何ですか？

まず、URL のルート ディレクトリ、つまり / (http://localhost:8080/ など) が何を意味するのかを明確にする必要があります。実験を通じて、/ は非常に特殊であることがわかりました。/* の URL パターンには一致しますが、/ の URL パターンには一致しません。

Tomcat では、/ はデフォルトで defaultservlet に一致しますが、その優先順位はパスの一致よりも低くなります。そのため、サーブレットの URL パターンが /* の場合、/ は defaultservlet ではなく、このサーブレットに一致します。

Tomcat ソース コードにある次のスニペットは私の見解を裏付けています: point_down:

<!-- ====================== デフォルトのウェルカム ファイル リスト ======================= -->
<!-- リクエスト URI がディレクトリを参照する場合、デフォルトのサーブレットは -->
<!-- そのディレクトリ内の「ようこそファイル」と、存在する場合は -->
<!-- 表示用の対応するリソース URI。 -->
<!-- ウェルカムファイルが存在しない場合は、デフォルトのサーブレットは -->
<!-- ディレクトリ一覧（方法については、デフォルトのサーブレット設定を参照してください -->
<!-- カスタマイズ) または 404 ステータスを返します (--> の値によって変わります)。
<!-- リスト設定 -->
<!-- -->
<!-- 独自のアプリケーションの web.xml で welcome ファイルを定義する場合 -->
<!-- デプロイメント記述子、そのリストは構成されたリストを*置き換えます* -->
<!-- ここに、必要なデフォルト値を必ず含めてください -->
<!-- アプリケーション内で使用します。

:point_up_2:上記はWelcome File Listに関するもので、デフォルトでは/パスはWelcome File Listで指定された Web ページ、つまり初期ページに転送されます。上記の一部を翻訳します。詳細はGoogle翻訳をご利用ください。翻訳: point_right:

翻訳:point_down:

リクエスト URI がディレクトリを指している場合、デフォルトのサーブレットはそのディレクトリ内の「ウェルカム ファイル」を検索し、存在する場合は対応するリソース URI を検索して表示します。ウェルカム ファイルが存在しない場合は、デフォルトのサーブレットは、リスト設定の値に応じて、ディレクトリ リストを提供するか (カスタマイズ方法については、デフォルトのサーブレット構成を参照)、404 ステータスを返します。

/ が welcome ページにリダイレクトされる理由は、 Welcome File Listが存在するためです。 Welcome File List機能するための前提条件は、 / が defaultservlet と一致している必要があることです。サーブレットの URL パターンが /* の場合、/ は defaultservlet ではなくこのサーブレットによって一致します。したがって、自己定義サーブレットのURLパターンが/の場合にのみ、http://localhost:8080/は404なしでhttp://localhost:8080/index.htmlに自動的に転送されます。

要約する

Tomcat でサーブレット URL パターンを構成する際の問題の詳細な説明については、これで終わりです。Tomcat 構成サーブレットに関する関連コンテンツの詳細については、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後も 123WORDPRESS.COM を応援していただければ幸いです。