Cannot create enclosures for links to files on SkyDrive

[cmischenko]

I have linked to MP3 files in my SkyDrive account, but the SmartCast feature won't create enclosures for those files.

Feed is http://feedburner.com/cbc-sermons

The error reported by PodMedic is:

"Media enclosure not created because: The URL was unavailable or FeedBurner could not receive a response within 10 seconds."

However, I consistently can reach these linked files from my browser, the RSS of my feed validates, and web-sniffer shows that the MIME type is being returned as audio/mpeg.

[rklau]

Sounds like SkyDrive is taking too long to respond to our requests. We can't let our requests stay open indefinitely, so we give external servers 10 seconds to return our request for info. Seems like you'll need to find a server to host your files that has a more reasonable response time.

[cmischenko]

I realize that's what it *sounds* like -- you're not telling me anything the error message didn't already say. :)

However, I have traversed the links to these files hundreds of times and not once has the SkyDrive service taken more than a split second to respond and start returning the file to me. I cannot believe that your system gets worse response to these links than I do from my puny DSL broadband connection at my home office unless there is an artificial delay or blocking occurring on one side of the connection (SkyDrive's or yours).

What I was hoping was that you would actually check the feed and tell me if the connections are being blocked. If these links are slow or unreachable from your service to theirs (when they aren't from my consumer internet connection) that there is an artificial block or delay being introduced on their side or yours or some kind of a routing problem that shouldn't be happening. Is it possible that your service isn't handling the rather lenghty URL for the SkyDrive files properly?

I guess what it comes down to is that from all of the testing that I am doing, there doesn't appear to be any actual performance problem on the SkyDrive site. I'd appreciate it if you could look into this problem and dig a little deeper than the error message that I'm currently getting which doesn't unambiguously identify the problem. Why would your systems get a different response from the SkyDrive servers than my systems do?

Thanks

[rklau]

It probably means that they're taking their time responding to an http head request, which is all we do - we don't ask for the entire file, just for the file headers. I'd submit a help request with SkyDrive and ask what their policy is on responding to head requests.

[cmischenko]

http://web-sniffer.net/?url=http%3A%2F%2Fbmhkrq.bay.livefilestore.com%2Fy1pALBYAG1FMRF77g0bW49mow7hfxhCSl9akVnFwrII0QFe0W-DmR5vvCKNteekV9zmY5ZHlkZTm-qrk3bZ2nz2BKazWfYPW5Sy%2Ftest.mp3%3Fdownload&submit=Submit&http=1.1&gzip=yes&type=HEAD&uak=0

This web-sniffer shows how the SkyDrive system is responding to a HEAD request, and it returns "immediately" (without any human-observable delay) on my system. Can you take a look at this response and tell me what in the SkyDrive response is problematic and would be causing FeedBurner to think that it isn't getting a successful or timely response. Or is there something in the content of the HTTP HEAD response that is incorrect or causing a problem?

[rklau]

Thanks for posting that. I don't see any content type in the response to the head request, so that may be it. I'll have one of our engineers take a look to verify.

[rklau]

Yep. Sorry for the goose chase here, but that's the issue: by not including content type in the head request response, we don't know that it's a media file, and can't create the enclosure as a result. If SkyDrive included content type in the headers of its response, we'd be all set.

[cmischenko]

Thanks. Does Google offer a free "cloud file storage" solution that would be compatible with Feedburner?

[rklau]

Not at this time.