表单数据
浏览器只能通过HTTP GET或HTTP POST提交表单数据，但非浏览器客户端也可以
使用 HTTP PUT、PATCH 和 DELETE。Servlet API 要求方法仅支持对 HTTP POST 的表单字段访问。ServletRequest.getParameter*()
该模块提供拦截 HTTP PUT、PATCH 和 DELETE
内容类型为 的请求，从中读取表单数据
请求的正文，并包装 使表单数据
可通过一系列方法获得。spring-webFormContentFilterapplication/x-www-form-urlencodedServletRequestServletRequest.getParameter*()
转发的标头
当请求通过负载均衡器等代理时，主机、端口和 方案可能会改变，这使得创建指向正确链接成为一项挑战 从客户端的角度来看，主机、端口和方案。
RFC 7239 定义了 HTTP 标头
代理可以使用它来提供有关原始请求的信息。Forwarded
非标准接头
还有其他非标准标头，包括 、 、 、 和 。X-Forwarded-HostX-Forwarded-PortX-Forwarded-ProtoX-Forwarded-SslX-Forwarded-Prefix
X-转发主机
虽然不是标准的，但 X-Forwarded-Host： <host> 是一个事实上的标准标头，用于将原始主机与
下游服务器。例如，如果将请求发送到
将请求转发到 的代理，然后可以发送一个标头来通知服务器原始主机是 。example.com/resourcelocalhost:8080/resourceX-Forwarded-Host: example.comexample.com
X-转发端口
虽然不是标准的，但是一个事实上的标准标头，用于
将原始端口通信到下游服务器。例如，如果将请求发送到代理，该代理将请求转发到 ，则可以发送
通知服务器原始端口是 .X-Forwarded-Port: <port>example.com/resourcelocalhost:8080/resourceX-Forwarded-Port: 443443
X-转发-原型
虽然不是标准的，但 X-Forwarded-Proto： （https|http） 是一个事实上的标准标头，用于通信原始协议（例如 https / https）
到下游服务器。例如，如果将请求发送到
将请求转发到 的代理，然后可以发送一个标头来通知服务器原始协议是 。example.com/resourcelocalhost:8080/resourceX-Forwarded-Proto: httpshttps
X-转发-SSL
虽然不是标准的，但它是一个事实上的标准标头，用于传达
原始协议（例如https/https）到下游服务器。例如，如果将请求发送到代理，该代理将请求转发到 ，则 的标头通知服务器
原始协议是 。X-Forwarded-Ssl: (on|off)example.com/resourcelocalhost:8080/resourceX-Forwarded-Ssl: onhttps
X-转发前缀
虽然不是标准的，但 X-Forwarded-Prefix： <prefix> 是一个事实上的标准标头，用于将原始 URL 路径前缀传达给
下游服务器。
的使用可能因部署方案而异，并且需要灵活地
允许替换、删除目标服务器的路径前缀或添加前缀。X-Forwarded-Prefix
方案 1：覆盖路径前缀
https://example.com/api/{path} -> http://localhost:8080/app1/{path}
前缀是捕获组之前路径的开头。对于代理，
前缀是 而对于服务器，前缀是 。在本例中，代理
可以发送以使原始前缀覆盖
服务器前缀 。{path}/api/app1X-Forwarded-Prefix: /api/api/app1
方案 2：删除路径前缀
有时，应用程序可能希望删除前缀。例如，考虑 以下代理到服务器映射：
https://app1.example.com/{path} -> http://localhost:8080/app1/{path}
https://app2.example.com/{path} -> http://localhost:8080/app2/{path}
代理没有前缀，而 applications 和 分别有路径前缀。代理可以发送到
让空前缀覆盖服务器前缀和 .app1app2/app1/app2X-Forwarded-Prefix: /app1/app2
|
此部署方案的一个常见情况是按 生产应用程序服务器，并且最好每个部署多个应用程序 服务器以降低费用。另一个原因是在同一台服务器上运行更多应用程序 为了共享服务器运行所需的资源。 在这些方案中，应用程序需要一个非空上下文根，因为有多个 应用程序在同一服务器上。但是，这不应该在 URL 路径中可见 公共 API，应用程序可以在其中使用不同的子域来提供好处 如：
|
方案 3：插入路径前缀
在其他情况下，可能需要在前缀前面加上一个前缀。例如，考虑 以下代理到服务器映射：
https://example.com/api/app1/{path} -> http://localhost:8080/app1/{path}
在这种情况下，代理的前缀为 ，服务器的前缀为 。代理可以发送以使原始前缀覆盖服务器前缀。/api/app1/app1X-Forwarded-Prefix: /api/app1/api/app1/app1
ForwardedHeaderFilter
ForwardedHeaderFilter是一个 Servlet 过滤器，用于修改请求以便
a） 根据标头更改主机、端口和方案，以及 b） 删除这些
标题以消除进一步的影响。筛选器依赖于包装请求，并且
因此，它必须先于其他过滤器排序，例如
应该处理修改后的请求，而不是原始请求。ForwardedRequestContextFilter
安全注意事项
转发标头存在安全注意事项，因为应用程序无法知道
如果标头是由代理（按预期）或恶意客户端添加的。这就是为什么
应将信任边界的代理配置为删除来自外部的不受信任的标头。您还可以配置 with ，在这种情况下，它会删除但不使用标头。ForwardedForwardedHeaderFilterremoveOnly=true
调度程序类型
为了支持异步请求和错误调度，请调度此
filter 应使用 和 进行映射。
如果使用 Spring Framework（参见 Servlet Config），则所有过滤器都会自动注册所有调度
类型。但是，如果通过或在Spring Boot中通过a注册过滤器，请确保包括和之外。DispatcherType.ASYNCDispatcherType.ERRORAbstractAnnotationConfigDispatcherServletInitializerweb.xmlFilterRegistrationBeanDispatcherType.ASYNCDispatcherType.ERRORDispatcherType.REQUEST
浅 ETag
筛选器通过缓存内容创建“浅层”ETag
写入响应并从中计算 MD5 哈希值。下次客户端发送时，
它执行相同的操作，但还会将计算值与请求标头进行比较，如果两者相等，则返回 304 （NOT_MODIFIED）。ShallowEtagHeaderFilterIf-None-Match
此策略可节省网络带宽，但不会节省 CPU，因为必须为每个请求计算完整响应。
状态更改 HTTP 方法和其他 HTTP 条件请求标头（如 和 ）超出了此筛选器的范围。控制器级别的其他策略
可以避免计算，并对 HTTP 条件请求提供更广泛的支持。
请参阅 HTTP 缓存。If-MatchIf-Unmodified-Since
此筛选器具有一个参数，用于将筛选器配置为写入弱 ETag
类似于以下内容：（如 RFC 7232 第 2.3 节中所定义）。writeWeakETagW/"02a2d595e6ed9a0b24f027f2b63b134d6"
为了支持异步请求，必须映射此筛选器
以便过滤器可以延迟并成功生成一个
ETag 到上次异步调度的末尾。如果使用 Spring Framework（参见 Servlet Config）
所有筛选器都会自动注册到所有派单类型。但是，如果注册
过滤器通过或在Spring Boot中通过一个，确保包括.DispatcherType.ASYNCAbstractAnnotationConfigDispatcherServletInitializerweb.xmlFilterRegistrationBeanDispatcherType.ASYNC
CORS（核心斯酒店）
Spring MVC 通过对 CORS 配置的注释提供细粒度支持
控制器。但是，当与 Spring Security 一起使用时，我们建议依赖必须在 Spring Security 的过滤器链之前订购的内置过滤器。CorsFilter