It looks like a recent change to Spaces makes it more restrictive on MIME types than  Specifically, where the application/xml MIME type used to work just fine on Spaces and continues to work on, Spaces will no longer load a gadget.xml manifest presented as application/xml.  Instead, it requires the manifest to present as text/xml.  This was preventing me from debugging my gadgets on Spaces because my web host presents .xml files as application/xml (a simple .htaccess file fixes this, but it took me a bit to track down the root of the problem).

My Hangman gadget currently has a problem retrieving its data feeds which are presented by Yahoo as application/xhtml+xml.  The same feeds pull just fine on, so my current belief is that this is another manifestation of the more strict MIME type requirements.  All I get from responseXML is "<error>Invalid XML</error>", which doesn't really help much.

Was this MIME type restriction intentional   Is there any way to make it less strict   I'd expect it to support at least application/xml, and preferrably also application/xhtml+xml.  Otherwise this will severely restrict our data feed options.  Obviously I can't get Yahoo to change their RSS MIME types, nor would I expect them to do so.

Edit:  Flipping over to the RSS proxy allows me to retrieve the application/xhtml+xml feed.  I don't like that fix for the long run as the Atlas Firefox compat layer has issues with XPath selections on nodes with namespaces when using XML retrieved via the RSS proxy (which is really silly, since Firefox has better XPath support than IE -- I don't understand why Atlas needs that compat layer in the first place).

Re: Web Gadget Development MIME types in Spaces vs.

Ben Walters - MSFT

We did intentionally make a change to be more restrictive of the mime types we allow through our web proxy.  Allowing only text/xml is probalby too restrictive.   We'll allow application/xhtml+xml and application/xml in our next release.