github.com/gin-contrib/timeout应前置使用

首先,gin的中间件是有执行顺序的,就是按照添加的顺序进行的。之前没在意,我把timeout中间件放在了最后面,导致业务一直不正常,后面debug源码总算看明白了:

源码入口:

go 复制代码
func(c *gin.Context) {
		finish := make(chan struct{}, 1)
		panicChan := make(chan interface{}, 1)

		w := c.Writer
		buffer := bufPool.Get()
		tw := NewWriter(w, buffer)
		c.Writer = tw
		buffer.Reset()
		.....
}

然后这个NewWriter(w, buffer)的实现如下:

go 复制代码
func NewWriter(w gin.ResponseWriter, buf *bytes.Buffer) *Writer {
	return &Writer{ResponseWriter: w, body: buf, headers: make(http.Header)}
}

他这里所做的就是把原始的writer下层一级,然后new了新的body和headers,也就是进行一层封装

这里也就意味着,假如你原来已经在body和header中写入了一些内容,在后续的代码中你就无法获取到原来的内容改了,获取到的是新的header 和body

当然,gin框架自带的中间件,肯定还是考虑得很细的,所以再最后他有把新旧header和body合并的操作:

go 复制代码
			dst := tw.ResponseWriter.Header()
			for k, vv := range tw.Header() {
				dst[k] = vv
			}

			if _, err := tw.ResponseWriter.Write(buffer.Bytes()); err != nil {
				panic(err)
			}

tw.Header()就是新header,dst就是旧header,用一个for循环新header中的值合并到旧header中,也就是原始的c *gin.Context中。这里一切看起来都那么的合理是吧!

但是,这里有个bug,假设在dst中,已经包含了keyabctw.Header()也有keyabc,那么旧的key就会被覆盖掉。导致原header信息丢失,这就是我项目中遇到的bug!

同理,body也是一样存在丢失的风险。

这里他就没考虑到这个问题,所以,该中间件需要放在有业务逻辑的中间件之前执行,这样才能避免出现这个bug。

相关推荐
Cachel wood27 分钟前
Mysql相关知识2:Mysql隔离级别、MVCC、锁
数据库·python·sql·mysql·中间件·数据分析·django
w23617346014 小时前
解析三大中间件:Nginx、Apache与Tomcat
nginx·中间件·tomcat·apache
和尚用0飘柔015 小时前
【中间件】redis使用
数据库·redis·中间件
佳腾_16 小时前
【消息队列RocketMQ】一、RocketMQ入门核心概念与架构解析
中间件·架构·消息队列·云计算·rocketmq
和尚用0飘柔01 天前
【中间件】nginx将请求负载均衡转发给网关,网关再将请求转发给对应服务
nginx·中间件·负载均衡
MarkHD1 天前
第二十五天 - Web安全防护 - WAF原理与实现 - 练习:请求过滤中间件
安全·web安全·中间件
Delphi菜鸟1 天前
go+mysql+cocos实现游戏搭建
mysql·游戏·golang·gin·cocos2d
西岭千秋雪_1 天前
Nacos配置中心客户端处理服务端配置信息源码解析
java·开发语言·分布式·spring·微服务·中间件
独行soc1 天前
2025年渗透测试面试题总结-拷打题库06(题目+回答)
java·开发语言·前端·中间件·数据挖掘·php·xss
weisian1512 天前
中间件--ClickHouse-12--案例-1-日志分析和监控
clickhouse·中间件·linq