- 主题:[讨论] 拦截器 与 过滤器 有什么区别呢？？
特指servlet filter的话，那货近乎无所不能
request/response随便改
【 在 guestking (无) 的大作中提到: 】
: 理论上filter也可以干绘画管理的事情
: 是框架在拦截器里面帮忙做了一些通用部分的处理，所以用拦截器处理更方便？
: 印象中spring session好像也是基于filter来做的
: ...................
--
FROM 218.79.11.*
关键是可以随便改，忘了哪家的mvc就是直接基于filter拦下来自己作分发
一般而言，标filter的接口都是倾向于能且仅能选择拦或不拦
往来报文本体都是只读不可写（比如nginx标成filter的那两个）
servlet这个略随性
【 在 guestking (无) 的大作中提到: 】
: 是的
: 反正所有请求进出都要过一遍
--
FROM 218.79.11.*
API命名偏执症的执念而已:-)
顺便吐槽：
说明spring gateway实现还是太高阶（难怪性能差）
真要是底层抠性能的话一串内存零拷贝，它能做出modify来才怪……
【 在 guestking (无) 的大作中提到: 】
: 你说的这个是filter的本意
: 不过现在基本上都是提供修改功能的
: 像spring gateway那套，除了基本的转法拦截之外，也提供修改功能
: ...................
--
FROM 218.79.11.*
往来报文body都能直接进应用层的，还指望啥性能
就是一个httpservice和一个httpclient直接串起来的
就算nginx，如果一定要修改req body
在报文尺寸超过内存分页尺寸时性能也是暴跌的
【 在 guestking (无) 的大作中提到: 】
: spring gateway性能差吗
: 是跟nginx比？
--
FROM 218.79.11.*
nginx没问题，header的处理开销很小
spring gateway不知道有没有特别优化过这种场景
【 在 guestking (无) 的大作中提到: 】
: 我不读写body呢，也慢吗
--
FROM 218.79.11.*
上次遇到这种勾当
还是为了满足给request body打日志（又是body)这种奇葩而常见的需求
【 在 canper (洗衣粉) 的大作中提到: 】
: 嘿嘿，早期在weblogic下，过滤器里吧request偷偷换成另一个，然后forward到jsp的时候报错了，错误信息大概是说这不是我原来那个request。
: 同样的代码在tomcat下没问题。
--
FROM 218.79.11.*
嗯，稍微像样一点的实现，body都是一个流直接连到epoll()之类底层的
然后要抢在正主之前拿正文就得各种buffer倒来倒去
如果是只读个数据流还稍微好点
碰上什么先按业务字段排序或者说要把签名织入body的就越发坑
（好像新版腾讯支付接口就把后面一条回避掉了）
【 在 guestking (无) 的大作中提到: 】
: 要读body就很烦
: 比如要给body算签名这种需求
--
FROM 218.79.11.*
那个是用GDI钩子作的吧
【 在 guestking (无) 的大作中提到: 】
: 我印象中2000年的时候，是用四通利方做国标码和big5的转码的
: 忘记有没有简繁转换功能了，效率还可以啊，玩台湾游戏必备
--
修改:oldwatch FROM 218.79.11.*
FROM 218.79.11.*
那就应该是webwork/struts2
1是走servlet分发的
【 在 nikezhang (难得糊涂) 的大作中提到: 】
: struts
--
FROM 116.233.186.*
很多是为了做日志/簿记/加解密这种勾当
【 在 nikezhang (难得糊涂) 的大作中提到: 】
: 必须读原生request吗？不能等Spring解析好映射成自己对象之后用切面读吗？
--
FROM 116.233.186.*