记一次Content-Length引发的血案

      转载地址: https://segmentfault.com/a/1190000011920471


背景

新项目上线, 发现一个奇怪的BUG, 请求接口有很小的概率返回400 Bad Request,拿到日志记录的请求的参数于POSTMAN中测试请求接口, 发现能够正常响应.

排查过程

  • 首先服务器能够正常响应400 Bad Request, 排除接口故障问题.
  • 对比日志过程中发现
{
    "hello":"world"
}

接口能够正常响应业务数据.

{
    "hello":"world",
    "kw":"我是八阿哥"
}

则接口返回400错误,接口的请求方式均为post json,于是开始review代码.发现在发送请求时设置了Content-Length,在含中文字符的情况下接口均返回400,定位到原因.请求的伪代码如下

let param = {
    "hello":"world",
    "kw":"我是八阿哥"
}

let _options = {
    headers: {
        'Content-Type': 'application/json',
        'Content-Length': JSON.stringify(param).length
    },
    url: url,
    method: 'POST',
    json: true,
    time: true,
    timeout: 5 * 1000,
    body: param
}

return new Promise((resolve,reject)=>{
    request(_options,(error, response, body)=>{
        ///XXXX
    ])
})

分析结果

首先, 来说说什么是Content-Length,在http的协议中Content-Length首部告诉浏览器报文中实体主体的大小。这个大小是包含了内容编码的,比如对文件进行了gzip压缩,Content-Length就是压缩后的大小(这点对我们编写服务器非常重要)。除非使用了分块编码,否则Content-Length首部就是带有实体主体的报文必须使用的。使用Content-Length首部是为了能够检测出服务器崩溃而导致的报文截尾,并对共享持久连接的多个报文进行正确分段.

其次,为什么含有中文字符的请求参数返回400,因为Content-Length是计算请求参数的字节数,而非字符数.而JSON.stringify(param).length返回的是字符数.含中文字符的情况下

console.log('八阿哥'.length//3, 即3个字符
console.log(Buffer.byteLength('八阿哥''utf8')); //9, utf-8编码下,一个汉字是3字节存储的

导致接口层拿到的Content-Length小于真实的字节长度, 因而无法正确的解析数据, 从而返回400 Bad Request.因此需要将设置Content-Length的长度改为Buffer.byteLength(JSON.stringify(param),'utf8')


猜你喜欢

转载自blog.csdn.net/stpeace/article/details/80217315