Q: Blubrry podcast not validating

The problem is not with the feed but in downloading your top episode's media file. Subscribing in the iTunes application works OK, and if you enter the media file's URL in a browser it plays OK, albeit after a slight delay.

However there is a 302 redirect in place, leading to the same URL but with https (secure connection) at the beginning instead of http. Additionally when testing in Terminal it displayed the resulting content-type as text/html:

curl -I -r 200-300 http://wwwacad.mtroyal.ca/adc/teachingstrides/promo_for_launch.mp3

HTTP/1.1 302 Found

Date: Thu, 30 Jun 2016 17:12:48 GMT

Server: Apache/2.2.3 (Red Hat)

Location: https://wwwacad.mtroyal.ca/adc/teachingstrides/promo_for_launch.mp3

Content-Type: text/html; charset=iso-8859-1

302 redirects can cause problems with some clients - please see https://en.wikipedia.org/wiki/HTTP_302 - and it's quite likely that the Store is falling over this, particularly since the redirect doesn't work as expected in Terminal. Furthermore the use of https may be inadvisable. I would advise placing the actual file at the initial URL without any redirects.

Roger, I wish you would stop replying to podcast support questions, you commonly give wrong answers. I always had my hunch that you are just answering as many questions as you can regardless if they are correct. This completely wrong answer just reinforced my suspicions. If you do not know the answer don't make one up. What you have stated is about as correct as saying the world is flat because there are no perfectly round rocks found in nature, and here's a link to Wikipedia about rocks.

There has never been a problem with 302 redirects and podcasting. I did a google search and could not find where Roger came to this conclusion. Furthermore, in iTunes documentation for podcasting specifications, it clearly states the following: "302s will be followed to a depth of five redirects and will not update the feed URL in the directory." Just to squash any concerns about 302 redirecting media files being an issue, not only has it been done since 2005 by just about every podcast media hosting service, HTTP 302 itself (as explained in the Wikipedia roger linked to) dates back to 1996 in the HTTP/1.0 protocol. If there was a problem with 302 redirects, all of the major podcasts out there would have issues, including those hosted by NPR, at LibSyn, Blubrry and even Apple's own podcasts.

THE REAL ANSWER

You are currently hosting your media on a secure server using a certificate authority (StartCom Certification Authority) that is not in the official list of supported certificates. See the full list here: https://create.blubrry.com/manual/your-web-site/secure-ssl-podcast-website/

Two solutions:

1. Revert back to serving the media without HTTPS.

I do not see a need to serve it via HTTPS since the redirect URL is not HTTPS. Anyone who is "monitoring" your computer activity will know you made the intent to download the file from the non secure first request. All HTTPS at that point is securing the downloading process, which I guarantee that if someone is monitoring what you are doing, would not be concerned about the bytes served, the secret is already out in the first http request that you are downloading that podcast.

2. Get an SSL certificate that is on the list linked above.

If you do this, then I would consider also making the root URL you are linking to HTTPS, otherwise you are not truly securing the activity.

WHY SSL IS THE ISSUE

Apple's podcast directory uses the top level certificates that are bundled with Java. As long as the top level certificate for your SSL certificate is not bundled with Java's Runtime Environment then the secure site will not be supported by iTunes podcast directory. Aside from StartCom certificates, we are aware that LetsEncrypt.org SSL certificates are not accepted by iTunes at this time. You are not alone with this top level SSL certificate problem.