Filters

Browsers can only submit form data using the HTTP GET method or the HTTP POST method, but non-browser clients can also use the HTTP PUT, PATCH, and DELETE methods. The Servlet API requires the ServletRequest.getParameter*() methods to support access to form fields only for the HTTP POST method.

The spring-web module provides a FormContentFilter to intercept PUT, PATCH, and DELETE HTTP method requests with content type application/x-www-form-urlencoded, reading form data from the request body, and wrapping ServletRequest to make that form data available through the ServletRequest.getParameter*() family of methods.

Transmitted headers

As the request passes through proxies (such as a load balancer), the host, port, and scheme may change, making it difficult to create links that point to the correct host, port, and scheme from the client's perspective.

The RFC 7239 specification defines the Forwarded HTTP header that the proxy -servers can be used to provide information about the original request. There are other non-standard headers, including X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto, X -Forwarded-Ssl and X-Forwarded-Prefix.

ForwardedHeaderFilter is a servlet filter that modifies the request to a) change the host, port, and scheme based on the Forwarded headers, and b) remove those headers to exclude their further influence. The filter operates based on request wrapping and therefore needs to be ordered before other filters, such as RequestContextFilter, which must work on the modified request rather than the original request.

There are precautions for the headers that are passed in because the application has no way of knowing whether the headers were added by the proxy as intended or by a malicious client. This is why the proxy at the trust boundary must be configured to remove untrusted Forwarded headers coming from outside. You can also configure ForwardedHeaderFilter with removeOnly=true, in which case it will remove but not use headers.

To provide support for asynchronous requests and error dispatching, this filter must be mapped to DispatcherType.ASYNC as well as DispatcherType.ERROR. When using AbstractAnnotationConfigDispatcherServletInitializer from the Spring Framework, all filters are automatically registered for any dispatch types. However, when registering a filter via web.xml or in Spring Boot via FilterRegistrationBean, be sure to enable DispatcherType.ASYNC and DispatcherType.ERROR in addition to DispatcherType.REQUEST.

Surface ETag

The ShallowEtagHeaderFilter creates a "shallow" ETag by caching the content written in the response and computing an MD5 hash from it. The next time the client sends it, the filter does the same thing, but compares the calculated value to the If-None-Match request header and, if they are equal, returns 304 (NOT_MODIFIED).

This strategy saves network bandwidth, but not processor resources, since the complete answer must be calculated for each request. Other controller-level strategies described earlier avoid computation.

This filter has a writeWeakETag parameter that configures the filter to write weak ETags similar to the following: W/"02a2d595e6ed9a0b24f027f2b63b134d6" (as defined in RFC 7232 Section 2.3).

To support asynchronous requests, this filter must be mapped to DispatcherType.ASYNC so that the filter can defer processing and successfully generate the ETag until the end of the last asynchronous dispatch. When usingAbstractAnnotationConfigDispatcherServletInitializerfrom the Spring Framework, all filters are automatically registered for all dispatch types. However, if you register a filter via web.xml or in Spring Boot via FilterRegistrationBean, be sure to include DispatcherType.ASYNC.

CORS

Spring MVC provides fine-grained CORS configuration support through annotations for controllers. However, when used with Spring Security, we recommend relying on the built-in CorsFilter, which should be placed at the front of the Spring Security filter chain.

See the sections on CORS and the CORS filter for more information.