Path Matching

Servlet API는 전체 request path를 requestURI로 노출하고, 이를 contextPath, servletPath, pathInfo로 더 세분화하는데, 이 값들은 Servlet이 어떻게 매핑되었는지에 따라 달라집니다. 이러한 입력으로부터 Spring MVC는 handler 매핑에 사용할 lookup path를 결정해야 하며, 여기에는 contextPath와 적용 가능한 경우 servletMapping prefix가 제외되어야 합니다.

servletPath와 pathInfo는 디코딩되며, 그로 인해 lookupPath를 도출하기 위해 전체 requestURI와 직접 비교하는 것이 불가능해지고, 따라서 requestURI를 디코딩할 필요가 생깁니다. 그러나 이는 path에 "/"나 ";"와 같은 예약 문자(reserved character)가 인코딩된 상태로 포함되어 있을 수 있고, 이들이 디코딩된 후에는 path의 구조를 변경시킬 수 있으며, 이는 보안 문제로도 이어질 수 있기 때문에 자체적인 문제를 야기합니다.

추가로, Servlet 컨테이너는 servletPath를 다양한 수준으로 정규화(normalize)할 수 있으며, 이로 인해 requestURI에 대해 startsWith 비교를 수행하는 것이 더욱 불가능해집니다.

이러한 이유로, prefix 기반 servletPath 매핑 타입과 함께 제공되는 servletPath에 의존하는 것은 피하는 것이 가장 좋습니다. DispatcherServlet이 "/"로 기본 Servlet으로 매핑되었거나, 또는 "/*"로 prefix 없이 매핑되고 Servlet 컨테이너가 4.0+인 경우, Spring MVC는 Servlet 매핑 타입을 감지하고 servletPath와 pathInfo의 사용을 완전히 피할 수 있습니다.

3.1 Servlet 컨테이너에서는, 동일한 Servlet 매핑 타입을 가정할 때, MVC 설정에서 Path Matching을 통해 alwaysUseFullPath=true인 UrlPathHelper를 제공함으로써 동일한 효과를 얻을 수 있습니다.

다행히도 기본 Servlet 매핑인 "/"는 좋은 선택입니다. 그러나 컨트롤러 매핑과 비교할 수 있도록 requestURI를 디코딩해야 한다는 문제가 여전히 남아 있습니다.

이는 다시, path 구조를 변경시키는 예약 문자를 디코딩할 가능성 때문에 바람직하지 않습니다. 이러한 문자(character)가 예상되지 않는다면, (Spring Security HTTP 방화벽처럼) 이를 거부할 수 있으며, 또는 UrlPathHelper를 urlDecode=false로 설정할 수 있지만, 이 경우 컨트롤러 매핑은 항상 잘 동작하지 않을 수도 있는 인코딩된 path와 매칭되어야 합니다.

더 나아가, 때때로 DispatcherServlet은 다른 Servlet과 URL 공간을 공유해야 하며 prefix로 매핑되어야 할 수도 있습니다.

위의 문제들은 AntPathMatcher를 사용한 String path 매칭의 대안으로, PathPatternParser와 파싱된 패턴을 사용할 때 해결됩니다. PathPatternParser는 Spring MVC 5.3 버전부터 사용 가능하며, 6.0 버전부터 기본적으로 활성화됩니다.

lookup path가 디코딩되거나 컨트롤러 매핑이 인코딩되어야 하는 AntPathMatcher와 달리, 파싱된 PathPattern은 RequestPath라 불리는 path의 파싱된 표현과, 한 번에 하나의 path 세그먼트씩 매칭합니다. 이는 path의 구조를 변경시킬 위험 없이, 각 path 세그먼트 값을 개별적으로 디코딩하고 정제(sanitize)하는 것을 가능하게 합니다.

파싱된 PathPattern은 또한 Servlet path 매핑이 사용되고 prefix에 인코딩된 문자가 없고 단순하게 유지되는 한, servletPath prefix 매핑의 사용도 지원합니다. 패턴 문법의 세부 사항과 비교는 Pattern Comparison을 참조하십시오.