Internet Explorer Not Opening Attachments Correctly

Same problem here.

I am using CVS and PHP 4.4.0. The bug is still there. I don't understand why IE acts this way. Maybe download resuming should be implemented?

Guess this should be Drupal:file system not upload (simple).

Oops, version should be cvs.

Maybe a seperate issue should be created for this, but I am bothered by two more things. One of those actually belong to to the upload module.

Firstly, files that have a space in the filename will have corrupted filenames when downloaded, e.g. the file "bulletin 30 september.doc" will be downloaded as "bulletin". Especially in IE this is a problem because Windows does not like extension-less files. I don't know what causes this problem, since upload.module implements hook_file_download correctly.

Secondly, I think Drupal should get more intuitive private downloading. I'm thinking about things like support for resuming downloads etc. Resumable downloads might actually fix PDF-downloading probs because the Adobe Reader browser plugin might use this, I'm not sure.

I have found the cause of the IE download errors. It is caused by the following headers, which are set when caching is enabled in drupal_page_header:

header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");

As a quick fix, I put these lines in:

if (!preg_match('@system/files@iS', $_SERVER['REQUEST_URI'])) { }

But, as I said this is a quick and dirty fix.

Sounds like and IE not handling cache headers properly.. I'm tempted to make this a wont fix or feature request.

Whether its IE's fault or not, its still the mostly used browser on this planet, unfortunately. So we should somehow try to find a good workaround.

Can anyone reproduce this issue in 4.7? I can't, but I haven't tested very thoroughly and I wouldn't know what could've solved it.

Confirmed: I am experiencing this error in 4.7.

I didn't see this issue thread when I searched, and I opened up a new one at:

http://drupal.org/node/61528 (now marked duplicate & pointing here).

OK, then I'll try harder to reproduce this myself and solve this problem.

A workaround for now: in the context menu (right mouse button) for a download link use Save Target As.

I have run into this problem as well and tested on multiple machines with IE just to be absolutely sure.

Can this be upgraded to a critical bug? This is a core feature that breaks in IE (however crappy is still the dominantly used browser) and thereby breaks for a great many of our users.

.

.

if the bug exists in cvs, don't downgrade to a lower version. The fix, if someone provides a patch, will be backported.

It would be great if someone could investigate the headers being sent by Drupal. At a local website, a quick test showed that Content-Length is 0 for private files. Maybe that is the culprit? If not, it still sounds like a bug. Maybe a good starting point to investigate this further.

Here is a working solution that needs to be rolled into a patch: http://drupal.org/node/18179. These are the missing headers, it seems:

'Expires: 0', 'Pragma: cache', 'Cache-Control: private'

Going to mark this critical because it affects all IE users.

patch in attachment

The patch in #19 was made against an old install and doesn't work against HEAD.

Re-rolled the patch for HEAD.

I tested this out and it worked a treat (on my test setup, both IE and FF failed to open directly without a save to disk step first). This patch fixed both cases. I'd set it to RTBC but I had to re-roll the patch.

regards,
--AjK

I cannot test IE, because I don't have it. I do not see any adverse effect with either Konqueror of Firefox.
It is already said to work with IE (both in this issue, and in the above mentioned thread).

The patch in #19 was for cvs DRUPAL-4-7 branch

Patch looks good. Small nit: should we put all headers below each other? All the current headers are on a separate line now. Are all 3 headers required to make it work, or is there one header that does the trick?

+1 for the patch, great that this problem has finally been solved.

Dries: my testing shows that the Cache-Control: private header seems to do the trick, though because of IE's unpredictability I would just add them all. This patch doesn't increase the number of headers sent to the client, because it replaces/overwrites the headers set in drupal_page_header (which are more, actually).

Committed. Should be packported to DRUPAL-4-7.

applied patch from #19 to 4.7

I am still having problem opening PDFs on v. 4.7. I've added the code to upload.module, but no luck. I've been trying to get this to work for the last two hours at least. Please advise.

I am still experiencing this problem using drupal 4.7.4 upload module is $Id: upload.module,v 1.100.2.9 2006/09/26 14:16:38 killes Exp $

