Cross Domain Media URLs do not work?

[daveseah]

I think I found a bug or limitation in 4.0.5.

If I am hosting a blog at one domain, and attempt to link a URL that exists on another domain, I get the error: Media URL reporting incorrect content type: text/html; charset=UTF-8 This is an inaccurate error, and appears to be a bug/limit of CURL or the way it is being used.


BACKGROUND

I have our podcasting website at http://nonazon.com/podcast, but for historical reasons the podcast files themselves are stored at http://davidseah.com/pub/podcasts. For example: http://davidseah.com/pub/podcasts/CeaserSeahPodcast034.mp3

When I click "Verify", I get the above error. After tracing through the code to see what it was doing, I noticed that the media URL failed and was followed with a second pointing to http://nonazon.com. What? This URL succeeded, and returned the media type of an HTML page.

After spending several hours testing my PHP configuration to no avail, I tried moving the MP3 file from davidseah.com to nonazon.com, mirroring the directory structure:

• old: http://davidseah.com/pub/podcasts/CeaserSeahPodcast034.mp3
• new: http://nonazon.com/pub/podcasts/CeaserSeahPodcast034.mp3

The new URL worked, and so I copied over all the MP3 files and prepared for the arduous task of handling incoming links that have to now be redirected. However, I happened to try the davidseah.com URL on another podcast post and IT WORKED. Wha? Did one of my experiments disabling BASEDIR work?

Nope. I tried renaming the nonazon podcast directory to "pcast", and the newly working blog entry (with davidseah.com) failed. Apparently, the media URL is being rewritten to look at the local directory, completely ignoring whatever domain you specify if it is not local.

So the workaround appears to be this:

• You can't have your MP3 files on a different server than your blog.
• If you do, copy them over to the same directory structure on the local server if possible.

So right now I have two sets of the same files. I don't know if this is a cURL thing or a bug in the plugin. In any event, the code on my server is malfunctioning in a misleading way.


SYSTEM INFO:

MediaTemple (dv) 4, PHP 5.3.5, WP 3.5 Network (Multisite), Blubrry PowerPress 4.0.5

[1/29/2013: updated URLs in post to point to renamed files]

[angelo]

There's no bug, this content type check is for your benefit. iTunes and mobile devices will not download a media file with the incorrect content type. Search the internet for how to fix this based on your web server. e.g. Google "Apache set content type".

As far as moving folders and such, I bet there's a .htaccess file in the folder your copying at the same time which sets the correct content type, but that's just a guess.

[daveseah]

Angelo:

My writeup was probably unclear.

In my case, the plugin is checking the wrong URI. Instead of checking the media URI I provided, it is checking the domain URI for some unknown reason. I found this after spending a long time verifying that my server was serving the correct MIME type using public tools. So why was the plugin failing? To find out, I traced through the plugin code itself as it ran, and saw it redirect to the hosting site domain's main web page URI. Which of course returns text/html, since this is a web page.

The pattern appears to be that my podcast files are hosted on a different domain than the podcast blog. Both domains happen to be on the same server, though. I'm reporting this in case other people have had a similar problem, or if the developers might have some notion that this is a possible bug.

I could express my theory as: "does checking the URI of a media file on a remote domain fail, when both the local domain and the remote domain are running on the same physical server?"

[daveseah]

I've resolved the problem: it was due to a misconfigured /etc/hosts file that assigned the wrong IP address to the domain. Everything is now working properly. Thanks for your patience!

[angelo]

Wow ok that /etc/hosts would do it, and it would have been nearly impossible for us to figure that out.