Filters

See equivalent in the Reactive stack

Servlet API에서, 나머지 Filter 처리 chain과 대상 Servlet의 처리 전후에 interception-style logic을 적용하기 위해 jakarta.servlet.Filter를 추가할 수 있습니다.

spring-web module에는 여러 개의 built-in Filter implementation이 있습니다:

• Form Data
• Forwarded Headers
• Shallow ETag
• CORS
• URL Handler

Spring 애플리케이션에서 사용할 수 있는 base class implementation도 있습니다:

• GenericFilterBean — Spring bean으로 설정된 Filter에 대한 base class; Spring ApplicationContext lifecycle과 통합됩니다.
• OncePerRequestFilter — GenericFilterBean의 extension으로서, 요청 시작 시점, 즉 REQUEST dispatch phase 동안 한 번만 호출되도록 지원하며, FORWARD dispatch를 통한 추가 handling은 무시합니다. 이 Filter는 또한 Filter가 ASYNC 및 ERROR dispatch에 관여할지 여부에 대한 제어를 제공합니다.

Servlet filter는 web.xml 또는 Servlet 어노테이션을 통해 설정할 수 있습니다. Spring Boot 애플리케이션에서는 declare Filter’s as beans하여 선언할 수 있으며, Boot는 이를 설정해 줍니다.

Form Data

브라우저는 HTTP GET 또는 HTTP POST를 통해서만 form data를 전송할 수 있지만, non-browser 클라이언트는 HTTP PUT, PATCH, DELETE도 사용할 수 있습니다. Servlet API는 HTTP POST에 대해서만 form field access를 지원하도록 ServletRequest.getParameter*() 메서드를 요구합니다.

spring-web module은 FormContentFilter를 제공하여 content type이 application/x-www-form-urlencoded인 HTTP PUT, PATCH, DELETE 요청을 가로채고, 요청 body에서 form data를 읽은 다음, ServletRequest를 wrapping하여 ServletRequest.getParameter*() 계열 메서드를 통해 form data를 사용할 수 있도록 합니다.

Forwarded Headers

See equivalent in the Reactive stack

요청이 load balancer와 같은 proxy를 거치면서 host, port, scheme이 변경될 수 있으며, 이로 인해 클라이언트 관점에서 올바른 host, port, scheme을 가리키는 링크를 생성하는 것이 어려워질 수 있습니다.

RFC 7239는 proxy가 original request에 대한 정보를 제공하기 위해 사용할 수 있는 Forwarded HTTP header를 정의합니다.

Non-standard Headers

X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto, X-Forwarded-Ssl, X-Forwarded-Prefix, X-Forwarded-For와 같은 다른 non-standard header도 있습니다.

X-Forwarded-Host

표준은 아니지만, X-Forwarded-Host: <host>는 original host를 downstream 서버에 전달하는 데 사용되는 사실상의 표준 header입니다. 예를 들어, example.com/resource 요청이 proxy로 전송되고, proxy가 이 요청을 localhost:8080/resource로 전달하는 경우, 서버에 original host가 example.com이었음을 알리기 위해 X-Forwarded-Host: example.com header를 전송할 수 있습니다.

X-Forwarded-Port

표준은 아니지만, X-Forwarded-Port: <port>는 original port를 downstream 서버에 전달하는 데 사용되는 사실상의 표준 header입니다. 예를 들어, example.com/resource 요청이 proxy로 전송되고, proxy가 이 요청을 localhost:8080/resource로 전달하는 경우, 서버에 original port가 443이었음을 알리기 위해 X-Forwarded-Port: 443 header를 전송할 수 있습니다.

X-Forwarded-Proto

표준은 아니지만, X-Forwarded-Proto: (https|http)는 original protocol(예: https / http)을 downstream 서버에 전달하는 데 사용되는 사실상의 표준 header입니다. 예를 들어, example.com/resource 요청이 proxy로 전송되고, proxy가 이 요청을 localhost:8080/resource로 전달하는 경우, 서버에 original protocol이 https였음을 알리기 위해 X-Forwarded-Proto: https header를 전송할 수 있습니다.

X-Forwarded-Ssl

표준은 아니지만, X-Forwarded-Ssl: (on|off)는 original protocol(예: https / https)을 downstream 서버에 전달하는 데 사용되는 사실상의 표준 header입니다. 예를 들어, example.com/resource 요청이 proxy로 전송되고, proxy가 이 요청을 localhost:8080/resource로 전달하는 경우, 서버에 original protocol이 https였음을 알리기 위해 X-Forwarded-Ssl: on header를 전송할 수 있습니다.

X-Forwarded-Prefix