to see an example see http://www.dibbletree.com/filemanager/active?fid=71

the upload module has the patch in it

can anyone suggest a way to fix this

Tkgafs

I just clicked your link, clickon open on the .pdf file and the file opened in IE7 and FF 2.0.

I'm not sure I see where the problem is with this issue.

Sorry should have said I'm using IE 6 and firexox 1.0.7 firefox works fine but IE 6 does not

tkgafs

Tkgafs probably meant to mark this 'active' since he's still experiencing problems with IE6 and Drupal 4.7.4 upload module.

I'm actually expeiriencing this too with directly opening PDF files in IE6. Saving them first and then opening is working however. I'll be investigating this further as I think it may be partly a server configuration issue as I'm only experiencing this bug on one server.

I've looked into my case of this and that installation hadn't been truly updated to the latest Drupal 4.7. After an update, file downloads work great in IE6. Marking closed.

I'm getting the same thing. Updating to latest 4.7 from CVS didn't seem to help anything.

I'm using Private files; don't know if that's contributing to this or not.

@webchick: Can you do a clean 4.7 install on this same server, but set files as public and see if IE6 is still having issues downloading files? Then we could narrow this sucker down.

Sure. Fortunately, I'm able to reproduce this locally on XAMPP LIte for Windows Version 1.5.4a

Shoot. I can't reproduce in a clean 4.7 install. :( That means it's something with our code base. Sigh. :P

No one has a problem with public file access. Try testing with file access set to private. On my Mac, setting access to private causes this problem in Safari, Firefox, and Internet Explorer. For some reason RealPlayer does not suffer this problem.

I tried both public and private on a clean DRUPAL-4-7 CVS checkout and can't reproduce. Can you, Darren? And if so, could you give more info on the server configuration perhaps?

I'll try again. If the problem is fixed, there should at least be an upgrade script to fix existing sites.

This issue was originally about upload_file_download() in upload.module not sending the correct headers and IE6 (AFAIK) was the only browser that wouldn't handle an incomplete list of headers gracefully.

Let's open another issue if you're having problems with private files in ALL browsers, as this was just an IE6 bug that has since been fixed by adding these headers in upload_file_download():

+ 'Expires: 0', 'Pragma: cache', 'Cache-Control: private'

I created a new database, checked a fresh copy of Drupal 4.7 out of CVS, turned on the private files setting, and enabled the upload module. Then I created a story, attached a PDF file, and clicked on the attachment link. The file would not open in the browser. I tried the same with an up-to-date copy of Drupal 5.0 from CVS and got the same result.

I'm using MySQL 5.0.21 and Apache/1.3.33 (Darwin) PHP/4.4.1 on Mac OS X 10.4.8.

Good point, RobRoy. I'm going to re-open issue 61528, which was incorrectly tagged as a duplicate of this one (see comment #11).

Patch http://drupal.org/node/61528 has been committed now. Not sure if this was good or bad. ;-)

As I mentioned in the other issue, that patch will not affect this issue.

I checked the history before committing and a Content-disposition header has been there since the beginning of upload module.

Confirmed that this is still happening:
Lamp install of 4.7.4 on PHP4.3.9
Clicking on Private files present the user with 3 options: Open, Save and Cancel. Save and Cancel work fine. However, Open seems to corrupt the local copy of the downloaded file. The error message is "The path or filename c:\documents and settings\me\local setttings\Temporary Internet Files\Content.IE5\CV8RUHSR\myppt_file.ppt[1] is invalid. Please check that the path and the filename are correct."

This occurs on several IE6 XP workstations. It DOES NOT occur on Firefox on either Windows or Linux. Also, IE7 works fine. It occurs with PDF and PPT files.

This came after the release of 4.7.4. Please download the latest 4.7.x development snapshot and re-open if you experience this problem using that.

http://drupal.org/drupal-4.7.x-dev

This problem is still occuring on the latest 4.7.x-dev. When the user clicks *open* instead of *Save* or *Cancel*, the download occurs, the application opens (MS Powerpoint or Adobe Reader) and then the error appears. It says that it can't find the file and, in the case of a ppt file, the location of the file is in the Temporary Internet Files Folder.

