Support » Plugin: Seriously Simple Podcasting » iTunes rejecting podcast due to lack of byte-range requests

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Contributor Hugh Lashbrooke


    I haven’t explicitly tested this plugin with multisite, but I cant see any specific reason why it wouldn’t work. I will be testing that out in the next week or so though.

    That being said, I would recommend contacting your host about that to see if there’s anything on their said that they can modify.

    Also, as I mentioned in your other support request, you are using the incorrect feed URL – you should be using this one:

    If this has helped you then please consider supporting continued development by leaving a review.


    > That being said, I would recommend contacting your host about that to see if there’s anything on their said that they can modify.

    Well, we’re our own host, so that’s not going to get us anywhere 🙂

    I’ve tried using the fixed URL, and the issue persists.

    For reference, I believe it’s a relic of the fact that our MultiSite instance uses ms-files.php to serve uploaded files from subsites in the network, and that’s where the byte-range request support gets lost.

    I’ll continue to keep looking into this and will report back if I learn anything more. Note that it appears to not be a problem with JUST your plugin, but with podcasting from MultiSite configurations in general. #awkward

    Plugin Contributor Hugh Lashbrooke


    OK – in that case I’ll do some thorough testing with multisite and see what I can work out. Will be good to get to the bottom of this so I can say that SSP officially supports multisite 🙂

    One thing to keep in mind with your testing:

    This might only affect MultiSite installations that were originally created before WordPress 3.5. Before then, MultiSite used a file called ms-files.php to serve subsite files, but I believe that installations since don’t use it. I don’t have any ‘newer’ installations to test on, but I believe newer MultiSites don’t have the issue.

    Hi Hugh. Just a follow up to see if you ever found any solutions to the byte-range request issue. We’re having that problem with iTunes and have confirmed that the server is configured correctly. We are using a MultiSite installation (version 4.3.1). Thanks in advance for any advice.

    Plugin Contributor Hugh Lashbrooke


    As far as I can tell from my research SSP works just fine with multisite installations. This plugin has no control over the byte-range requests issue as that is completely a server-side problem. This plugin merely sends iTunes to the file, so if your server is not serving the files up correctly then you will need to sort that out with your hosting provider.

    There is nothing that I can do from within SSP to fix this issue as the plugin does not have control over the server. If iTunes is giving that error even though you have confirmed that your server is configured correctly then the only reason for that would be that your server is not in fact configured correctly, so you will need to follow up on that.

    Sorry that I can’t be of more help, but this is not a plugin issue – it is a server issue.


    Thanks Hugh. I’ll go back to the host and re-hash this and keep my fingers crossed.

    Hi again Hugh. Well, I finally have more information about the byte-range request error. Apologies in advance for the long post.

    Short version:
    Our paths to the actual mp3 files in the XML are getting redirected. Is this caused by the plugin or WordPress itself?

    Long version:
    Godaddy ran multiple tests and they said they confirmed that their server supports byte-range requests. So… I asked iTunes support for help and they responded with this:

    You can test byte-range requests by looking in the grey box on the right side here:
    When iTunes accesses the file:
    it is redirected to:
    Which does not respond correctly with:
    HTTP 206 Partial Content
    “Accepts Ranges: Bytes”

    Provide the info below to GoDaddy and request they reconfirm.
    ==== Provide this information to GoDaddy ====
    curl -H Range:bytes=50-60 -I -L
    HTTP/1.1 200 OK
    Date: Tue, 19 Jan 2016 19:20:35 GMT
    Server: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4
    X-Powered-By: PHP/5.4.33
    ETag: “acfd1382d062d2188d0807a096fe7ef6”
    Expires: Fri, 22 Mar 2019 05:07:15 GMT
    Content-Length: 46386821
    Last-Modified: Thu, 22 Oct 2015 12:47:53 GMT
    Content-Type: audio/mpeg

    === Example of correct response ===
    curl -H Range:bytes=50-60 -I -L
    HTTP/1.1 302 Found
    Date: Tue, 19 Jan 2016 20:30:37 GMT
    Server: Apache
    Vary: Accept-Encoding
    Connection: close
    Content-Type: text/html
    HTTP/1.1 206 Partial Content
    Accept-Ranges: bytes
    Cache-Control: max-age=2592000
    Content-Range: bytes 50-60/15828241
    Content-Type: audio/mpeg
    Date: Tue, 19 Jan 2016 20:30:37 GMT
    Etag: “569adde3-f18511”
    Expires: Fri, 19 Feb 2016 00:07:06 GMT
    Last-Modified: Sun, 17 Jan 2016 00:18:43 GMT
    Server: ECAcc (sjc/4EA8)
    Via: 1.1 varnish
    X-Cache: HIT
    X-Varnish: 1619265824
    Content-Length: 11

    I forwarded this new info to a tech at Godaddy who responded with this:

    Thank you for providing more information on this issue. Using this specific example and command I was able to verify that the server settings are properly working with byte-ranges, however anything going through your WordPress application is not. As a specific example, you can use the exact same referenced MP3 file as a direct link on the server and it works without issue:

    $ curl -H Range:bytes=50-60 -I -L
    HTTP/1.1 206 Partial Content
    Date: Thu, 21 Jan 2016 01:20:14 GMT
    Server: Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4
    Last-Modified: Thu, 22 Oct 2015 12:47:53 GMT
    ETag: “43a2227-2c3ce85-522b0e74682a0”
    Accept-Ranges: bytes
    Content-Length: 11
    Content-Range: bytes 50-60/46386821
    Content-Type: audio/mpeg

    The only difference made versus Apple’s example is to use the direct address to the file:

    As this issue is being caused within your WordPress issue, you will need to either find an alternative method of linking or uploading or review this issue with your WordPress developers.

    All of this to say that the problem seems to be a redirected path. Not really sure why it’s tagged as a byte-range request error.

    Thanks for any info you can provide.

    Hi Hugh. Not trying to be a nag 🙂 but was wondering if you’ve had any time to give this some thought?
    Thanks a bunch.


    I have similar issues with mine where it seems the URL for the audio file is being changed and iTunes doesn’t like it. iTunes is labeling it as a byte-request error but after investigating it, the actual problem is that the link to the audio file is broken. I finally got the error to go away from iTunes by disabling the Seriously Simple Stats plugin but I’m waiting to see if it actually fixed the problem with iTunes (originally iTunes wasn’t showing any of my episodes because it wasn’t seeing an audio file attached.) Is there a way to TURN OFF the URL creation for the audio files and JUST USE THE DIRECT LINK????

    Our Podcast feed url is

    Plugin Contributor Hugh Lashbrooke


    @cloudfire: There’s no need to shout – you can just use the direct link if you need to do so. This guide in the extensive plugin documentation explains how you can do that: (last section in the guide).

    @fuelbox: I honestly cannot work out what the reason is for this issue. The only thing I can think of is for you to use the raw file URL as explained in the guide I linked to here for cloudfire. That will prevent you from being able to use the stats add-on, but it sounds like that might be the only way to get your audio files to work.

    To be clear, this is an issue relating to what your server allows in terms of redirects and not something that i inherently wrong inside SSP itself.

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘iTunes rejecting podcast due to lack of byte-range requests’ is closed to new replies.