iTunes範圍請求;播客被拒絕

有一個播客，我試圖添加到處理字節範圍請求的iTunes。我可以curl確認這荷蘭國際集團的音頻文件：iTunes範圍請求;播客被拒絕

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: *

然而，當我試着輸入網址到飼料頁面到iTunes中，我得到以下錯誤：

"There is a problem with your feed. Your episodes are hosted on a server which doesn't support byte-range requests. Enable byte-range requests and try your submission again."

的音頻文件託管在與供稿文件不同的服務器上，並由一個節點服務器提供服務......但只要響應標頭是正確的，我就不明白爲什麼這很重要。

我有相同的服務器，向其中加入前 iTunes中被服務的其他一些播客開始要求字節範圍的支持，他們仍然正常工作（任何平臺，包括iPhone上，這表明字節範圍請求確實在工作）。

來源

2012-08-15 bricker

如果響應標頭的HTTP狀態爲200，則即使服務器正在接受字節範圍請求，iTunes也會拒絕播客。我所要做的只是強制一個206 Partial Response標題。在節點，它看起來像這樣（CoffeeScript的）：

res.writeHead 206, headers

headers是包含所有字節範圍請求適當的報頭，諸如散列：

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

的start和end變量獲取通過解析Range請求標頭，而length是音頻文件的實際大小。我也扔了"Cache-Control": "no-cache"好措施。

來源

2012-08-16 01:01:39 bricker

iTunes範圍請求;播客被拒絕

回答

相關問題