http响应头首部Content-Length

http响应头首部Content-Length

本文讲述4个问题

  1. gzip编码与Content-Length的关系
  2. 分块编码与Content-Length的关系
  3. file文件已经在服务端进行gzip压缩,那为何在node中用request请求这张图片时(请求的方法为head/get)返回头首部Content-Length还是未压缩前的图片大小?
  4. 响应头一定会包含Content-Length首部吗?

在图片性能监控脚本中对站内某页面的所有图片进行请求(采用request模块),以获取图片的具体大小。(通过response.headers的Content-Length)

// 部分代码

request.head('http://file.showjoy.com/images/46/4695c19423cd40469fb89836373c1d45.jpg', function (error, response, body) {
  console.log(response.headers['content-cength'])
  
  // 'content-length': '812401'
})

对超过阈值的图片会邮件进行提醒:

d

但是在页面中用chrome查看这张图片时,却发现size只有227kb。

由于file开头的资源是文件服务器上的资源,将file改成cdn1再做尝试。可见图片尺寸大小还是812kb。

cdn1上的资源是由文件服务器上的资源同步上去的,这也意味着相同的资源size不同。造成这样的问题很有可能是服务器对资源做了压缩处理。

cdn http响应头

Accept-Ranges:bytes
Access-Control-Allow-Origin:*
Access-Control-Expose-Headers:X-Log, X-Reqid
Access-Control-Max-Age:2592000
Cache-Control:public, max-age=86400
Connection:keep-alive
Content-Disposition:inline; filename="4695c19423cd40469fb89836373c1d45.jpg"
Content-Length:812401
Content-Transfer-Encoding:binary
Content-Type:image/jpeg
Date:Thu, 04 Aug 2016 10:24:19 GMT
ETag:"FqxG8os4S6llXHllO2ublrIKagfY"
Last-Modified:Mon, 11 Apr 2016 09:05:23 GMT
Server:nginx
X-Log:mc.g;IO:1
X-Qiniu-Zone:0
X-Reqid:6VUAAKhrk3UAkmcU
X-Via:1.1 zhenjiang173:4 (Cdn Cache Server V2.0), 1.1 yzh229:1 (Cdn Cache Server V2.0)
file文件服务器 http响应头

HTTP/1.1 200 OK
Server: Tengine
Date: Thu, 04 Aug 2016 10:23:45 GMT
Content-Type: image/jpeg
Last-Modified: Mon, 11 Apr 2016 09:01:56 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Content-Encoding: gzip

可以看出文件服务器开启了Content-Encoding: gzip

内容编码gzip介绍

Accept-Encoding和Content-Encoding是HTTP中用来对「采用何种编码格式传输正文」进行协定的一对头部字段。

工作原理:

浏览器发送请求时,通过Accept-Encoding带上自己支持的内容编码格式列表,服务端从中挑选一种用来对内容编码,编好码的数据就放在实体主体中,再通过Content-Encoding响应头指明选定的格式,浏览器拿到相应正文后再依据Content-Encoding进行解压。

具体过程:

  1. 网站服务器生成原始响应报文,其中有原始的Content-Type和Content-Length首部。
  2. 内容编码服务器创建编码后的报文,编码后的报文有同样的Content-Type和不同的Content-Length,同时增加了Content-Encoding首部。
  3. 接收程序得到编码后的报文,进行解码,获得原始报文。

这就有了一系列问题:

  1. file文件已经在服务端进行gzip压缩,那为何在node中用request请求这张图片时(请求的方法为head)返回头首部Content-Length还是未压缩前的图片大小?
  2. 响应头一定会包含Content-Length首部吗?
<!--响应头-->

<!--首行-->
HTTP/1.1 200 OK

<!--首部-->
Server: Tengine
Date: Fri, 05 Aug 2016 08:08:05 GMT
Connection: keep-alive
Vary: Accept-Encoding
Transfer-Encoding: chunked

<!--实体首部-->
Content-Type: image/jpeg
Cache-Control: max-age=315360000
Content-Encoding: gzip
Expires: 0
Cache-Control: no-cache


<!--实体主体-->
内容...

HTTP实体首部描述了HTTP报文的内容。在这里可以将实体首部和实体主体想象结合成一个箱子,实体首部是箱子上部的描述信息,实体主体则是箱子内货真价实的物品。

响应头的实体首部列表:

  • Content-Type
  • Content-Length
  • Content-Language
  • Content-Encoding
  • Content-Location
  • Content-Range
  • Content-MD5
  • Last-Modified
  • Expires
  • Allow
  • ETag
  • Cache-Control

http的head方法与get方法返回的首行和首部完全相同,不同的是get方法的响应头中会有主体,而head方法在响应中只返回首部,不会返回主体部分,这就允许客户端在未获取实际资源的情况下,对资源的首部进行检查。

