Last modified: 2014-11-16 07:31:56 UTC
If your wiki is configured to use img_auth.php for access control, and you have documents like PDFs, Microsoft Word, PowerPoint, or Excel uploaded to your wiki, there is some weird interaction that prevents these documents from being opened directly from Internet Explorer's address bar. If you copy/paste the URL to the uploaded document into the address bar and press Enter, it will pop up an error saying it couldn't access the document. (The exact message varies depending on what document type you try to load, and it isn't always consistent. Word will often add an additional popup saying that it died and a log of the error is being produced.) Problem was reproduced on two different wiki servers running MediaWiki 1.13.1. Problem happens with both IE 6.0 on Windows XP and with IE 7 on Vista. Problem does not happen with Firefox. Problem does not happen if you click on a link to get to the exact same URL, such as going to the Image: page first then clicking on that link. Only when the URL is entered in the address bar. Problem does not happen if you put the same document on the server where you can access it without going through img_auth.php. Problem does not happen with normal .txt files and image files, only with document types like PDF and Microsoft document types. Problem is consistent -- happens every time. STEPS TO REPRODUCE: 1. Configure wiki to use img_auth.php for accessing uploads 2. Upload a PDF or Word document 3. Paste the URL of the uploaded document (not the Image: page) into IE and try to access it.
Can you provide some sample file names? Does the issue occur only with Chinese filenames for instance, or also with pure-ASCII names? [IE _should_ be sending URLs as UTF-8 by default so that shouldn't make a difference, but it's good to check these things.]
The filename doesn't matter; it happens with every filename. I just retested with a simple (24K) uploaded Word document titled "Test.doc". It will start a download progress popup, echoing back that it is downloading "Test.doc" and showing 0% progress, but it is immediately overlayed by two more error popups - one from IE saying it couldn't find/access the resource, and one saying that WINWORD.EXE is dying and a log is being generated (don't know where this goes). I assumed there was a known problem with accessing some resources from IE address bar, but couldn't find much in Microsoft's Knowledge Base. Could be related to http://support.microsoft.com/kb/953166, another problem where a page works when clicked as a link but not when typed in the address bar. Or saw another report that similar things happen if expiry HTTP header is set to now or in the past. This reportedly also affects people who wish to upload a document then email its URL to a bunch of others. The links apparently don't work when clicked in Microsoft Outlook either. Work-around for now is to mail the Image: URL instead, requiring two clicks by receiving users.
I finally tracked this down a bit. It is due to the "Vary: Cookie" header in img_auth.php. Due to limitations in its caching engine, IE usually won't cache pages if there is a Vary header. (See http://blogs.msdn.com/ieinternals/archive/2009/06/17/Vary-Header-Prevents-Caching-in-IE.aspx) So a work-around is to remove the "Vary: Cookie" header. Adding an ETag header is also supposed to help. Note that this issue also has a large impact on performance on corporate intranets where Explorer is used a lot, since all images on the page are reloaded every time the page is accessed.
