示例HTTP范围请求会话


91

是否可以向我展示带有范围请求的示例http会话。我的意思是请求和响应头是什么?


2
几个月前,发布了新版本的HTTP / 1.1标准。它具有用于范围请求的特殊RFC,比旧规范更具可读性,包括许多项目的示例:tools.ietf.org/html/rfc7233
Thirler,2015年

Answers:


135

以下是Chrome和静态网络服务器之间的交换,以检索MP4视频。

初始请求-视频。请注意Accept-Ranges响应标头以指示服务器具有范围标头支持:

GET /BigBuckBunny_320x180.mp4
        Cache-Control: max-age=0
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range:
        Accept: text/html,application/xhtml+xml,application/xml,*/*
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Accept-Encoding: gzip,deflate,sdch
        Accept-Charset: ISO-8859-1,utf-8,*
200 OK
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 64657027
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:24 GMT

检测到先前响应中的范围标头-后续请求具有开放范围以确认支持。响应返回206状态和Content-Range标头,以指示响应正文中存在的字节:

GET /BigBuckBunny_320x180.mp4
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range: bytes=0-
        Accept: */*
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Referer: http://localhost:8080/BigBuckBunny_320x180.mp4
        Accept-Encoding: identity
        Accept-Charset: ISO-8859-1,utf-8,*
206 Partial Content
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 64657027
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:25 GMT
        Content-Range: bytes 0-64657026/64657027

随后的范围请求以捕获文件结尾(可能是捕获尾随的元数据):

GET /BigBuckBunny_320x180.mp4
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range: bytes=64312833-64657026
        Accept: */*
        If-Range: A023EF02BD589BC472A2D6774EAE3C58
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Referer: http://localhost:8080/BigBuckBunny_320x180.mp4
        Accept-Encoding: identity
        Accept-Charset: ISO-8859-1,utf-8,*
206 Partial Content
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 344194
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:25 GMT
        Content-Range: bytes 64312833-64657026/64657027

用户单击视频进度条中超出下载范围的内容-发出范围请求以从选定位置开始播放:

GET /BigBuckBunny_320x180.mp4
        Connection: keep-alive
        Accept-Language: en-GB,en-US,en
        Host: localhost:8080
        Range: bytes=1073152-64313343
        Accept: */*
        If-Range: A023EF02BD589BC472A2D6774EAE3C58
        User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 ...
        Referer: http://localhost:8080/BigBuckBunny_320x180.mp4
        Accept-Encoding: identity
        Accept-Charset: ISO-8859-1,utf-8,*
206 Partial Content
        Content-Type: video/mp4
        Connection: keep-alive
        Last-Modified: Wed,14 Dec 2011 15:50:59 GMT
        ETag: A023EF02BD589BC472A2D6774EAE3C58
        Transfer-Encoding:
        Content-Length: 63240192
        Accept-Ranges: bytes
        Server: Brisket/1.0.1
        Date: Wed,14 Dec 2011 16:11:25 GMT
        Content-Range: bytes 1073152-64313343/64657027

7
空白的Transfer-Encoding标头是捕获HTTP通信方式的伪像,还是那里有一个真正的HTTP服务器为此标头生成空白值?
swl10

7
在第一种情况下,服务器似乎返回了64657027字节的内容。那么发生了什么-客户是否只是丢弃了该内容,然后随后发出了真正想要的零件的范围请求?还是服务器未返回任何内容,原因是客户端消息中的某些内容表明请勿执行此操作。如果是这样,那是什么?
莫里

3
@Morrie-好像服务器知道自己本身支持范围请求,并通过Accept-Ranges: bytes标头告诉客户端“我接受范围请求” ,但是它还会向下发送资源的内容长度,以便客户端可以使用上限值发出范围请求界。据我所知,客户端消息中没有任何内容表明可以执行此操作-服务器可以选择以“这里是整个资源”或“我接受范围请求”进行响应-再次是Accept-Ranges标头的存在。无论如何,这就是我的理解。
西蒙·怀特海德2015年

4
但是,第一个响应中的64657027的Content-Length是否表示实际上在标头之后有很多字节的有效载荷,客户端必须消耗该有效载荷,因为连接是保持活动状态的?我想知道响应消息中的内容是实际上没有任何有效负载。
莫里

1
@Morrie Keep-alive是来自客户端的请求,客户端没有任何义务继续使用连接。我刚刚在自己的工作中得出结论,至少对于chrome,在收到标头后立即立即中止范围为“ 0-”的第一个GET请求,而不是使用HEAD请求。我相信,这是一种避免可能无法正确实现HEAD动词的服务器出现问题的方法。
Zoomulator 2015年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.