所以在编写爬虫的时候使用了request.head方法,快捷地获取所需要的Content-Length。但是为何获取的Content-Length是gzip压缩前的大小呢?

Content-Length 实体的大小

Content-Length首部指示出报文实体主体的字节大小,这个大小是包含了所有内容编码的。比如对文本文件进行了gzip压缩的话,Content-Length首部就是压缩后的大小,而不是原始大小。

另外Content-Length首部对于长连接是必不可少的,长连接代表在连接期间会有多个http请求响应在排队,而服务器不能够关闭连接,客户端只能通过Content-Length知道一条报文在哪里结束,下一条报文在哪里开始。

除非使用了分块编码Transfer-Encoding: chunked,否则响应头首部必须使用Content-Length首部。 [摘自http权威指南]

传输编码和分块编码

分块编码把「报文」分割成若干个大小已知的块,块之间是紧挨着发送的,这样就不需要在发送之前知道整个报文的大小了。(也意味着不需要写回Content-Length首部了)

当使用持久连接时,在服务器写主体之前,必须知道它的大小并在Content-Length首部中发送。如果服务器动态创建内容,可能在发送之前无法知道主体大小,分块编码就是为了解决这种情况。服务器把主体逐块发送,说明每一块的大小。服务器再用大小为0的块作为结束块。,为下一个响应做准备。

再回过头看请求file文件服务器的图片时响应头的首部信息发现了这个首部:Transfer-Encoding: chunked

这也说明了这个图片请求的响应是采用分块编码的传输方式,采用这种传输方式进行响应时,没必要带上Content-Length这个首部信息。因为即使带上了也是不准确的。再回过头看上述file图片的响应头中确实没有Content-Length首部。

但是在node中请求http://file.showjoy.com/images/46/4695c19423cd40469fb89836373c1d45.jpg这张图片,是能取得Content-Length的,这是什么原因?

request.head('http://file.showjoy.com/images/46/4695c19423cd40469fb89836373c1d45.jpg', function (error, response, body) {
  console.log(response.headers)
})


===>

{ server: 'Tengine',
  date: 'Sun, 07 Aug 2016 04:13:08 GMT',
  'content-type': 'image/jpeg',
  'content-length': '812401',
  'last-modified': 'Mon, 11 Apr 2016 09:01:56 GMT',
  connection: 'close',
  vary: 'Accept-Encoding',
  etag: '"570b6804-c6571"',
  expires: 'Thu, 31 Dec 2037 23:55:55 GMT',
  'cache-control': 'max-age=315360000',
  'accept-ranges': 'bytes' }

上述原因在于在node中请求需要加上Accept-Encoding': 'gzip'首部信息,让服务器知道这个请求支持gzip压缩。不加这个首部,服务器就不会采取gzip压缩,同时我司服务器设定也不进行分块编码。所以返回响应头的Content-Length首部是必须的,但是这个值的大小肯定是没有进行过压缩的。

request(
  { method: 'get'
  , uri: 'http://file.showjoy.com/images/46/4695c19423cd40469fb89836373c1d45.jpg'
  , gzip: true
  }
, function (error, response, body) {
    // body is the decompressed response body 
    console.log(response.headers)
  }
)

===>

{ server: 'Tengine',
  date: 'Sun, 07 Aug 2016 04:16:10 GMT',
  'content-type': 'image/jpeg',
  'last-modified': 'Mon, 11 Apr 2016 09:01:56 GMT',
  'transfer-encoding': 'chunked',
  connection: 'close',
  vary: 'Accept-Encoding',
  expires: 'Thu, 31 Dec 2037 23:55:55 GMT',
  'cache-control': 'max-age=315360000',
  'content-encoding': 'gzip' }

同理上面请求示例开启了gzip,文件服务器根据这个标识同时开启了分块编码,致使Content-Length没有返回。

那么如何获取开启了分块编码的响应的文件大小呢?以下是node http原生写法,供大家参考。

var options = { 
  hostname: 'file.showjoy.com', 
  port: 80, 
  path: '/images/7a/7add9f81cd9b41a6aba6271c69719f71.jpg', 
  method: 'GET',
  headers: {
    'Accept-Encoding': 'gzip'
  }
}; 

var req = http.request(options, function(res) { 
  console.log('STATUS: ' + res.statusCode); 
  console.log('HEADERS: ' + JSON.stringify(res.headers));
  var chunks = [];
  res.on('data', function (chunk) {
    chunks.push(chunk);
  })
  res.on('end', function () {
    console.log('SIZE: ' + chunks.toString().length)  // file size
  })
})
req.write('data\n'); 
req.end();

原创文章 欢迎转载。

参考:

1.https://imququ.com/post/content-encoding-header-in-http.html

2.https://imququ.com/post/transfer-encoding-header-in-http.html

3.HTTP权威指南

标签: none

添加新评论