Here are the specfic conditions:
IE6 on XP Sp2
MS Office Installed

Firefox on Linux and Windows works fine.

Can you test this on a fresh copy of 5.x-dev with no contrib modules? Let's see if the problem exists there first.

Then, can you confirm this is on 4.7.x-dev with NO contrib modules installed? Thanks.

Also, does your upload_file_download() function in upload.module have this line?

'Expires: 0', 'Pragma: cache', 'Cache-Control: private'

Can you do a var_dump of those headers before the return and paste that here?

I just tested 4.7.x-dev and could open a private PDF on IE6 for Win XP with no troubles. Can anyone else reproduce this in 4.7.x-dev or 5.x-dev? If you can, please to a var_dump of your headers in upload_file_download().

Brand new install of drupal-5.0-beta2.

I enabled file uploads, created a page and attached a pdf file to it.

Clicking on the link DID NOT present me with an option to OPEN,SAVE or CANCEL. Instead, 2 copies of Adobe 7 Reader opened with the PDF in both. Needless to say, this is entirely different behavior than that of the original bug. Additionally, the URL became the URL of the document. I tested this with 2 different PDF files from entirely separate sources.

The client system was the same system experiencing the errors as before.

OK, I have tried to run var_dump to get the headers without success.

I even tried syslog(LOG_WARNING,"test") at the top of the function and I never got any output in my system logs!!! That says to me that the function, upload_file_download(), isn't being called. I could be mistaken here, but like I said. I saw nothing in my server logs using the SYSLOG statement at the top of the upload.module after that function is declared.

Additionally, I checked my 4.7.4 file for the "Expires: 0', 'Pragma: cache', 'Cache-Control: private'" and YES, it is there.

Try using http://web-sniffer.net/ to get your header information. I can check for you if you give me the URL.

I can confirm the double window behavior in 5.x-dev which I reported in http://drupal.org/node/61528#comment-158819, but at least it works in D5.

This patch matches the headers in D5, which will hopefully get PDFs downloading correctly in 4.7-dev (please let me know davea). This will get it working in IE6, until someone figures out that double window issue (should be another issue) which is really no big deal.

Headers in D5

        return array(
          'Content-Type: '. $type .'; name='. $name,
          'Content-Length: '. $file->filesize,
          'Cache-Control: private'
        );

Headers in D4

        return array(
          'Content-Type: '. $type .'; name='. $name,
          'Content-Length: '. $file->filesize,
          'Content-Disposition: '. $disposition .'; filename='. $name,
	  'Expires: 0', 'Pragma: cache', 'Cache-Control: private'
        );

Just to note, opening private PDFs in IE6 on current 4.7.x-dev still works for me, but anyone experiencing issues should test this and see if it fixes it for you.

(I am glad I had my coffee this morning)

THIS IS NOT AN ISSUE WITH upload.module.

After not seeing my SYSLOG entry appear, I began digging and found that I had the filemanager.module,the attachment.module and upload.module installed and enabled. I disabled the upload.module, put my SYSLOG entry in filemanager.module. Sure enough, the headers in filemanager.module are the cause.

However, you may find my research helpful. I tested this on the following setups and got the same DESIRED behavior:

IE6/W2k/Office2k3
IE6/XP/no-office
Firefox/Linux
Firefox/XP/no-office

For the sake of those that care, here are the headers that I got to work in IE6 with Office 2003 installed:

    'Content-Type: '. $file->mimetype .'; name='. $name,
    'Content-Length: '. $file->size,
    'Content-transfer-encoding: 8bit',
    'Content-disposition: attachment; filename="'. $file->filename .'"',
    'Expires: 0', 'Pragma: cache', 'Cache-Control: private'

And here are some links:
http://support.microsoft.com/default.aspx?scid=kb;en-us;316431
http://bugs.php.net/bug.php?id=16173
http://pkp.sfu.ca/support/forum/viewtopic.php?p=359&sid=4516e6d325c613c7...
http://forum.springframework.org/showthread.php?t=24466

Sorry to trouble you all!

I will post the problem at http://drupal.org/node/93787

Have a great day!