iTunes 范围请求；播客被拒绝答案

【问题标题】：iTunes Range requests; podcast is rejectediTunes 范围请求；播客被拒绝
【发布时间】：2012-08-12 06:45:16
【问题描述】：

我正在尝试将一个播客添加到处理字节范围请求的 iTunes 中。我可以通过curling 音频文件来确认这一点：

curl -H "Range: bytes=50-100" --head http://media.site.org/podcasts/upload/2012/08/15/audio-081512.mp3

HTTP/1.1 200 OK
Server: nginx/1.2.0
Date: Wed, 15 Aug 2012 22:28:40 GMT
Content-Type: audio/mpeg
Content-Length: 51
Connection: keep-alive
X-Powered-By: Express
Status: 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 50-100/1441605
Access-Control-Allow-Origin: *

但是，当我尝试将提要页面的 URL 输入到 iTunes 中时，我收到以下错误：

“您的供稿存在问题。您的剧集托管在不支持字节范围请求的服务器上。启用字节范围请求并再次尝试提交。”

音频文件托管在与提要文件不同的服务器上，并由节点服务器提供服务...但我不明白为什么只要响应标头正确就应该如此。

我在同一台服务器上提供了一些其他播客，这些播客是在iTunes 开始需要字节范围支持之前添加的，它们仍然可以正常工作（在任何平台上，包括 iPhone，表明字节范围请求确实有效）。

【问题讨论】：

标签： http http-headers itunes podcast

【解决方案1】：

如果响应标头的 HTTP 状态为 200，则即使服务器正在接受字节范围的请求，iTunes 也会拒绝播客。我所要做的就是强制使用206 Partial Response 标头。在 Node 中，它看起来像这样（CoffeeScript）：

res.writeHead 206, headers

headers 是一个包含字节范围请求的所有正确标头的哈希，例如：

headers:
  "Accept-Ranges": "bytes"
  "Content-Range": "bytes #{start}-#{end}/#{length}

start和end变量是通过解析Range请求头得到的，length是音频文件的实际大小。我还投了"Cache-Control": "no-cache" 以作好衡量。

【讨论】：