Tomcat 利用 RemoteIpValve 对每个request请求的处理规则
2019-07-16 14:36
2763 查看
版权声明:署名,允许他人基于本文进行创作,且必须基于与原先许可协议相同的许可协议分发本文 (Creative Commons)
tomcat利用RemoteIpValve对请求头内容的处理内容
4、更新request
4.2、将第3步尚未做过匹配检查的IP列表重新写回到request.getHeader(remoteIpHeader)中;
5、判断 request.getHeader(protocolHeader) 与protocolHeaderHttpsValue(值为“https”)是否一致:
5.2、若一致:修改 secure=true,schema=https,port=https请求的默认端口(httpsServerPort的值,默认为443)
5.3、若不一致:修改 secure=false,schema=http,port=http请求的默认端口(httpServerPort的值,默认为80)
6、调用下一个VAULE对象的invoke 方法,对处理过的request\response进行新的处理
——> 会进入项目,经过一系列filter之后,执行controller方法。所以controller中的request是经过tomcat处理的请求;
文章目录
- org.apache.catalina.valves.RemoteIpValve的属性
- 1、 remoteIpHeader
- 2、proxiesHeader
- 3、 internalProxies
- 4、trustedProxies
org.apache.catalina.valves.RemoteIpValve的属性
1、 remoteIpHeader
声明HEADER的key值,对应key的存储value值为从请求客户端开始经过的所有IP地址列表(IP间以英文逗号分隔)。
2、proxiesHeader
声明HEADER的key值,对应key的存储value值为从请求客户端开始经过的内部代理的IP地址列表(IP间以英文逗号分隔)。经过tomcat时,由tomcat根据remoteIpHeader、、对HEADER进行复制。不保证包括所有内部代理的IP列表
3、 internalProxies
声明了内部代理的IP地址匹配正则表达式。request.getHeader(remoteIpHeader)的IP列表中,只有不匹配了该正则式的IP才有可能写入request.getHeader(proxiesHeader)中
4、trustedProxies
声明了可信代理的IP地址匹配正则表达式。request.getHeader(remoteIpHeader)的IP列表中,如果非内部代理、但是可信代理的IP,则有可能写入request.getHeader(proxiesHeader)中(不匹配internalProxies,匹配trustedProxies)
tomcat利用RemoteIpValve对请求头内容的处理内容
可见org.apache.catalina.valves.RemoteIpValve#invoke
- 1、获取request中的所需信息,调用 request.getRemoteAddr() 获取 request.getHeader(remoteIpHeader) 的值;
作为初始值,最后需要还原回 request 中;在回传给前端用户前,恢复对request的修改。
- 2、对 remoteAddr 按“,” 切割字符串,得到 IP地址数值;
- 3、对 IP地址数值进行遍历,总最后一个IP开始(String中位于最右的IP),对每个IP 依次(internalProxies、trustedProxies)进行正则表达式匹配: 3.1、不匹配 internalProxies 的直接跳过,对数组中下一个IP进行匹配。否则进行3.2;
- 3.2、匹配 trustedProxies 的暂存在 proxiesHeaderValue 数组中。否则进行3.3;
- 3.3、对于既不是内部代理、又不是可信代理的IP地址,则作为新request.getRemoteAddr()的值。结束循环,不再进行匹配操作。
-
4.1、将第三步中得到的代理IP地址数组写入到request.getHeader(proxiesHeader)中(若数组长度为0,则为null)
—— 由此可见,经历过上述处理的request请求,request.getHeader(proxiesHeader)中代理的IP地址并不包括经过的所有代理IP地址,且有可能一个代理IP地址都没有写入。
-
5.1、若 request.getHeader(protocolHeader) == null:不做任何操作
——> 会进入项目,经过一系列filter之后,执行controller方法。所以controller中的request是经过tomcat处理的请求;
下一个VAULE对象在测试时是:org.apache.catalina.core.StandardEngineValve的实例
扩展
请求的流转路径
web应用的容器控制(利用 org.apache.catalina.Container的扩展与实现),从左到右按照从最外层容器类型到最内层容器类型的顺序:Engine, HOST, CONTEXT,WRAPPER
- 7、恢复request的HEADER 为传入本方法时的初始状态(执行第一步前的状态,将修改过的值赋值为原值),返回请求给用户。
相关文章推荐
- Tomcat请求处理(四) -- Request, Response, 和Pipeline
- tomcat 中配置 access log 监控每个 http request 的处理时间
- Tomcat请求处理(四) -- Request, Response, 和Pipeline
- 请求与响应原理图及Tomcat对request的处理过程
- 编写RequestUtils,利用BeanUtils封装请求参数的处理(赋值与自动类型转换)过程...
- ASIHTTPRequest使用第三方库处理网络请求
- tomcat请求处理分析(一) 启动container实例
- AJAX中同时发送多个请求XMLHttpRequest对象处理方法
- Nginx--官网中文翻译(中英文对比)--9-nginx怎样处理一个请求How nginx processes a request
- dhl:httpHandler.ProcessRequest(HttpContext.Current);传入的请求不与任何路由匹配-解决方案 默认规则被修改
- 一套Tomcat处理多个域名请求 - Virtual Host
- Tomcat源码解读系列(三)——Tomcat对HTTP请求处理的整体流程
- Tomcat请求处理
- Tomcat处理一个HTTP请求的过程
- java利用线程池实现处理socket请求的小例子
- 使用HttpWebRequest进行请求时发生错误:基础连接已关闭,发送时发生错误处理
- tomcat请求处理流程
- Tomcat请求处理(五) -- 请求在容器间的流动
- Tomcat主配置-请求处理
- tomcat源代码系列--请求处理过程