표준은 아니지만, X-Forwarded-Prefix: <prefix>는 original URL path prefix를 downstream 서버에 전달하는 데 사용되는 사실상의 표준 header입니다.

X-Forwarded-Prefix의 사용은 deployment scenario에 따라 달라질 수 있으며, target 서버의 path prefix를 교체, 제거 또는 앞에 추가할 수 있도록 유연해야 합니다.

Scenario 1: Override path prefix

1https://example.com/api/{path} -> http://localhost:8080/app1/{path}

prefix는 capture group {path} 이전 path의 시작 부분입니다. proxy에 대한 prefix는 /api이고, 서버에 대한 prefix는 /app1입니다. 이 경우, proxy는 X-Forwarded-Prefix: /api를 전송하여 original prefix /api가 서버 prefix /app1을 override하도록 할 수 있습니다.

Scenario 2: Remove path prefix

때때로 애플리케이션은 prefix를 제거하기를 원할 수 있습니다. 예를 들어, 다음과 같은 proxy에서 서버로의 mapping을 고려해 보십시오:

1https://app1.example.com/{path} -> http://localhost:8080/app1/{path}
2https://app2.example.com/{path} -> http://localhost:8080/app2/{path}

proxy에는 prefix가 없지만, 애플리케이션 app1과 app2에는 각각 /app1 및 /app2라는 path prefix가 있습니다. proxy는 X-Forwarded-Prefix:를 전송하여 비어 있는 prefix가 서버 prefix /app1 및 /app2를 override하도록 할 수 있습니다.

A common case for this deployment scenario is where licenses are paid per production application server, and it is preferable to deploy multiple applications per server to reduce fees. Another reason is to run more applications on the same server in order to share the resources required by the server to run. In these scenarios, applications need a non-empty context root because there are multiple applications on the same 서버. However, this should not be visible in URL paths of the public API where applications may use different subdomains that provides benefits such as:

• Added security, for example, same origin policy
• Independent scaling of applications (different domain points to different IP address)

Scenario 3: Insert path prefix

다른 경우에는 prefix를 앞에 추가해야 할 수도 있습니다. 예를 들어, 다음과 같은 proxy에서 서버로의 mapping을 고려해 보십시오:

1https://example.com/api/app1/{path} -> http://localhost:8080/app1/{path}

이 경우, proxy의 prefix는 /api/app1이고 서버의 prefix는 /app1입니다. proxy는 X-Forwarded-Prefix: /api/app1를 전송하여 original prefix /api/app1이 서버 prefix /app1을 override하도록 할 수 있습니다.

X-Forwarded-For

X-Forwarded-For: <address>는 클라이언트의 original InetSocketAddress를 downstream 서버에 전달하는 데 사용되는 사실상의 표준 header입니다. 예를 들어, [fd00:fefe:1::4]에 있는 클라이언트가 192.168.0.1에 있는 proxy로 요청을 전송하는 경우, HTTP 요청에 포함된 "remote address" 정보는 proxy가 아니라 실제 클라이언트의 주소를 반영하게 됩니다.

ForwardedHeaderFilter

ForwardedHeaderFilter는 요청을 수정하기 위한 Servlet filter로서, a) Forwarded header를 기반으로 host, port, scheme을 변경하고, b) 추가적인 영향을 제거하기 위해 해당 header를 제거합니다. 이 filter는 요청을 wrapping하는 것에 의존하므로, 수정된 요청을 사용해야 하고 original 요청을 사용하면 안 되는 RequestContextFilter와 같은 다른 filter보다 앞에 배치되어야 합니다.

Security Considerations

애플리케이션은 header가 의도한 대로 proxy에 의해 추가된 것인지, 악의적인 클라이언트에 의해 추가된 것인지 알 수 없기 때문에 forwarded header에는 보안 관련 고려 사항이 있습니다. 이러한 이유로, 신뢰 경계의 proxy는 외부에서 들어오는 신뢰할 수 없는 Forwarded header를 제거하도록 설정해야 합니다. 또한 ForwardedHeaderFilter를 removeOnly=true로 설정할 수 있으며, 이 경우 header를 사용하지 않고 제거만 합니다.

Dispatcher Types

asynchronous requests와 error dispatch를 지원하기 위해 이 filter는 DispatcherType.ASYNC 및 DispatcherType.ERROR로 mapping되어야 합니다. Spring Framework의 AbstractAnnotationConfigDispatcherServletInitializer (참고: Servlet Config)를 사용하는 경우, 모든 filter는 모든 dispatch type에 대해 자동으로 등록됩니다. 그러나 web.xml을 통해 filter를 등록하거나 Spring Boot에서 FilterRegistrationBean을 통해 등록하는 경우, DispatcherType.REQUEST에 더해 DispatcherType.ASYNC 및 DispatcherType.ERROR를 포함해야 합니다.

