パスマッチング

サーブレット API は、完全なリクエストパスを requestURI として公開し、さらにそれを contextPath、servletPath、pathInfo に細分します。contextPath、servletPath、pathInfo の値は、サーブレットのマッピング方法によって異なります。これらの入力から、Spring MVC は、マッピングハンドラーに使用するルックアップパスを決定する必要があります。これにより、contextPath および必要に応じて servletMapping プレフィックスを除外する必要があります。

servletPath と pathInfo はデコードされるため、lookupPath を導出するために完全な requestURI と直接比較することは不可能であり、requestURI をデコードする必要があります。ただし、パスに "/" や ";" などのエンコードされた予約文字が含まれている可能性があるため、これには独自の問題が発生します。これにより、デコード後にパスの構造が変更され、セキュリティの問題が発生する可能性があります。さらに、サーブレットコンテナーは servletPath をさまざまな程度に正規化する可能性があるため、requestURI に対して startsWith の比較を実行することはさらに不可能になります。

これが、プレフィックスベースの servletPath マッピング型に付属する servletPath への依存を避けることが最善の理由です。DispatcherServlet が "/" または "/*" のプレフィックスなしでデフォルトのサーブレットとしてマップされ、サーブレットコンテナーが 4.0+ である場合、Spring MVC はサーブレットマッピング型を検出し、servletPath と pathInfo の使用を完全に回避できます。3.1 サーブレットコンテナーでは、同じサーブレットマッピング型を想定し、MVC 構成でパスマッチングを介して UrlPathHelper と alwaysUseFullPath=true を提供することで同等のことが実現できます。

幸い、デフォルトのサーブレットマッピング "/" が適切な選択です。ただし、コントローラーのマッピングと比較できるようにするには、requestURI をデコードする必要があるという課題があります。パス構造を変更する予約文字をデコードする可能性があるため、これも望ましくありません。そのような文字が予期されない場合は、拒否するか（Spring Security HTTP ファイアウォールなど）、urlDecode=false を使用して UrlPathHelper を構成できますが、コントローラーのマッピングはエンコードされたパスと一致する必要があります。さらに、DispatcherServlet が URL スペースを別のサーブレットと共有する必要があり、プレフィックスでマッピングする必要がある場合があります。

上記の課題は、AntPathMatcher との文字列パスマッチングの代わりに、PathPatternParser と解析されたパターンを使用する場合に対処されます。PathPatternParser は、バージョン 5.3 から Spring MVC で使用できるようになっており、バージョン 6.0 からデフォルトで有効になっています。デコードされたルックアップパスまたはエンコードされたコントローラーマッピングのいずれかを必要とする AntPathMatcher とは異なり、解析された PathPattern は、一度に 1 つのパスセグメントである RequestPath と呼ばれるパスの解析された表現に一致します。これにより、パスの構造を変更するリスクなしに、パスセグメント値を個別にデコードおよびサニタイズできます。解析された PathPattern は、サーブレットパスマッピングが使用され、プレフィックスが単純に保たれている、つまりエンコードされた文字がない限り、servletPath プレフィックスマッピングの使用もサポートします。パターン構文の詳細と比較については、パターン比較を参照してください。