先说问题,go gin 框架中使用 c.Header("new-token", "123") 设置 http header 键值的时候,设置的 new-token 键会变成 New-Token !!!

事件始末
最近在做服务器鉴权相关的工作,一个比较简单的逻辑:
服务端收到客户端请求后,校验客户端带过来的校验参数 token 是否过期,当 token 过期时间小于一天时,会生成一个新的 token 并通过设置 http header 的 new-token 来通知客户端去将本地缓存的 token 更新。

功能做好了,示例代码如下:
服务端这里省略了校验 token 时间的逻辑,只给了设置 token 的逻辑:
package main
import (
"github.com/gin-gonic/gin"
)
func main() {
engine := gin.Default()
engine.GET("/header", func(c *gin.Context) {
c.Header("new-token", "123")
c.String(200, "ok")
})
engine.Run(":4780")
}
这时我直接就跟客户端对接小哥说:当客户端缓存的 token 快过期的时候,我会通过设置 http header 的 new-token 值来告诉你已经更新了,你去把客户端自己缓存的 token 换掉就行了。
前端小哥的代码如下:
if (response.headers && response.headers['new-token']) {
store.upadteToken(response.headers['new-token'])
}
因为功能并不复杂,我也就没有测试(前端小哥也没测试),直接提交测试了。再加上 token 的过期时间也设置的比较长,前几天并没有出现过这种需要更新 token 的情况。
但突然有天测试小哥说出问题了需要看看,我看了看代码,直接否认说不是自己的问题,前端小哥也直接矢口否认。
没法子,两人去案发现场一比对,才发现问题,是后端返回的 new-token 不是全小写的,而是 New-Token !!!

定位问题
丢人!!!!
为了找回一点点颜面,查了查源码才发现原来 gin 框架是会对 header 做设置。
最终会走到 go 源码 go\src\net\textproto 的 CanonicalMIMEHeaderKey(s string) string 方法中,如下:
// CanonicalMIMEHeaderKey returns the canonical format of the
// MIME header key s. The canonicalization converts the first
// letter and any letter following a hyphen to upper case;
// the rest are converted to lowercase. For example, the
// canonical key for "accept-encoding" is "Accept-Encoding".
// MIME header keys are assumed to be ASCII only.
// If s contains a space or invalid header field bytes, it is
// returned without modifications.
func CanonicalMIMEHeaderKey(s string) string {
commonHeaderOnce.Do(initCommonHeader)
// Quick check for canonical encoding.
upper := true
for i := 0; i < len(s); i++ {
c := s[i]
if !validHeaderFieldByte(c) {
return s
}
if upper && 'a' <= c && c <= 'z' {
return canonicalMIMEHeaderKey([]byte(s))
}
if !upper && 'A' <= c && c <= 'Z' {
return canonicalMIMEHeaderKey([]byte(s))
}
upper = c == '-'
}
return s
}
可以看到,就是在这里将我们赋给 header 的键 new-token 给改成大写的 New-Token 的。
结案忠告
亲,你也不想让同事都知道你这么菜吧!xxxx
框架的使用的确可以省去我们不少的时间,但是在使用框架的时候,再小的功能也要测试一下,不然可能会造成类似本篇描述的问题。
3万+

被折叠的 条评论
为什么被折叠?



