正如Wrikken所建议的，这是一个有效的请求。当客户端请求媒体或恢复下载时，这也很常见。
客户端通常会进行测试，以查看服务器是否仅在寻找Accept-Ranges响应之外还处理远程请求。Chrome始终会Range: bytes=0-向其发送第一个GET请求以发送视频，因此您无法忽略它。
每当客户端Range:在其请求中包括该请求时，即使该请求的格式有误，也希望得到部分内容（206）的响应。在HTML5视频播放期间向前搜索时，浏览器仅请求起点。例如：
Range: bytes=3744-
因此，为了使客户端正确播放视频，您的服务器必须能够处理这些不完整的范围请求。
您可以通过两种方式处理在问题中指定的“范围”类型：
首先，您可以使用响应中给出的请求起始点进行回复，然后用文件的总长度减去一（请求的字节范围为零索引）进行响应。例如：
请求：
GET /BigBuckBunny_320x180.mp4
Range: bytes=100-
响应：
206 Partial Content
Content-Type: video/mp4
Content-Length: 64656927
Accept-Ranges: bytes
Content-Range: bytes 100-64656926/64656927
其次，您可以使用请求中给出的起点和开放式文件长度（大小）进行答复。这是用于网络广播或其他总长度未知的媒体。例如：
请求：
GET /BigBuckBunny_320x180.mp4
Range: bytes=100-
响应：
206 Partial Content
Content-Type: video/mp4
Content-Length: 64656927
Accept-Ranges: bytes
Content-Range: bytes 100-64656926/*
提示：
您必须始终以范围内包含的内容长度作为响应。如果范围是完整的，并且从开始到结束，那么内容长度就是区别：
请求：范围：字节= 500-1000
响应：内容范围：字节500-1000 / 123456
请记住，该范围是零索引的，因此Range: bytes=0-999实际上是请求1000个字节，而不是999个字节，因此请响应以下内容：
Content-Length: 1000
Content-Range: bytes 0-999/123456
要么：
Content-Length: 1000
Content-Range: bytes 0-999/*
但是，如果可能，请避免使用后一种方法，因为某些媒体播放器会尝试从文件大小中确定持续时间。如果您的要求是媒体内容，这是我的直觉，那么您应该在响应中包括其持续时间。使用以下格式完成此操作：
X-Content-Duration: 63.23
这必须是一个浮点数。与不同Content-Length，此值不一定是准确的。它用于帮助播放器在视频中寻找。如果您正在流播网络广播，并且只大致了解其持续时间，则最好包括估计的持续时间，而不要完全忽略它。因此，对于两个小时的网络广播，您可以包含以下内容：
X-Content-Duration: 7200.00
对于某些媒体类型，例如webm，您还必须包括内容类型，例如：
Content-Type: video/webm
所有这些都是媒体正常播放所必需的，尤其是在HTML5中。如果您不指定持续时间，播放器可能会尝试从文件大小中找出持续时间（以便进行查找），但这并不准确。很好，这对于网络广播或实时流媒体来说是必需的，但对于播放视频文件而言并不理想。您可以使用FFMPEG之类的软件提取持续时间，并将其保存在数据库或文件名中。
X-Content-Duration正在逐步淘汰Content-Duration，因此我也将其包括在内。对“ 0-”请求的基本响应至少包括以下内容：
HTTP/1.1 206 Partial Content
Date: Sun, 08 May 2013 06:37:54 GMT
Server: Apache/2.0.52 (Red Hat)
Accept-Ranges: bytes
Content-Length: 3980
Content-Range: bytes 0-3979/3980
Content-Type: video/webm
X-Content-Duration: 2054.53
Content-Duration: 2054.53
还有一点：Chrome始终会通过以下内容开始其第一个视频请求：
Range: bytes=0-
某些服务器会发送常规的200响应作为答复，它会接受（但播放选项有限），但尝试发送206来代替服务器处理范围。RFC 2616表示可以忽略范围标头。