"Enable byte-range requests..." but I'm sure my host has this enabled?

Question

"Enable byte-range requests..." but I'm sure my host has this enabled?

Hi,

I'm trying to submit a podcast feed but I am receiving this 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."

Now, I know this is a common error, I understand why and what causes it and I've already read all the threads on here but I am none the wiser. I'm sure my hosting provider already supports this request type, as you can see here:

$ curl -I -r 200-300 http://myhost.com/some/path/to/episode.mp3

HTTP/1.1 206 Partial Content

Date: Thu, 23 Aug 2012 20:40:25 GMT

Server: Apache

Last-Modified: Sat, 04 Aug 2012 13:50:29 GMT

ETag: "31ffbc6-19ff95b4-4c670ed7806f5"

Accept-Ranges: bytes

Content-Length: 101

Content-Disposition: attachment

Content-Range: bytes 200-300/436180404

Content-Type: applicaton/x-octet-stream

Here is my feed:

http://feeds.feedburner.com/TheStressFactorPodcast

I've validated it and tested it in iTunes and it seems fine.

So what am I missing? Does the above not prove that my hosting provider supports byte-range requests? Has anyone had this problem? Perhaps a feedburner issue?

Any help much appreciated!

Posted on Aug 23, 2012 1:58 PM

Reply

Answer 1

Aug 23, 2012 2:11 PM in response to Community User

It isn't the hosting service for the feed which matters, but that for the episode media files. Your top episode's media file URL is

http://feedproxy.google.com/~r/TheStressFactorPodcast/~5/CAzsB6CMBKA/Stress_Fact or_Podcast_090_-_DJ_B-12_-_August_2012_Three_Hour_Drum_And_Bass_Studio_Mix.mp3

When entered in a browser, this downloads - that's not going to work, you need a direct URL to the mp3 file and it should play in a browser, not dowload (as well as being on a server which accepts byte-range requests).

The URL above redirects to another URL, but as it downloads the URL disappears to quickly to see what it is. The server your media files are on is not configured properly to serve mp3 files.

Reply

Answer 2

Aug 23, 2012 2:27 PM in response to Roger Wilmut1

Roger,

Ah I see, I hope you're right. We had an htaccess file that was forcing the "Content-Disposition: attachment" header so I've removed this and indeed that header is now gone.

Let's see if it fixes it. Thanks!

Reply

Answer 3

Aug 24, 2012 2:08 PM in response to Roger Wilmut1

Hi Roger,

I'm afraid this didn't really help. I still get the same error message. Any more ideas?

Thanks,

Reply

Answer 4

Aug 24, 2012 2:16 PM in response to Community User

The top episode's media file now plays correctly in a browser, though it's still a redirect - I don't know whether that is any sort of issue. But I'm afraid I can't advise any further on byte-range requests - if the Store is saying your server doesn't have it and the people running your server say it does (though I can't say whether the log you quote in your first post actually proves that it does) then the only thing I can suggest - which you don't want to hear - is that you find another hosting service, specifically asking them to confirm that they do handle it.

Reply

Answer 5

Aug 24, 2012 2:24 PM in response to Roger Wilmut1

OK thanks for your help anyway Roger.

According to this page here they do support redirects and considering this is Feedburners way of counting hits I can't imagine its not supported by Apple:

http://www.apple.com/itunes/podcasts/specs.html#tracking

Hmmmmm....

Reply

Answer 6

Aug 31, 2012 8:23 AM in response to Community User

I just thought I'd update this thread with more information as I have spent quite a while looking at this problem and I think this info may help other people. As I stated in my original post, my hosting provider does support byte-range requests. After spending a good couple hours adjusting and retrying the submission with different versions of my feed I noticed this error message is erroneous!

iTunes seems to throw this error randomly. First I noticed it gave the error when I had a typo in my feed which made the enclosure URL invalid (it returned a 404) but iTunes still gave the "byte-range requests" error. I then noticed sometimes iTunes would accept the feed and sometimes not. Then I worked out once I get the error I could just click the "continue" button repeatedly and then after 3-10 times it would accept the submission. Stupid!

So in summary, if you are sure your hosting provider supports byte-range requests and you still get the error, just retry. You can check if your provider supports it by using the command in my first post and see what HTTP headers are returned. The ones in bold should indicate that your provider supports it. The curl command is not on Windows but it is on Linux and I think it is on OSX.

I hope this helps someone!

Reply

Answer 7

Aug 31, 2012 8:32 AM in response to Community User

Interesting. This is the result of your curl process with one of my episodes, hosted on GoDaddy:

curl -I -r 200-300 http://rfwilmut.net/podcasts/Soundof78s36.mp3

HTTP/1.1 206 Partial Content

Date: Fri, 31 Aug 2012 15:31:14 GMT

Server: Apache

Last-Modified: Sat, 02 Jul 2011 07:44:11 GMT

ETag: "5d9337a-a3939a-4a7114cd0ffc3"

Accept-Ranges: bytes

Content-Length: 101

Content-Range: bytes 200-300/10720154

Content-Type: audio/mpeg

Would you read this as meaning that GoDaddy do accept byte-range requests? - because it seems to be generally nbelieved that they don't.

Reply

Answer 8

Aug 31, 2012 10:15 AM in response to Roger Wilmut1

Hi Roger,

Given what I've read about byte range requests, I would say that particular file on that particular host can be downloaded using a HTTP 1.1 byte range request. I don't know anything about GoDaddy or what their policies are.

Here is an example of a server that does not allow byte range requests, it returns a 200 status code:

$ curl -I -r 200-300 http://img1.wsimg.com/fos/hp/1/86462_background.jpg

HTTP/1.1 200 OK

Content-Type: image/jpeg

Last-Modified: Tue, 24 Jul 2012 21:10:50 GMT

Accept-Ranges: bytes

ETag: "0e934cde069cd1:0"

Server: Microsoft-IIS/7.5

X-Powered-By: ASP.NET

Content-Length: 24381

Cache-Control: max-age=3888000

Date: Fri, 31 Aug 2012 16:57:21 GMT

Connection: keep-alive

This file is part of the GoDaddy homepage.

If anyone is interested here is some more reading...

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

(Scroll down to "10.2.7 206 Partial Content")

http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-latest.html#rfc .section.4

http://benramsey.com/blog/2008/05/206-partial-content-and-range-requests/

I could still be wrong but from the reading I've done I'd say if you receive a 206 you are good 🙂

BTW you're a star with the amount of support you give in this forum!

Max

Reply