3 
   <servlet-mapping>
      <servlet-name>myName</servlet-name>
      <url-pattern>/aName</url-pattern>
   </servlet-mapping>

    <security-constraint>

            <web-resource-collection>

                    ...

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

            </web-resource-collection>

             ...

    </security-constraint>

これは web.xml からの抜粋です (これを使用して jboss/tomcat Web サービスを構成します)。inがurl-patterninweb-resource-collectionに関連しているかどうか疑問に思っています。 url-patternservlet-mapping

4

3 に答える 3

6

特定のurl-patternリクエストの制約を選択するために使用される は、何にも関連していません。ここでのサーブレット仕様の興味深い部分は次のとおりです。

SRV.12.8.3 リクエストの処理

サーブレット コンテナは、リクエストを受信すると、SRV.11.1 で説明されているアルゴリズムを使用し url-patternて、リクエスト URI に最適な で定義された制約 (存在する場合) を選択します。制約が選択されていない場合、コンテナはリクエストを受け入れます。それ以外の場合、コンテナーは、要求の HTTP メソッドが選択されたパターンで制約されているかどうかを判断します。そうでない場合、要求は受け入れられるものとします。http-method それ以外の場合、要求は に適用される制約を満たす必要がありますurl-pattern。リクエストが受け入れられ、関連するサーブレットにディスパッチされるには、次の両方のルールを満たす必要があります。

と：

SRV.11.1 URL パスの使用

クライアント要求を受信すると、Web コンテナーはそれを転送する Web アプリケーションを決定します。選択した Web アプリケーションには、要求 URL の先頭に一致する最長のコンテキスト パスが必要です。URL の一致する部分は、サーブレットにマッピングするときのコンテキスト パスです。

Web コンテナは次に、以下で説明するパス マッピング手順を使用して、リクエストを処理するサーブレットを特定する必要があります。

サーブレットへのマッピングに使用されるパスは、リクエスト オブジェクトからのリクエスト URL からコンテキスト パスとパス パラメータを差し引いたものです。以下の URL パス マッピング ルールが順番に使用されます。最初に成功した一致が使用され、それ以上の一致は試行されません。

  1. コンテナは、リクエストのパスとサーブレットのパスが正確に一致するものを見つけようとします。一致が成功すると、サーブレットが選択されます。
  2. コンテナは再帰的に最長のパス プレフィックスを照合しようとします。これは、パス セパレータとして「/」文字を使用して、一度に 1 ディレクトリずつパス ツリーをステップ ダウンすることによって行われます。最長一致によって、選択されるサーブレットが決まります。
  3. URL パスの最後のセグメントに拡張子 (.jsp など) が含まれている場合、サーブレット コンテナーは、拡張子の要求を処理するサーブレットを照合しようとします。拡張子は、最後の「.」の後の最後のセグメントの一部として定義されます。キャラクター。
  4. 前の 3 つのルールのいずれにもサーブレットが一致しない場合、コンテナーは要求されたリソースに適したコンテンツを提供しようとします。アプリケーションに「デフォルト」のサーブレットが定義されている場合は、それが使用されます。

SRV.11.2 マッピングの仕様

Web アプリケーションのデプロイメント記述子では、次の構文を使用してマッピングを定義します。

  • 「/」文字で始まり「/*」サフィックスで終わる文字列は、パス マッピングに使用されます。
  • 「*.」で始まる文字列。プレフィックスは拡張マッピングとして使用されます。
  • 「/」文字のみを含む文字列は、アプリケーションの「デフォルト」サーブレットを示します。この場合、サーブレット パスはリクエスト URI からコンテキスト パスを引いたものであり、パス情報は null です。
  • 他のすべての文字列は、完全一致のみに使用されます。
于 2010-04-30T20:57:13.790 に答える
5

次の理由により、 security-constraint/web-resource-collection/url-patternがservlet-mapping/url-patternに関連していないことは理にかなっています: web にはいくつかのservlet-mapping要素が存在する可能性があります。この場合、相対 URI を解決するためにどのサーブレット マッピング/URL パターンを使用するかが明確ではありません。（推測です-Tomcatでセキュリティ制約をまだ使用していません）。

于 2010-04-27T16:09:52.233 に答える
1

いいえ、それらは相互に関連していません。特定のサーブレットマッピングをセキュリティ制約にバインドする方法はありません。どちらも特定のURLパターンに適用され、セキュリティ制約は特定のHTTPメソッド（GET、POSTなど）にのみ適用できるため、完全に独立しています。

両方の要素は、サーブレット仕様で定義および説明されています。セキュリティに関するセクションSRV.12.8、およびurl-pattern要素に関する詳細を読むことをお勧めします。

于 2010-04-28T16:38:03.953 に答える