iTunes Range requests; podcast is rejected

Question

There is a podcast that I'm trying to add to itunes which is handling byte-range requests. I can confirm this by curling the audio file:

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

However, when I try to enter the URL to the feed page into iTunes, I get the following error:

"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."

The audio files are hosted on a different server than the feed file, and are being served by a Node server... but I don't see why that should matter as long as the response headers are correct.

I have some other podcasts being served from the same server, which were added before iTunes started requiring byte-range support, and they still work fine (on any platform, including iPhone, indicating that the byte-range requests are indeed working).

Answer 1

If the response headers have an HTTP Status of 200, then iTunes will reject the podcast even if the server is accepting byte-range requests. All I had to do was force a 206 Partial Response header. In Node, it looks like this (CoffeeScript):

res.writeHead 206, headers

headers being a hash containing all the proper headers for byte-range requests, such as:

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

The start and end variables are acquired by parsing the Range request header, and the length is the actual size of the audio file. I also threw in "Cache-Control": "no-cache" for good measure.