IIS 5 & IIS 6
IIS won't server xls doc rtf
Last post Nov 24, 2008 03:57 PM by tomkmvp
Nov 21, 2008 02:01 PM|tracing|LINK
Here is the scenario...
Create a virtual directory and place documents in it
rtf, xls, doc, pdf, txt
For fun, turn on directory browsing and go to
files are displayed, you can click to open, click to save, all work
If you click to open in new window, or, click to create shortcut and paste url in new window, ONLY the pdf and txt files are served.
DOC, XLS, RTF will hang, and eventually you get a message that the path xxxx (which is a valid path) can't be found.
Now, if you use Firefox instead of IE, these problems go away...
To further confound and confuse, if I take an XLS and place it on GoDaddy instead of my intranet IIS server, and then type
http://godaddyserver,file.xls it serves the xls file to the same explorer windows on the same machine that can not be served by my intranet IIS.
IT first told me that it was an IE config issue, since FF on the same machine could be served, they said IE was refusing the file.
But that can't be the answer if that same IE that will reject the file CAN get the same file from another IIS 6 server on the internet owned by GoDaddy.
I can't see how it is a permissions issue, since PDF and TXT will be served when the url is pasted in a new window, it is only rft doc and xls that it "cant find".
Any ideas ?
I am suspecting some security patch issue, we have ALWAYS served these file types via http links in the past without issue.
THANKS ! I am done, can't figure it out.
ps using http not https
Nov 21, 2008 02:25 PM|tomkmvp|LINK
It's not an IIS issue since it works from Firefox. Sounds like an Office related issue since it's not a problem with txt or pdf. Do you have WebDAV enabled on your IIS server?
Nov 21, 2008 04:37 PM|tracing|LINK
As I told my IT that gave me same answer as you, it cant be if my internet server can serve if I can use the same browser and get the same doc from another server that is the same type...
And I was right
Here is the fix, I unchecked EXPIRE CONTENT in the http headers tab for the entire web and restarted IIS, and it is now working, I toggled it back and forth and have proven that is the fix.
Now, I have two paths to the same folder, one by virtue that the folder is a subfolder of the web, and I also created a virt dir to the same folder.
If I expire on one and not the other, one will work and one will not, if I reverse them, then it changes and one will and one will not. So it follows the url and if you need to fix it for the subfolder of a web, you have to set it at the web level affecting
the entire web (all the web will be no expire), or, if you need expiry, you set the web to expiry, and create a virt dir to the folder in question that has the office docs, and then set that and no expire and use that url to get to the doc folders not the
So it was the server, and this proves that FireFox has a security issue, because if I do not want people to be served docs by using the security setting MS has designed into office docs, setting expiry to immediate, Firefox users get around that.
Nov 24, 2008 03:57 PM|tomkmvp|LINK