Wednesday, November 7, 2012

Testing owssvr.dll output

This is really a minor thing, but it annoyed me off and on over the span of a few months, and I just realized what the issue was and quickly fixed it.

I've touched on using owssvr.dll to create XMLified list dumps for consumption in InfoPath and other applications before. It was pretty straight-forward to do in SharePoint 2007, though once I migrated to SharePoint 2010, the lists weren't working exactly as I'd expect anymore. InfoPath seemed to be able to consume them fine (once I added noredirect=TRUE to the request).

If I wanted to actually see the output I was getting from a request, however, normally I'd open up Internet Explorer, punch in the URL, and I'd see XML splashed all over my monitor. Until now. Now, IE wants to download the file instead. What a pain.

It turns out that this is related to a common problem folks have with new farms and viewing PDFs. The safe MIMEtype collection default in SharePoint doesn't contain a MIMEtype entry for application/PDF, nor does it contain one for application/xml!

Now, in Production, this is generally fine. My users won't be storing XML data in SharePoint, so I won't bother with updating the permitted MIMEtype list for the web application. In Development, however, I'm going to be using this a lot, and I'd rather not get bitten by the problem again, so...Central Administration -> Manage Web Applications...open General Settings for each of my web applications, and change Browser File Handling from Strict to Permissive. Voila, I no longer need to fuss with the extra steps of opening XML from my Downloads folder.