Unable to View Source of an XML file using IE8

i have a web-page that returns XML with an xsl stylesheet transform, e.g.:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='/css/homepage.xsl'?>
<MyData>
   ...
</MyData>

It properly displays the transformed XSL as HTML. But when i try to view the XML source, Internet Explorer gives me the error:

The XML source file is unavailable for viewing

Some people claim that this behaviour is by design.

But i can give you a site where the desired behaviour works perfectly (Blizzards WoW Armory) (i.e. you can view the xml source):

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/_layout/pageIndex.xsl"?>
<page globalSearch="1" lang="es_mx" requestUrl="/index.xml" type="front">
  <pageIndex>
    <related-info/>
  </pageIndex>
</page>

So the argument that "this behaviour is by design" is disproven by direct observation.

What is wrong with my XML, that the source XML cannot be shown?

Leading you down the wrong path

Here is some supplemental information.

Http response headers from Blizzard's (working) site:

GET http://www.wowarmory.com/ HTTP/1.1

HTTP/1.1 200 OK
...
Content-Type: text/xml;charset=UTF-8
Content-Length: 233

<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type开发者_运维百科="text/xsl" href="/_layout/pageIndex.xsl"?><page globalSearch="1" lang="es_mx" requestUrl="/index.xml" type="front">
  <pageIndex>
    <related-info/>
  </pageIndex>
</page>

And here are the response headers from my (borken) xml:

GET http://www.example.com/default.ashx HTTP/1.1

HTTP/1.1 200 OK
...
Content-Type: text/xml; charset=utf-8
...
Content-Length: 131974

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='/css/homepage.xsl'?>
<MyData>
   ...
</MyData>

See also

• Viewing source in XML to XHTML transformation through XSL
• Unable to View Source of an XML file using IE7
• PRB: Browsing and Saving the Default MSXML XSL Stylesheet in Internet Explorer

tl;dr: no-cache was turned on

Long Version

i stumbled across a blog post from a guy having a similar problem:

• Debugging the Internet Explorer View Source problem with Fiddler and fixing ASP.NET

Using the automatic debugging feature of Fiddler (a feature i'd never used), he narrowed it down the presence of a particular entry in the response headers:

Vary: *

He didn't understand why this header is causing IE to break, but he was able to remove it, and it fixed his problem. i don't have the vary: 0 header in my response, but it did give me a direction.

i was reading the documentation that deals with this option: HttpCachePolicy.SetOmitVaryStar Method. One thing caught my eye:

Note The use of the vary:* header can disable all client caching.

And so i wondered if the reason that "the XML source isn't available for viewing" is that there's a policy in place forcing IE to delete the XML source as soon as it's done (i.e. don't cache it)

Following in this guy's footsteps, i dug out fiddler and turned on the Automatic breakpoints after response feature. Turns out you can then muck with the response headers, rearranging, adding, changing, deleting stuff.

Original headers (fails)

HTTP/1.1 200 OK
Date: Thu, 01 Jul 2010 02:53:35 GMT
Server: Microsoft-IIS/7.0
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/xml; charset=utf-8
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Content-Length: 134772
Via: 1.1 www.example.com

<?xml version="1.0" encoding="utf-8"?>
...

i noticed that my headers have entries relating to caching:

Cache-Control: no-cache
Pragma: no-cache

perhaps if i remove those? i go into the spot in fiddler and manually delete those two lines, leaving:

Remove cache control headers

HTTP/1.1 200 OK
Date: Thu, 01 Jul 2010 02:55:06 GMT
Server: Microsoft-IIS/7.0
Content-Type: text/xml; charset=utf-8
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Content-Length: 134772
Via: 1.1 www.example.com

<?xml version="1.0" encoding="utf-8"?>
...

Note: The headers are not there by mistake, the content is always stale, and i want the client to refresh every time.

My initial solution fixes the problem, but introduces a new one - since the content is always stale. While i want ie to fetch every time, i don't really want it to delete its own local copy.

The line in the ashx that's giving me grief is:

//client don't cache it (it's too volatile)
context.Response.Cache.SetCacheability(HttpCacheability.NoCache); 

which turns into:

Cache-Control: no-cache

Removing the line leaves Cacheability as its default (Private), giving the response value:

Cache-Control: private

This allows the client to cache the content, and i can view source in the browser.

I can't reproduce this behavior. Check my XML/XSLT driven site http://www.aranedabienesraices.com.ar

With IE8, I can see the source and transformation result (Tools menu).

Could it be related to private cache?

I was having this same problem this days in Internet Explorer 9 but using the compatibility view and the 7 and 8 versions it provides in the developer tools.

I had this in my .htaccess

<FilesMatch "\.(php)$">
    Header unset Cache-Control
    Header set Cache-Control "max-age=86400, s-maxage=86400, no-store"
    Header set Pragma "cache"
    Header set Expires "Mon, 5 Aug 2013 20:00:00 GMT"
</FilesMatch>

changed the cache-control headers to store and now I can see the xml source of the file

<FilesMatch "\.(php)$">
    Header unset Cache-Control
    Header set Cache-Control "max-age=86400, s-maxage=86400, store"
    Header set Pragma "cache"
    Header set Expires "Mon, 5 Aug 2013 20:00:00 GMT"
</FilesMatch>

I got this error trying to figure out why a page that looks ok on every single browser in windows and linux didn't work in compatibility view or older versions of Explorer. That problem is still a mystery since the document and headers are set to utf-8. But that's another thing.

I was having the same problem. I changed the Response.ContentType to "text/xml" which was previously "application/xml". The "text/xml" format allows to "View Source".

What's the difference between text/xml vs application/xml for webservice response