- 主题:[讨论] 拦截器 与 过滤器 有什么区别呢？？
理论上filter也可以干绘画管理的事情
是框架在拦截器里面帮忙做了一些通用部分的处理，所以用拦截器处理更方便？
印象中spring session好像也是基于filter来做的
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 要看你的上下文是什么, 要说是spring web里面的filter跟interceptor,
: 前者继承自servlet的filter概念, 处理的是请求的编码, 格式, 动静态资源分发这类逻辑, spring boot中带了很多默认的处理方法, 大部分情况直接用Configuration直接配置就好了
: 后者不是servlet本身的概念, 是框架做出来方便你用的, 大部分是要自己实现, 处理的是像用户会话管理, 权限控制这类偏业务的逻辑.
: ...................
--
FROM 180.167.95.*
是的
反正所有请求进出都要过一遍
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 特指servlet filter的话，那货近乎无所不能
: request/response随便改
--
FROM 180.167.95.*
你说的这个是filter的本意
不过现在基本上都是提供修改功能的
像spring gateway那套，除了基本的转法拦截之外，也提供修改功能
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 关键是可以随便改，忘了哪家的mvc就是直接基于filter拦下来自己作分发
: 一般而言，标filter的接口都是倾向于能且仅能选择拦或不拦
: 往来报文本体都是只读不可写（比如nginx标成filter的那两个）
: ...................
--
FROM 180.167.95.*
spring gateway性能差吗
是跟nginx比？
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: API命名偏执症的执念而已:-)
: 顺便吐槽：
: 说明spring gateway实现还是太高阶（难怪性能差）
: ...................
--
FROM 180.167.95.*
我不读写body呢，也慢吗
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 往来报文body都能直接进应用层的，还指望啥性能
: 就是一个httpservice和一个httpclient直接串起来的
: 就算nginx，如果一定要修改req body
: ...................
--
FROM 180.167.95.*
怎么知道不是原来的request的
换成另一个的时候，header里面的东西没全复制过去？
【 在 canper (洗衣粉) 的大作中提到: 】
: 嘿嘿，早期在weblogic下，过滤器里吧request偷偷换成另一个，然后forward到jsp的时候报错了，错误信息大概是说这不是我原来那个request。
: 同样的代码在tomcat下没问题。
--
FROM 180.167.95.*
要读body就很烦
比如要给body算签名这种需求
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 上次遇到这种勾当
: 还是为了满足给request body打日志（又是body)这种奇葩而常见的需求
--
FROM 180.167.95.*
签名放body这种事情
之前和我对接的一家厂商就是这么干的
我直接拒绝了，让他们改成放header里
【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 嗯，稍微像样一点的实现，body都是一个流直接连到epoll()之类底层的
: 然后要抢在正主之前拿正文就得各种buffer倒来倒去
: 如果是只读个数据流还稍微好点
: ...................
--
FROM 180.167.95.*
这种事情，前端做就好了吧
【 在 canper (洗衣粉) 的大作中提到: 】
: 遇到的第一个需求是简体繁体转换
--
FROM 180.167.95.*
我印象中2000年的时候，是用四通利方做国标码和big5的转码的
忘记有没有简繁转换功能了，效率还可以啊，玩台湾游戏必备
【 在 canper (洗衣粉) 的大作中提到: 】
: 先不说那个年代还没有前端的概念，前端转换的效率也差很多
--
FROM 180.167.95.*