缘由

php 这边用 post+json 形式向 golang 的 gin 框架发送数据，之前网页版都是使用正常，最近有个需求是一个功能接入移动端内部办公系统，通过接入 sdk 调用实现网页上的功能。

现象

php 作为业务代理层，会接收客户端传过来的数据，然后通过封装的 curl 库发送给 golang 微服务。但是这次在接收到 sdk 的发过来的数据，组装加工并转发到 gin 时，却一直报错。

 "Key: 'SubmitReq.TaskID' Error:Field validation for 'TaskID' failed on the 'required' tagKey: 'SubmitReq.ResultStatus' Error:Field validation for 'ResultStatus' failed on the 'required' tag"

熟悉 gin 的童鞋就应该知道，这是 shouldBind 报出的，也就是 SubmitReq 这个结构里有两个必传字段，但是在接收时，却没有收到，因此报错。

type SubmitReq struct {TaskID       string                 `form:"taskId" json:"taskId" binding:"required"`ResultStatus int64                  `form:"resultStatus" json:"resultStatus" binding:"required"`
}var submitReq structure.submitReq
if err := c.ShouldBind(&submitReq); err != nil {rsp.Errno = config.ErrnoParamsrsp.Errmsg = err.Error()c.JSON(http.StatusOK, rsp)return
}

解决

首先是完善 gin 入口那的接收 http 请求日志

log.Infof("_com_request_in||%v||from=%v||uri=%v||url=%v||method=%v||contentType=%v||header=%+v||args=%v", traceInfo, c.ClientIP(), c.Request.URL.Path, c.Request.URL, c.Request.Method, c.Request.Header.Get("Content-Type"), c.Request.Header, string(data))

接下来就是模拟发送了，并通过三次发送，定位到了问题。

最开始，模拟实际情况，先到 php 服务上找到当时 sdk 发过来的日志，然后拿到发送的数据，模拟发送，在 gin 服务上发现日志中的 method 为 post，而 contentType 和 args 都为空，这就很有问题。

翻了翻源码，发现 contentType 为空时，会按照下载逻辑处理。实际上，就是不处理参数，接收值为空，也就报上述的错误了。

func parsePostForm(r *Request) (vs url.Values, err error) {if r.Body == nil {err = errors.New("missing form body")return}ct := r.Header.Get("Content-Type")// RFC 7231, section 3.1.1.5 - empty type//   MAY be treated as application/octet-streamif ct == "" {ct = "application/octet-stream"}ct, _, err = mime.ParseMediaType(ct)switch {case ct == "application/x-www-form-urlencoded":var reader io.Reader = r.BodymaxFormSize := int64(1<<63 - 1)if _, ok := r.Body.(*maxBytesReader); !ok {maxFormSize = int64(10 << 20) // 10 MB is a lot of text.reader = io.LimitReader(r.Body, maxFormSize+1)}b, e := io.ReadAll(reader)if e != nil {if err == nil {err = e}break}if int64(len(b)) > maxFormSize {err = errors.New("http: POST too large")return}vs, e = url.ParseQuery(string(b))if err == nil {err = e}case ct == "multipart/form-data":// handled by ParseMultipartForm (which is calling us, or should be)// TODO(bradfitz): there are too many possible// orders to call too many functions here.// Clean this up and write more tests.// request_test.go contains the start of this,// in TestParseMultipartFormOrder and others.}return
}

第二次，找到 php 中 curl 填充 header 的 Content-Type 处的代码，发现有逻辑漏洞

if (!empty($userInfo)) {$headerContentType = !empty($contentType) ? $contentType : $_SERVER['HTTP_CONTENT_TYPE'];$ctx->extHeaders = ["userinfo: " . json_encode($userInfo, JSON_UNESCAPED_UNICODE), "Content-Type: " . $headerContentType];
}

如果上游接口中，传了 $userInfo 但是 $contentType 为空，这时 $_SERVER['HTTP_CONTENT_TYPE'] 若为空，就是最开始时的错误。后来通过打印 php 的日志也发现了这点，Content-Type 确实为空。

于是，补充了下相关逻辑，加上了 application/json; charset=utf-8 ，并发送了模拟请求。不过依然是第一次报的错误。

第三次，仔细看了下 gin 打印的日志，终于发现了端倪，在 method 是 POST，Content-Type 是 application/json; charset=utf-8 情况下，参数 args 为

taskId=1&resultStatus=1

本来应该要传 json 格式的，可传的是 form 形式的（也可以说是 queryString 的）。虽然， gin 支持 json、form 和 queryString 三种格式数据解析，但是在 method 和 header 头类型都确定的情况下，没传 json ，而是其他格式的，难怪会解析报错。

func (jsonBinding) Bind(req *http.Request, obj interface{}) error {if req == nil || req.Body == nil {return fmt.Errorf("invalid request")}return decodeJSON(req.Body, obj)
}

问题，还是出现在 php 封装的 curl 代码那

curl_setopt($ci, CURLOPT_POSTFIELDS, is_string($params) ? $params : http_build_query($params));

原来最后发送数据这里，是不管前面设置啥 Content-Type 的，由于前面传的是数组，这里肯定会以 form 形式传过去的。

解决，也很简单，就是在上游收敛了传的 Content-Type 和 params 数据，这样就不会出现挂羊头卖狗肉的情形了。