File download results in "IE was not able to open this internet site"

Question

I'm at a loss for this one. I've looked all over and there seem to be a lot of solutions, but they aren't working for me. I've got a CGI::Application app generating a MS Excel spreadsheet with Spreadsheet::WriteExcel. This worked fine for quite some time until our live server had a hardware failure a couple weeks ago. We used the outage as an excuse to upgrade to Windows Server 2008 (from 2003) and Apache 2.2.17 (from 2.2.11). Now, I'm getting sporadic (but too frequent to ignore) complaints from customers receiving this error when trying to download spreadsheets:

Internet Explorer cannot download [url] from [site].
Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.

I have tried IE 7-8 on XP, Vista, and 7 and have been unable to reproduce this error locally. The users that have the problem have it every time, not randomly. All complaints have come from IE users, mostly on IE8.

After reading a couple posts about the error message, I added the -expires header to no avail. (With no way to test this directly, I've had to implement a fix and wait a day or so to see if people stop complaining ._.)

sub export_spreadsheet {
   my $self = shift;
   binmode STDOUT;

   my $str;
   open my $fh, '>', \$str;
   my $workbook = Spreadsheet::WriteExcel->new($fh);
   # words words words
   $workbook->close;
   close $fh;

   $self->header_add(-type => 'application/vnd.ms-excel',
                     -expires => '+1d',
                     -attachment => 'export.xls');
   return $str;
}  

The headers for the request look normal. These were collected on my local machine, mind you.

HTTP/1.1 200 OK
Date: Tue, 31 May 2011 22:23:17 GMT
Server: Apache/2.2.17 (Win32) mod_ssl/2.2.17 OpenSSL/0.9.8o mod_perl/2.0.4-dev Perl/v5.10.1
Expires: Wed, 01 Jun 2011 22:23:18 GMT
Content-Disposition: attachment; filename="export.xls"
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100
Content-Type: application/vnd.ms-excel
Content-Length: 18944
Accept-Ranges: none
Proxy-Connection: Keep-Alive

The current workaround we give to customers (unable or unwilling to switch to an alternate browser) with the issue is to switch to SSL by putting typing the https themselves. The SSL download works fine for the ones who have tried it and gotten back to us. Speculation: Could it be a downstream proxy messing with our headers? Could that be why it works in SSL and errors in plain HTTP? (The server upgrade would be an unfortunate coincidence in this case.)

Answer 1

According to http://support.microsoft.com/kb/316431 IE can't deal with some situations where a file isn't cached but it's then opened by some external process. It's not the exact same case, but as EricLaw mentioned in a comment, it might have something to do with the Vary heading and the fact that the download doesn't have a file name.

I'd remove that header and give it a filename and IE should be able to save the file to disk so that it can be opened by Excel.

Answer 2

IF the system as a whole is working and that only the downloads are sporadically failing, then you could also try giving the file name a dynamic name.

Answer 3

We had a similar case recently, and after checking a whole bunch of useless answers on the MS site, I came across an interesting blog post that shed some more light on the issue, mainly about headers that prevent caching (including the Vary header that ended up solving the OP's problem, +1).

However, IE throws this misleading exception in a number of other cases as well, so I thought I'd add this here in case it's useful to someone else encountering the same problem. In our case, it turned out that the author of the JSP that generated the (Excel) file and sent it to the response had forgotten to make sure that no whitespace should preceed the file contents in the response.

In the case of Java/JSP files (I'm sure you can adapt the same principle to other languages), problems occur when you have something innocent-looking like:

<%@ page contentType="text/html; charset="iso-8859-1" pageEncoding="iso-8859-1" errorPage="" language="java" session="true" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
[and so on]

i.e. have the carriage returns as part of the JSP directives instead of between them before you generate the file contents and send them to the response, because the carriage return between such lines is whitespace that manages to throw a virtual spanner in IE's delicate machinery (normal browsers seem to handle this just fine). If you instead format your code like this:

<%@ page contentType="text/html; charset="iso-8859-1" pageEncoding="iso-8859-1" errorPage="" language="java" session="true"
%><%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c"
%>[and so on]

then you should be ok. I'm sure most web devs have come across similar issues, but in my case it had been a while and I had to look over the JSP a few times before noticing that one line wasn't doing that....