SpringMVC內(nèi)置如下過濾器

• 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提供了一個(gè)解決該上述問題的方案，就是FormContentFilter過濾器，F(xiàn)ormContentFilter 是SpringMVC的內(nèi)置過濾器，配置后立即生效，可以把除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<String, String> 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<String, String> 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);
        }

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

Forwarded Headers

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

SpringMVC提供了一個(gè)內(nèi)置過濾器ForwardedHeaderFilter，目的是：

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

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

@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將會(huì)從HTTP Forwarded請求頭中重新構(gòu)建request及response的包裝類，使得包裝類中的請求反應(yīng)HTTP Forwarded中的原始請求信息。因此，后續(xù)的處理從request中拿到的就會(huì)是原始請求的相關(guān)信息。

Shallow ETag

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

這個(gè)策略會(huì)節(jié)約網(wǎng)絡(luò)帶寬但是不會(huì)節(jié)省CPU計(jì)算，因?yàn)槊看握埱笊蟻碇笳埱髢?nèi)容都需要被計(jì)算一次MD5，如果通過MD5判斷后請求內(nèi)容和上次請求相同的話，只返回304狀態(tài)碼而無需再次返回內(nèi)容。

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

COR

跨域過濾器CorsFilter，如果不使用Spring Security的話，可以通過CorsFilter進(jìn)行跨域處理。

以上就是Spring MVC 八 - 內(nèi)置過濾器的詳細(xì)內(nèi)容，更多關(guān)于Spring MVC內(nèi)置過濾器的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論