问题描述及排查过程
一个正常响应里,http状态码为400,但实际已经成功返回了数据,且无论是自己写的业务逻辑代码还是中间件都没有返回400(bad request)这个状态码。
而且gin debug日志中也提示说有操作试图将状态码400覆盖为200,这个操作肯定就是我们的正常业务响应了,那么这个400状态码是哪里来的呢?
答案是gin框架,因为在json unmarshal的时候有一个字段出错了,但是其他字段是可以正常使用的,而后面的业务逻辑中又没有使用这个没成功反序列化的字段,所以响应一直都是正常的。
接收前端请求的代码如下
func PostProj(c *gin.Context) {
dto := PostReq{}
// _ = c.BinJSON(&dto) 原来并没有判断错误,如果有err,还是会正常执行,而且出错的字段没有被业务逻辑使用到,一切就会很正常
if err := c.BindJSON(&dto); err != nil {
logrus.Error(err)
c.JSON(http.StatusOK, HttpRespBody{
Code: http.StatusBadRequest,
Msg: "",
})
return
}
...
}
但是BindJSON这个方法使用了MustBindJSON,要求更严格,
// BindJSON is a shortcut for c.MustBindWith(obj, binding.JSON).
func (c *Context) BindJSON(obj any) error {
return c.MustBindWith(obj, binding.JSON)
}
// MustBindWith binds the passed struct pointer using the specified binding engine.
// It will abort the request with HTTP 400 if any error occurs.
// See the binding package.
func (c *Context) MustBindWith(obj any, b binding.Binding) error {
if err := c.ShouldBindWith(obj, b); err != nil {
c.AbortWithError(http.StatusBadRequest, err).SetType(ErrorTypeBind) // nolint: errcheck
return err
}
return nil
}
可以看到如果序列化过程有任何错误,就会中断请求并且设置状态码为400.
ShouldBind方法就没有这个限制了。
解决方案
一是加好err判断,如果反序列化失败,不管是哪个字段失败了,都立刻返回错误。而且建议状态码为400,更清晰。
如果业务要求全都返回http.StatusOK(200),那么这个BindJSON一定会将状态码改写为400,这时候就要看这个不符合要求的请求体是什么情况了,
如果能接受非法请求体,或者要求全部返回200状态码,就用ShouldBind(不推荐),它不会改写状态码
一般情况下,是要拒绝非法请求体的,还是要前端传一个合法的请求体,所以就继续用BindJSON,然后如果出错返回400 bad request就好了。