Edgewall Software

Opened 17 years ago

Closed 6 years ago

#1020 closed defect (fixed)

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

Reported by: aguilr at alum dot rpi dot edu Owned by: Christopher Lenz
Priority: high Milestone: 0.8.1
Component: general Version: 1.0-stable
Severity: normal Keywords:
Cc: skolgan@…, oohlaf@…, edgewall.p3u@… Branch:
Release Notes:
API Changes:
Internal Changes:


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.


Attachments (0)

Change History (23)

comment:1 by anonymous, 17 years ago

Cc: trac@… added

Has anyone had a chance to look into this bug?

comment:2 by Jonas Borgström, 17 years ago

Cc: trac@… removed

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.

comment:3 by anonymous, 17 years ago

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.

comment:4 by zoltan.podlovics@…, 17 years ago

Summary: PDF files (maybe all binary files) are not downloadable using Internet ExplorerIt's a well known IE & Acrobat Reader bug

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

comment:5 by zoltan.podlovics@…, 17 years ago

Summary: It's a well known IE & Acrobat Reader bugPDF files (maybe all binary files) are not downloadable using Internet Explorer

Summary changed back to the original.

comment:6 by skolgan@…, 17 years ago

Cc: skolgan@… added

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 :(

comment:7 by pkou at ua.fm, 17 years ago

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

comment:8 by Christopher Lenz, 17 years ago

Milestone: 0.8.1
Resolution: fixed
Status: newclosed

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

comment:9 by oohlaf@…, 17 years ago

Cc: oohlaf@… added
Resolution: fixed
Status: closedreopened

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

comment:10 by oohlaf@…, 17 years ago

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.

comment:11 by Christopher Lenz, 17 years ago


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.

comment:12 by anonymous, 17 years ago

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

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.

comment:13 by Christopher Lenz, 17 years ago

Owner: changed from Jonas Borgström to Christopher Lenz
Status: reopenednew

comment:14 by Christopher Lenz, 17 years ago

Resolution: fixed
Status: newclosed

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

in reply to:  16 comment:17 by edgewall @…, 16 years ago


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

Last edited 7 years ago by Jun Omae (previous) (diff)

comment:18 by edgewall.p3u@…, 10 years ago

Resolution: fixed
Status: closedreopened

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

comment:19 by edgewall.p3u@…, 10 years ago

Cc: edgewall.p3u@… added

comment:20 by edgewall.p3u@…, 10 years ago


comment:21 by edgewall.p3u@…, 10 years ago

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.

comment:22 by Christian Boos, 10 years ago

Can you try each of these links?

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

comment:23 by edgewall.p3u@…, 10 years ago

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.

comment:24 by figaro, 7 years ago

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.

comment:25 by Ryan J Ollos, 6 years ago

Resolution: fixed
Status: reopenedclosed

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.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Christopher Lenz.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christopher Lenz to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.