示例 http 范围请求会话答案

【问题标题】：Sample http range request session示例 http 范围请求会话
【发布时间】：2012-01-07 18:50:12
【问题描述】：

是否可以向我展示一个包含范围请求的示例 http 会话。我的意思是请求和响应标头是什么？

【问题讨论】：

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

【解决方案1】：

以下交换发生在 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

【讨论】：

空白的 Transfer-Encoding 标头是捕获 HTTP 通信方式的人工制品，还是有真正的 HTTP 服务器为该标头生成空白值？
在第一种情况下，看起来服务器正在返回 64657027 字节的内容。那么发生了什么——客户是否只是丢弃了该内容，然后针对真正想要的部分发出范围请求？或者服务器没有返回任何内容，因为客户端消息中的某些内容说不要这样做。如果有，是什么？
@Morrie - 似乎服务器知道自己支持范围请求，通过 Accept-Ranges: bytes 标头告诉客户端“我接受范围请求”，但它也发送了内容长度资源，以便客户端可以使用上限发出范围请求。据我所知，客户端消息中没有任何内容表明要这样做——服务器可以选择以“这里是整个资源”或“我接受范围请求”作为响应——这又是 Accept-Ranges 标头的存在。反正这是我的理解。
但是第一个响应中的 64657027 的 Content-Length 是否意味着实际上在标头后面有那么多字节的有效负载，客户端必须消耗这些字节，因为连接是 Keep-Alive？我想知道该响应消息中的什么内容表明实际上没有任何有效负载。
@Morrie Keep-alive 是来自客户端的请求，客户端没有任何义务继续使用连接。我刚刚在自己的工作中得出结论，至少对于 chrome，第一个范围为“0-”的 GET 请求在收到标头后立即中止，而不是使用 HEAD 请求。我相信这是一种避免任何可能无法正确实现 HEAD 动词的服务器出现问题的方法。