Spring?MVC內置過濾器功能示例詳解

更新時間：2023年09月15日 09:17:33 作者：福

這篇文章主要為大家介紹了Spring?MVC內置過濾器使用示例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪

SpringMVC內置如下過濾器

Form Data
Forwarded Headers
Shallow ETag
CORS

Form Data

瀏覽器可以通過HTTP GET或HTTP POST提交form data（表單數(shù)據(jù)），但是非瀏覽器客戶端可以通過HTTP PUT、HTTP DELETE、HTTP PATCH提交表單數(shù)據(jù)。但是Servlet規(guī)范約定，通過Servlet API的ServletRequest.getParameter*()系列接口只能獲取到HTTP POST提交的表單數(shù)據(jù)。

所以，通過其他方式提交的表單數(shù)據(jù)就獲取不到。

SpringMVC提供了一個解決該上述問題的方案，就是FormContentFilter過濾器，F(xiàn)ormContentFilter 是SpringMVC的內置過濾器，配置后立即生效，可以把除POST的其他方法提交上來的表單數(shù)據(jù)（content type為application/x-www-form-urlencoded）包裝成servletRequest的參數(shù)、從而通過Servlet API的ServletRequest.getParameter*()方法獲取到。

源碼：

@Override
    protected void doFilterInternal(
            HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
            throws ServletException, IOException {

        MultiValueMap&lt;String, String&gt; params = parseIfNecessary(request);
        if (!CollectionUtils.isEmpty(params)) {
            filterChain.doFilter(new FormContentRequestWrapper(request, params), response);
        }
        else {
            filterChain.doFilter(request, response);
        }
    }

解析context type為"application/x-www-form-urlencoded"的body信息獲取到表單數(shù)據(jù)組成params Map，之后將params包裝到FormContentRequestWrapper中的formParams屬性中:

public FormContentRequestWrapper(HttpServletRequest request, MultiValueMap&lt;String, String&gt; params) {
            super(request);
            this.formParams = params;
        }

        @Override
        @Nullable
        public String getParameter(String name) {
            String queryStringValue = super.getParameter(name);
            String formValue = this.formParams.getFirst(name);
            return (queryStringValue != null ? queryStringValue : formValue);
        }

之后調用HttpServletRequest的getParameter方法會從formParams中獲取數(shù)據(jù)。

Forwarded Headers

RFC 7239 定義了HTTP Forwarded請求頭來反應經過代理之后的原始請求頭信息，比如原始請求主機、端口號等信息。此外，還會有其他的非標準的轉發(fā)頭信息比如：X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto, X-Forwarded-Ssl, X-Forwarded-Prefix等等。

SpringMVC提供了一個內置過濾器ForwardedHeaderFilter，目的是：

改變Forwarded請求頭的host、port等相關信息
移除這些頭信息，以便消除后續(xù)影響（比如處于安全考慮）

如果配置ForwardedHeaderFilter的參數(shù)removeOnly=true的話，所有forwarded相關的參數(shù)都會被移除：

@Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
            FilterChain filterChain) throws ServletException, IOException {

        if (this.removeOnly) {
            ForwardedHeaderRemovingRequest wrappedRequest = new ForwardedHeaderRemovingRequest(request);
            filterChain.doFilter(wrappedRequest, response);
        }

否則，F(xiàn)orwardedHeaderFilter將會從HTTP Forwarded請求頭中重新構建request及response的包裝類，使得包裝類中的請求反應HTTP Forwarded中的原始請求信息。因此，后續(xù)的處理從request中拿到的就會是原始請求的相關信息。

Shallow ETag

ShallowEtagHeaderFilter是SpringMVC用來處理“弱”ETag的過濾器，配置打開該過濾器后，會計算請求內容的MD5到response中，下次瀏覽器再次發(fā)送請求的時候會通過request的頭信息If-None-Match發(fā)送該MD5數(shù)據(jù)，ShallowEtagHeaderFilter會再次計算請求內容的MD5值并與request頭信息的If-None-Match比較，如果相等的話，則返回前臺304狀態(tài)碼。

這個策略會節(jié)約網絡帶寬但是不會節(jié)省CPU計算，因為每次請求上來之后請求內容都需要被計算一次MD5，如果通過MD5判斷后請求內容和上次請求相同的話，只返回304狀態(tài)碼而無需再次返回內容。

測試發(fā)現(xiàn)chrome瀏覽器在后臺發(fā)送Etag回來之后也并不會發(fā)送If-None-Match，會導致該過濾器無效，應該是需要chrome端做一個什么設置，尚未搞定，各位如果需要使用本過濾器的話需要注意。但是換成Edge瀏覽器之后是正常的、可以收到304的。