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.)

Doable

Have you tried Fiddler to examine your headers in both directions ? Also, what error do you get in other browsers ? I often find Firefox or Chrome can give you a much more verbose error message that fixes a problem that IE wont tell you about! – Adenaadenauer

Those headers are from Fiddler. Great little tool. Firefox and Chrome have no problem, and users with the problem don't have it in other browsers. – Doable

You probably should not send the VARY header, as that doesn't do anything useful in your scenario and will prevent certain IE versions (e.g. IE8) from caching the file. That in turn can break downloads, see e.g. blogs.msdn.com/b/ieinternals/archive/2009/10/03/… – Idolatry

I'm trying to figure out where the Vary header is coming from, as I'm never setting it myself. I assume Apache is doing it, but I can't find where. – Doable

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.

Endodontist

I'm trying to track down where the Vary header is coming from. I assume Apache is adding it somewhere down the line. Can you clarify what you mean by "the download doesn't have a file name"? I specify a file name in the Content-Disposition header. Is there somewhere else I should check? – Doable

I added a timestamp to the filename and put in an Apache rule to remove the Vary header. Users with the problem are reporting that it works now. For posterity, the Apache directive I used is: SetEnvIfNoCase Request_URI <url> no-gzip dont-vary – Doable

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.

Wadesworth

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....

Elbertine