Shallow ETag

ShallowEtagHeaderFilter filter는 response에 기록된 content를 caching하고, 그로부터 MD5 hash를 계산하여 “shallow” ETag를 생성합니다. 다음에 클라이언트가 요청을 보낼 때도 동일한 작업을 수행하지만, 계산된 값을 If-None-Match request header와 비교하고, 두 값이 같으면 304 (NOT_MODIFIED)를 반환합니다.

이 전략은 각 요청에 대해 전체 response를 계산해야 하므로 CPU는 절약하지 못하지만, 네트워크 대역폭은 절약합니다. state를 변경하는 HTTP 메서드와 If-Match, If-Unmodified-Since와 같은 다른 HTTP conditional request header는 이 filter의 범위를 벗어납니다. controller level의 다른 전략은 계산을 피하고 HTTP conditional request에 대해 더 광범위한 지원을 제공할 수 있습니다. HTTP Caching을 참조하십시오.

이 filter에는 weak ETag를 다음과 유사하게 기록하도록 filter를 설정하는 writeWeakETag parameter가 있습니다: W/"02a2d595e6ed9a0b24f027f2b63b134d6" (정의: RFC 7232 Section 2.3).

asynchronous requests를 지원하기 위해 이 filter는 DispatcherType.ASYNC로 mapping되어야 하며, 이렇게 해야 filter가 마지막 async dispatch 끝까지 ETag 생성을 지연시키고 성공적으로 생성할 수 있습니다. Spring Framework의 AbstractAnnotationConfigDispatcherServletInitializer(참고: Servlet Config)를 사용하는 경우, 모든 filter는 모든 dispatch type에 대해 자동으로 등록됩니다. 그러나 web.xml을 통해 filter를 등록하거나 Spring Boot에서 FilterRegistrationBean을 통해 등록하는 경우, DispatcherType.ASYNC를 포함해야 합니다.

CORS

See equivalent in the Reactive stack

Spring MVC는 controller에 어노테이션을 사용하여 CORS 설정에 대한 세밀한 지원을 제공합니다. 그러나 Spring Security와 함께 사용하는 경우, Spring Security의 filter chain보다 앞에 위치해야 하는 내장 CorsFilter에 의존할 것을 권장합니다.

자세한 내용은 CORS 및 CORS Filter 섹션을 참조하십시오.

URL Handler

See equivalent in the Reactive stack

이전 Spring Framework version에서는, Spring MVC를 설정하여 들어오는 요청을 controller 메서드에 mapping할 때 URL path의 trailing slash를 무시하도록 할 수 있었습니다. 이는 "GET /home/" 요청이 @GetMapping("/home")으로 어노테이션된 controller 메서드에 의해 처리된다는 것을 의미합니다.

이 option은 6.0에서 deprecated되었고 7.0에서 제거되었지만, 애플리케이션은 여전히 이러한 요청을 안전한 방식으로 처리해야 합니다. 이 목적을 위해 UrlHandlerFilter Servlet filter가 설계되었습니다. 이는 다음과 같이 설정할 수 있습니다:

• trailing slash가 있는 URL을 수신할 때 HTTP redirect status로 응답하여 브라우저를 trailing slash가 없는 URL variant로 보냅니다.
• 요청을 wrapping하여 요청이 trailing slash 없이 전송된 것처럼 동작하게 하고, 요청 처리를 계속합니다.

다음은 blog 애플리케이션을 위해 UrlHandlerFilter를 생성하고 설정하는 방법입니다:

1UrlHandlerFilter urlHandlerFilter = UrlHandlerFilter
2		// will HTTP 308 redirect "/blog/my-blog-post/" -> "/blog/my-blog-post"
3		.trailingSlashHandler("/blog/**").redirect(HttpStatus.PERMANENT_REDIRECT)
4		// will wrap the request to "/admin/user/account/" and make it as "/admin/user/account"
5		.trailingSlashHandler("/admin/**").wrapRequest()
6		.build();Copied!

1val urlHandlerFilter = UrlHandlerFilter
2		// will HTTP 308 redirect "/blog/my-blog-post/" -> "/blog/my-blog-post"
3		.trailingSlashHandler("/blog/**").redirect(HttpStatus.PERMANENT_REDIRECT)
4		// will wrap the request to "/admin/user/account/" and make it as "/admin/user/account"
5		.trailingSlashHandler("/admin/**").wrapRequest()
6		.build()Copied!