2

バイト範囲のリクエストを処理しているiTunesに追加しようとしているポッドキャストがあります。curlオーディオファイルを使用してこれを確認できます。

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を含むすべてのプラットフォームで、バイト範囲の要求が実際に機能していることを示します）。

4

1 に答える 1

2

応答ヘッダーのHTTPステータスが200。の場合、サーバーがバイト範囲の要求を受け入れている場合でも、iTunesはポッドキャストを拒否します。私がしなければならなかったのは、206 Partial Responseヘッダーを強制することだけでした。Nodeでは、次のようになります（CoffeeScript）：

res.writeHead 206, headers

headers次のようなバイト範囲リクエストのすべての適切なヘッダーを含むハッシュである：

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

および変数は、要求ヘッダーを解析することによって取得されstartます。これは、オーディオファイルの実際のサイズです。私もかなりの量を投入しました。endRangelength"Cache-Control": "no-cache"

于 2012-08-16T01:01:39.840 に答える