示例：HTTP范围请求会话

Question

您能否给我展示一个使用范围请求的HTTP会话示例，即请求和响应头部是什么？

- chamal

---

几个月前，HTTP/1.1标准的新版本已经发布。它有一个专门的RFC用于范围请求，这比旧规范更易读，包括许多项目的示例：https://tools.ietf.org/html/rfc7233 - Thirler

Answer 1

下面的对话是Chrome浏览器与一个静态Web服务器之间的交互，用于获取一个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

- johnstok

---

空的Transfer-Encoding头是HTTP通信被捕获的方式的副产品，还是真的有HTTP服务器生成此头的空值？ - swl10

在第一种情况下，似乎服务器正在返回64657027字节的内容。那么究竟发生了什么情况——客户端是否只是丢弃了那部分内容，随后再请求它真正需要的部分范围？或者是因为客户端的消息中有某些内容指示不要返回任何内容，所以服务器没有返回任何内容？如果是这样，那是什么内容？ - Morrie

根据我的理解，似乎服务器知道自己支持范围请求，通过 Accept-Ranges: bytes 标头告诉客户端“我接受范围请求”，但它还发送资源的内容长度，以便客户端可以进行带有上限的范围请求。就我所知，客户端消息中没有任何要求这样做 - 服务器可以选择响应“这是整个资源”或“我接受范围请求” - 这就是 Accept-Ranges 标头的存在。那就是我的理解。 - Simon Whitehead

第一个响应中的Content-Length为64657027，这是否意味着在标头后面实际上有那么多字节的载荷需要客户端消耗，因为连接是Keep-Alive？我想知道响应消息中的哪些内容表明实际上没有任何有效负载。 - Morrie

@Morrie Keep-alive是客户端的请求，客户端没有任何义务继续使用连接。在我的工作中，我得出结论，至少对于Chrome来说，第一个带有范围“0-”的GET请求一旦接收到头部信息就会立即中止，而不是使用HEAD请求。我认为这是一种避免与任何未正确实现HEAD动词的服务器发生问题的方法。 - Zoomulator