PDF files (maybe all binary files) are not downloadable using Internet Explorer

[aguilr at alum dot rpi dot edu]

When trying to download a binary file, PDF in this case, IE will give the following error:

—- Internet Explorer cannot download …database.pdf?rev=30&format=raw from trac.site.com

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've confirmed this works on IE 5.5 and 6 for Windows. I posted this question on the mailing list. Matt Good mentioned it may be:

• IE trying to be smart but really isn't. It may be possible to trick it by adding "&dummy=something.pdf" to the URL.

I tried that but it didn't work

• IE is expecting the PDF file to be transmitted in it's entirety instead of bit's at a time (streamed?).

Is the python code buffering the entire PDF before it transmits it? If not, that may be the solution.

At the moment this is affecting the way we use Trac because we keep files like ERD documents and other resources for our project in PDF format. All our Windows/IE users are unable to access these documents from the Trac site.

Thanks!

[anonymous]

Has anyone had a chance to look into this bug?

[Jonas Borgström]

I don't have any idea why IE behaves this way. Loading the whole (potentially very large) file into memory before sending it to the browser doesn't sound like something you want your webserver to do. There must be a better way to fix this.

Please don't cc the trac-list directly. Ticket notifications can generate a bit too much traffic. Send an ordinary mail instead, I'm sure someone on the list knows a better way around this IE bug.

[anonymous]

In the past I had a website I mantained showing a similar problem with PDFs. In the end we found that the website in IIS was set to have content expiration set to immediately. Once this was removed, download of PDFs worked fine.

[zoltan.podlovics@…]

It's a well known IE & Acrobat Reader bug. IE will create a temporary file when you try to view or download a PDF file, but before Acrobat Reader takes control IE will _delete_ this file.

Here is the workaround: (you must have these HTTP headers for IE & Acrobat Reader)

Pragma: no-cache
Cache-control: private
Content-type: application/pdf
Content-length: size_in_bytes

Or alternatively you can force the Content-type to application/octet-stream to prevent loading Acrobat Reader.

Regards, Zoltan

[zoltan.podlovics@…]

Summary changed back to the original.

[skolgan@…]

It's also showing up when downloading a .zip files that are in SVN repo… changing svn:mime-type to application/octet-stream doesn't help either :(

[pkou at ua.fm]

Also, the problem is described in Microsoft knowledge base, issue ​KB316431.

[Christopher Lenz]

Should be fixed in [1248], ported to stable in [1249].

[oohlaf@…]

I just ran into this problem again using trac 0.8.1 from Debian and serving PDF files over SSL.

The backport fix in changeset [1249] forgot to remove the pragma: nocache statement (as [1248] also does).

[oohlaf@…]

To clarify:

While I understand that the problem is fixed in the development version, it might be useful information in case it is decided to do another bugfix release 0.8.2.

As I only use the released versions, and not development snapshots. So in the meantime I commented the line out in File.py.

[Christopher Lenz]

Understood. We haven't yet decided (or even discussed) whether there will be another minor release of the 0.8 branch, but this ticket would be a candidate for inclusion.

[anonymous]

Its all files and only an SSL problem. To manually fix it you can edit: File.py and comment out the lines as shown below:

# self.req.send_header('Pragma', 'no-cache')
self.req.send_header('Expires', 'Mon, 26 Jul 1997 05:00:00 GMT')
# self.req.send_header('Cache-Control',
#                      'no-store, no-cache, must-revalidate, max-age=0')
# self.req.send_header('Cache-Control', 'post-check=0, pre-check=0')
self.req.end_headers()

Then you use the py_compile script to compile the byte-code object files and trac should be fixed. A little annoying but not too bad.

[Christopher Lenz]

Fixed in the 0.8-stable branch in [1479].

[edgewall @…]

Greetings,

Many thanks for this artical - it helped me to get to my solution. In my case, I'm running Apache and serving a dynamically generated PDF file that downloads fine in all popular browsers but IE. My working solution was to add the following lines prior to my other header outputs:

		/**
		 * The following Pragma and Cache-Control lines are necessary 
		 * as the overcome an issue that IE has in some server configurations 
		 * when the no-cach header is sent. The two lines override these 
		 * headers, allowing IE to proceed. When not turned on, the error IE 
		 * provides is: 
		 *   Internet Explorer cannot download <item URL here instead of item file name> from <domain>.  
		 *   
		 *   Internet Explorer was not able to open this Internet site. The requested site is either 
		 *   unavailable or cannot be found. Please try again later.
		 */
		header("Pragma: public");
		header("Cache-Control: max-age=0");

Sean P. O. MacCath-Moran www.emanaton.com

[edgewall.p3u@…]

Looks like this very problem is present once again in Trac 1.0 :(

[edgewall.p3u@…]

Update: I found out that specifying the export path using https://trac.example.org/export/767/trunk/doc.pdf will work but https://trac.example.org/export/HEAD/trunk/doc.pdf won't. So something in the revision path look-up procedure seems to throw off IE but not any other decent browser.

[Christian Boos]

Can you try each of these links?

• ​http://trac.edgewall.org/demo-1.0/export/8089/trunk/trac/htdocs/trac_banner.png
• ​http://trac.edgewall.org/demo-1.0/export/HEAD/trunk/trac/htdocs/trac_banner.png
• ​http://trac.edgewall.org/demo-1.0/browser/trunk/trac/htdocs/trac_banner.png?format=raw
• ​http://trac.edgewall.org/demo-1.0/raw-attachment/wiki/Foo/Bar/576691_10150960828864324_365277918_n.jpg
• ​http://trac.edgewall.org/demo-1.0/attachment/wiki/Foo/Bar/576691_10150960828864324_365277918_n.jpg?format=raw

With your version of IE (which one, btw?).

For me (IE9), all of these links work as expected. If they also do work for you, I'm afraid the problem has more to do with your local setup and installation of Trac. Well, in fact even if some links don't work for you, the problem might be due to some cache proxies in your local network. I remember we have an issue open related to squid (#9650, which itself links to #6367, have a look at that one as well).

[edgewall.p3u@…]

OK in my case there is no proxy involved. I tried all the links and the work fine with IE 8 (sorry should have mentioned that before). I'm not surprised that they work since they are not served via https. This is where the problem occurs. I also looked at the other two tickets but it does not be that problem.

My guess is that there happens something funny with the reply one gets from Trac when "HEAD" is requested instead of an explicit revision.

[figaro]

With the global browser share of IE as a whole currently below 20% and declining and a workaround in place, I suggest we downgrade this issue to wontfix.

[Ryan J Ollos]

I'm closing this, but not specifically because it's an IE problem. The ticket was resolved in an earlier release of Trac and there may or may not be a related issue. If there is a related issue, a new ticket should be created.

If someone can reproduce the issue in IE9 or later, and is willing to work through debugging the issue, then feel free to create a new ticket with a reference back to this ticket. There's no sense leaving this ticket open forever if we don't have concrete steps to reproduce the issue and confirmation that the issue is seen in IE9 or later. Also, it's generally not a good idea to re-open a ticket that was resolved in an earlier release.