Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Error Parsing Feed: Invalid XML

I am getting this message when I submit my podcast feed to itunes but I know the feed is valid according to feed validator.org.


Feed Url is http://feed.theplatform.com/f/w8GvE/soulierefeedforpodcast2


I do get these responses back but they seem benign.


This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.






Can you take a look and suggest what might be wrong.

iTunes-OTHER, Mac OS X (10.6.6), Not a client issue

Posted on Sep 13, 2011 5:21 PM

Reply
12 replies

Sep 14, 2011 2:17 PM in response to frankfromsammamish

I think the problem probably lies in the very complex URL you have for your media file. The actual URL has several ampersands in it:


http://release.theplatform.com/release/content.mp4/file.mp4/file.m4v?metafile=fa lse&pid=Y61PQjT0tPOh_862pvlmV42ZcY5MvL3n&feed=Souliere%20Family%20PodCast&metafi le=false


(The forum has inserted a line return in the middle of the word 'false' but of course the URL is all one line.) Because ampersands can cause problems in an XML feed they have been replaced in the feed by the code &


http://release.theplatform.com/release/content.mp4/file.mp4/file.m4v?metafile=fa lse&pid=Y61PQjT0tPOh_862pvlmV42ZcY5MvL3n&feed=Souliere%20Family%20PodCast&metafi le=false


This version works in iTunes when subscribing, but it doesn't work in a browser, whereas the first one does (although it downloads rather than plays). The iTunes Store, though it's not a browser, behaves in a similar manner and plainly doesn't like this URL: though I can't be sure of this it seems likely that this is why you are being rejected.


These complex URLs involving server-side scripting are a bad idea in a podcast feed: they often cause problems. You should try to provide a direct link to the actual media file: the test is that when it's pasted into a browser's address bar it plays the file.

Sep 20, 2011 5:09 PM in response to Roger Wilmut1

HI Roger,

As you suggested, I simplified the url and it now plays in a browser. However, iTunes still rejects my submission with the same vague error message.


Here is the feed URL.

http://feed.theplatform.com/f/w8GvE/soulierefeedforpodcast2


In the past we have succesfully submitted a podcast that was generated by our system. The file url is the same. Here is the URL to that feed.


http://feed.theplatform.com/f/YGTCaB/DWHvoxKzeuoT?form=iTunes&adapterParams=imag e%3DThe_American_Veteran%26podcastKeywords%3Dveteran,benefits,military,va


Help !

Sep 22, 2011 12:55 PM in response to frankfromsammamish

This appears to have absolutely nothing to do with the content of your feed. When I save a copy of your XML to my server and submit that URL, it goes through to the next step (preview), even when I make sure the headers coming from my server match the non-working URL. I pulled both responses from the servers and compared them -- they are absolutely identical.


I'm not sure what's going on here, but the error message can't be correct: that same XML submits fine in other contexts.

Sep 22, 2011 1:29 PM in response to EricHolbrook

To try to narrow the problem down to something in the headers, I used a PHP script to try to fake as many of the headers to look like Frank's URL as possible. Here's the set of headers from the working submission: (my server)


HTTP/1.1 200 OK

Date: Thu, 22 Sep 2011 19:39:50 GMT

Server: Apache

X-Cache: HIT from (my test server)

Expires: Thu, 22 Sep 2011 19:40:02 GMT

Access-Control-Allow-Origin: *

Connection: close

Last-Modified: Wed, 21 Sep 2011 00:12:44 GMT

Content-Type: application/rss+xml; charset=UTF-8

Content-Length: 1742


And here's from the non-working submission: (feed.theplatform.com)

HTTP/1.1 200 OK

Date: Thu, 22 Sep 2011 19:35:02 GMT

Content-Type: application/rss+xml; charset=UTF-8

X-Cache: HIT from feed.theplatform.com

Last-Modified: Wed, 21 Sep 2011 00:12:44 GMT

Expires: Thu, 22 Sep 2011 19:40:02 GMT

Access-Control-Allow-Origin: *

Connection: close

Server: Jetty(6.1.19)


The only meaningful difference I can see is in the Content-Length, which does not appear to be a part of Frank's submission. Is it possible that a missing Content-Length will result in a bad XML error?


If anyone wants to try to replicate this test, I used a variation on Frank's original URL to limit the set of items returned to one: http://feed.theplatform.com/f/w8GvE/soulierefeedforpodcast2?range=1-1

Sep 22, 2011 3:41 PM in response to frankfromsammamish

Missing Content-Length doesn't appear to be the make-or-break, either. The original submission URL now contains a Content-Length, but is still rejected with the same 'Invalid XML' error.


Is there any chance this podcast feed is being rejected because someone else had already submitted a feed from http://feed.theplatform.com, and the owner (or something) does not match that of the original submission?

Sep 22, 2011 11:31 PM in response to EricHolbrook

EricHolbrook wrote:


Is there any chance this podcast feed is being rejected because someone else had already submitted a feed from http://feed.theplatform.com, and the owner (or something) does not match that of the original submission?

I wouldn't have thought so. You have to have an account to submit the feed in the first place: but once it's up the Store just reads it, and it can be modified by anyone who can access the server, quite independently of their iTunes login. Also, many people have more than one podcast on the same server.

Sep 23, 2011 12:01 PM in response to frankfromsammamish

Further investigation shows that that the Content-Length header does not actually appear for a request made by iTunes. So, when this podcast URL is consumed, it's coming back from the http://feed.theplatform.com server without Content-Length attached. That's still my #1 suspect here -- there just aren't many other variables that haven't already been eliminated.


Can anyone confirm one way or the other whether a podcast feed without a Content-Length HTTP header can be successfully submitted?

Sep 26, 2011 9:56 AM in response to EricHolbrook

Here's an interesting twist: the problem doesn't happen when iTunes arrives there through a 302 redirect.


http://tinyurl.com/frankfeed


This works: iTunes accepts the request and moves us along to the status page, but still rejects the original URL.


So, the URL that is rejected when it's accessed directly is accepted when it's delivered via a 'Document Moved Temporarily' HTTP status code, as issued by any URL-shortening service. In my mind, this proves conclusively that the feed is correct and the error message is wrong.


A dependency on a third-party service to submit a podcast and keep it online is not good. Why is this happening? Is there any way to get this issue escalated to Apple for investigation?

Sep 26, 2011 12:45 PM in response to frankfromsammamish

After Frank was unable to replicate my success using TinyURL, I poked around some more, trying to find a consistent repro, and at the end of the effort, I wasn't able to find one.


I learned instead that the issue is intermittent: clicking the 'Submit' button repeatedly will eventually allow me to bypass the 'Invalid XML' error and get to the preview pane. Around 20 clicks of 'continue' seems to do it for me.

Error Parsing Feed: Invalid XML

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.