php 这边用 post+json 形式向 golang 的 gin 框架发送数据，之前网页版都是使用正常，最近有个需求是一个功能接入移动端内部办公系统，通过接入 sdk 调用实现网页上的功能。
php 作为业务代理层，会接收客户端传过来的数据，然后通过封装的 curl 库发送给 golang 微服务。但是这次在接收到 sdk 的发过来的数据，组装加工并转发到 gin 时，却一直报错。
重庆分公司
重庆分公司
"Key: 'SubmitReq.TaskID' Error:Field validation for 'TaskID' failed on the 'required' tag
Key: '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.ErrnoParams
rsp.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-stream
if ct == "" {ct = "application/octet-stream"
}
ct, _, err = mime.ParseMediaType(ct)
switch {case ct == "application/x-www-form-urlencoded":
var reader io.Reader = r.Body
maxFormSize := 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 数据，这样就不会出现挂羊头卖狗肉的情形了。
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
