Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
After upgrading from 5.1 to 5.2, IE can no longer download/open files on the site. Mozilla, Safari, Opera all work. When I right-click on the file and go to save-as I get "The file could not be written to the cache". This has cropped up only since the upgrade to 5.2 from 5.1. The site is only accessible via SSL and the file system is "private".
running on Gentoo Linux, Apache-2.2.4, PHP-5.2.2, Drupal-5.2
Comment | File | Size | Author |
---|---|---|---|
#43 | ie_cannot_dl_over_ssl-163445-43.d6.patch | 959 bytes | pescetti |
#42 | ie_cannot_dl_over_ssl-163445-42.d6.patch | 908 bytes | greg.1.anderson |
#35 | ie-private-downloads-over-ssl-163445-35.patch | 953 bytes | mlsamuelson |
#24 | drupal5-uploadmodule-msie-fix-if-https.patch | 1.35 KB | webengr |
#20 | drupal5-uploadmodule-patch-msie-ssl.patch | 1.17 KB | webengr |
Comments
Comment #1
whelm CreditAttribution: whelm commentedI've dropped back to 5.1 and the issue is gone.
Comment #2
whelm CreditAttribution: whelm commentedThis problem is still present in 5.3
Comment #3
joep.hendrix CreditAttribution: joep.hendrix commentedI can confirm that this problem is still in D5.3.
With the a certain advanced setting this can be avoided (see attachment).
This setting is not standard so please consider this as a bug.
Joep
Comment #4
webengr CreditAttribution: webengr commentedI am also seeing this issue for a website that is setup to be private andl https, and not viewable by annoymous,
and was upgraded from 4.X to version 5.7
So this is still an issue ass of later April 2008
Comment #5
webengr CreditAttribution: webengr commentedI am also seeing this issue for a website that is setup to be private andl https, and not viewable by annoymous,
and was upgraded from 4.X to version 5.7
So this is still an issue ass of later April 2008
Comment #6
webengr CreditAttribution: webengr commentedThis is a bug that has not been resolved for version 5.7 so I put it up as a bug here for that version:
http://drupal.org/node/254939
Comment #7
alpritt CreditAttribution: alpritt commentedI've marked the other issue as duplicate of this one.
To clarify: this is working fine in 5.1 but broken in 5.2 and later, yes?
Is it an issue in HEAD? What about on a fresh install?
Comment #8
webengr CreditAttribution: webengr commentedI setup three FRESH INSTALL websites using the dev branch for versions 5, 6, 7
NOTE TOOK WEBSITES DOWN, MAY2009, IF NEED TEST WEBSITES BACKUP LET ME KNOW
short answer YES BUG EXISTS for head of 5 and 6, could not test 7 because of upload module error in the dev.
NOTE I tested for 5.x dev that the bug is only for PRIVATE, not PUBLIC download method.
THE ssl cert is self signed, so you will have to accept that to see sites...
-----------------
I just tested http://drupal.org/drupal-5.x-dev 2008-Jun-07
and for https with PRIVATE upload, the MS IE bug is still rampant.
HERE IS THE SITE AND AN ACCOUNT TO TEST. I made notes on the page and set user to view and download only.
(please others, don't change the test account user settings... so we can get this fixed)
http://64.129.81.185/ (redirects to https)
or
https://64.129.81.185/
user: test
password: abc123
-------------
I am going back and doing 6.x-dev and 7.x-dev now, ... DONE
--------------
FOR 6.x DEV 2008-Jun-09
http://64.129.81.186/ (redirects to https)
or
https://64.129.81.186/
user: test
password: abc123
YES THE BUG EXISTS for MSIE 6
----------------------------
FOR 7.x DEV 2008-Jun-11
http://64.129.81.187/ (redirects to https)
or
https://64.129.81.187/
user: test
password: abc123
COULD NOT TEST DUE TO DEV ERROR
notice: Undefined variable: file in ***/drupal-7.x-dev/modules/upload/upload.module on line 151.
Comment #9
webengr CreditAttribution: webengr commentedBTW, problem still exists even on dev.
since the other theads for other versions are not suppose to be used,
could you change the title of this thread to say since 5.2, both 5.x and 6.x problem ?
Comment #10
bander2 CreditAttribution: bander2 commentedFYI, I had this problem as well and WebFM module worked for me as a workaround. Saving files still doesn't work, but I am dealing with mostly pdf's that I want people to just open anyway.
I am still trying to fix the problem, and I think it is related to an overall problem I am having where file downloads don't get completely downloaded. For me I think I have tracked it to a problem with max_execution_time in php.ini. I don't know if this is how it is supposed to work, but, it seems that a script is executing the entire time the file is downloaded (this is a problem for my > 100MB files). That mean't that files were downloaded some and then timed out leaving you with a file that IE thinks is corrupt. I increased max_execution_time and my early tests indicate that this fixes the problem.
So, maybe my issue is unrelated> I am running IIS 6 with SSL and WebFM module (workaround for private file system) on Drupal 5.7.
Comment #11
webengr CreditAttribution: webengr commentedI appreciate the input, but I don't think it is related to the size of the file, and it did work before on earlier versions of 5.x,
some change to the code for 6.x and later 5.x caused https private download to have errors... unless you disable the ssl setting...
so don't think it is an apache thing.
Comment #12
nerdoc CreditAttribution: nerdoc commentedI can confirm this, using drupal 6.6 private download method and https.
Comment #13
drumming_cat CreditAttribution: drumming_cat commentedHi,
I've encountered this problem now, too, after having set up SSL for our Drupal 5.15 site.
Files are accessible through private download method (which works fine without SSL).
When I try to open files in IE 6 and IE 7 the error message is:
Internet Explorer cannot download filename from sitename.
Internet Explorer was unable to open this Internet site. The requested site is either unavailable or cannot be found. Pleast try again later.
The same documents can be opened without a problem in Safari and Firefox.
Could you please let me know if there will any attempts to fix this bug?
SSL is important for my client as is the use of IE.
Drupal 5.15
Apache 2.2.3
PHP 5.1.6
MySQL 5.0.45
Thanks and cheers,
Natascha
Comment #14
drumming_cat CreditAttribution: drumming_cat commentedI found the following solution on the web which solved the issue for my installation without any further issues (so far):
I added a Cache Control entry in the file_download section that controls all my file downloads ($type and $size obviously being set dynamically in my script):
return array('Content-Type: '.$type, 'Content-Length: '.$size, 'Content-Transfer-Encoding: binary', 'Cache-Control: max-age=60, must-revalidate');
Alternatively (but not realistic in the environment that I work in), activate the setting Don't save encrypted pages to disk in Internet Explorer, menu Tools – Options – Advanced.
Comment #15
webengr CreditAttribution: webengr commentedApologies, but we may need some clarification on your fix,
Are you referring to ./includes/file.inc
and function file_download()
And if so, is the return you are suggesting simply placed before the closing curly brace for the function?
BTW -- this problem still exists for IE8 I have been told.
AND POSSIBLY AOL
Comment #16
bander2 CreditAttribution: bander2 commentedwebengr, the function drumming_cat is refering to is in modules>upload>upload.module. there is a return array already there that is returning the headers. you just need to add to what is already there. I am away from my drupal install so hopefully that was specific enough. if not let me know if you still need help because i know how frustrating this problem can be, and i can give you more specifics.
Comment #17
johnhanley CreditAttribution: johnhanley commentedThis doesn't have anything to do with the file system directly, but I recently encountered the "Internet Explorer cannot download..." problem while attempting to implement the public/private download solution described in this article. The solution provided by drumming_cat worked perfectly.
I prefer dogs over cats, but props to this kitty.
Comment #18
webengr CreditAttribution: webengr commentedI have hesitated to elevate this bug, but it would be nice to fix this on 5, 6 and beta 7.
every time we do an update, this work around will get removed because it is a core module.?
can we make a patch and have the core developers look it over and get it into the core for 5,6, and 7,
since this module is core?
and get the patch to work against which function... returning array... that is messing up the https?
and looking in the upload module, as expected, several functions...
Comment #19
johnhanley CreditAttribution: johnhanley commentedI agree this is a problem, but use hook_file_download() to add the needed attributes.
Comment #20
webengr CreditAttribution: webengr commentedOKAY per promise, a patch is attached, the patch is for drupal 5, and includes comments for the developers to review.
Thank you for the above drupal users finding that it was a MSIE cache control problem for ssl connections.
I found the Microsoft web page explaining that MSIE has to prevent caching for SSL download:
http://support.microsoft.com/kb/815313
And here is the w3 page explaining Cache-Control:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
So yes on the upload module, ./modules/upload/upload.module
for drupal 5 around line 261, function upload_file_download($file)
the return array needed additional information to suggest to microsoft browsers not to store cache.
The Microsoft website suggested for SSL: 'Cache-Control: no-store',
Above what was recommended was 'Cache-Control: max-age=60, must-revalidate'
I tried 'Cache-Control: no-store', that worked
I tried 'Cache-Control:max-age=60', that worked
I tried 'Cache-Control:must-revalidate', that worked
I tried 'Cache-Control:max-age=60, must-revalidate', and that worked also for drupal 5 with MSIE https.
Since the latter was suggested above, and the upload module is used by non-ssl downloads,
and perhaps allowing the abilitity to store for cache may be better that no-store, I went with what
was above suggested in this forum topic.
SO here is what the function looked like after patching:
NOW we need others to bang on this and get the core developers to implement if satisfied!
Comment #21
webengr CreditAttribution: webengr commentedComment #22
webengr CreditAttribution: webengr commentedComment #23
webengr CreditAttribution: webengr commentedI set the version to the latest, since that is what I am using and the bug is still present, and set the component to upload.module since that is what was discovered as having the bug.
After thinking some more, my question to the users, which variation of cache control would be best?
Maybe the Microsoft page was correct and we should use "no-store" instead of "must-revalidate" or "max-age"
MAYBE somehow the upload module should determine if HTTPS then IF it is https use the no-store in the return array, but don't use the no-store in the return array if it is http?
how could that be done elegantly?
maybe
http://www.wallpaperama.com/forums/how-to-detect-if-url-is-secured-ssl-w...
have php use $_SERVER['HTTPS'] for the conditional and decide return array with that?
BTW #2
after reading the microsoft knowledge base articles and version 5, 6, 7 and 8 of IE problems
I am still not sure which combination of 'no-store' 'no-cache' or whatever Cache-Control would be best.
Do we have any readers that are truly wizards at understanding the cache-control settings and
how best to optimize for MSIE and Firerox and others?
I do think now that part of the answer is that the function needs to return a different array if https than http and most the other posts elswhere have not mentioned this approach....
Comment #24
webengr CreditAttribution: webengr commentedHere is the drupal 5 patch using the value of $_SERVER['HTTPS'] to add to the return array 'Cache-Control: no-store' if HTTPS is on.
QUESTION:
For a SSL connection the browser should not store cache? And most likely Firefox and others just ignore that
the server did not tell them to not store the cache?
If all SSL downloads should not be cached by browsers, which I think is so, then the drupal module should use 'no-store' not max-age nor re-validate cache when doing an SSL download - correct?
Comment #25
Damien Tournoud CreditAttribution: Damien Tournoud commentedLet's see:
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
Cache-Control: store, no-cache, must-revalidate, post-check=0, pre-check=0
Note that the
store
directive doesn't exist, and is causing issues studied in #197786: Some servers / browsers will cache pages even when header Cache-control: no-cache is set.Supposing that store is the issue, I'm bumping that to D6. Can someone please test and confirm that removing the
store
directive solves the issue in affected versions of Internet Explorer?Comment #26
izmeez CreditAttribution: izmeez commentedsubscribing, Izzy
Comment #27
jerome@drupal.org CreditAttribution: jerome@drupal.org commentedhi,
I have a similar issue but with HTTP (no HTTPS): downloaded zip files with Internet Explorer 7 and 8 (no problem with firefox, opera and chrome) have an incorrect file size and they appear as corrupted.
I use Drupal 6.13 with the public download method.
I try with "no-store" configuration in bootstrap.inc but it doesn't solve my issue.
Do you have any fix for that?
bye
Jerome
Comment #28
jerome@drupal.org CreditAttribution: jerome@drupal.org commentedhi,
I have a similar issue but with HTTP (no HTTPS): downloaded zip files with Internet Explorer 7 and 8 (no problem with firefox, opera and chrome) have an incorrect file size and they appear as corrupted.
I use Drupal 6.13 with the public download method.
I try with "no-store" configuration in bootstrap.inc but it doesn't solve my issue.
Do you have any fix for that?
bye
Jerome
Comment #29
xamox CreditAttribution: xamox commentedI am on drupal 6 and using no-store worked for me.
Make sure you clear all your cache after you do this.
Comment #30
bigdave CreditAttribution: bigdave commentedComment #31
mrfelton CreditAttribution: mrfelton commentedSubscribing.
Comment #32
qianbc2007 CreditAttribution: qianbc2007 commentedI just got the information from PHP.net,the code is working on IE 7.0 under https ,the header information should like :
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Cache-Control: private",false);
Comment #33
bigdave CreditAttribution: bigdave commentedStill happening in 6.15
Comment #34
dakotaryan CreditAttribution: dakotaryan commentedConfirm still happening in 6.13. Also confirm that adding the following headers definitely solved the problem in IE7 and 8, using a private file system, auth user, and no SSL, through IMCE:
Content-Disposition: attachment
Cache-Control: cache, store
I made the change in the IMCE module function that handles files downloads, but I imagine you may be able to set these headers elsewhere...
Cheers, Dakota
Comment #35
mlsamuelson CreditAttribution: mlsamuelson commentedThis issue (unable to do private file downloads in IE over SSL) has a patch for HEAD over at http://drupal.org/node/181036.
The patch, relevant for Drupal 6 is attached here. Needs review.
Comment #36
dilvish CreditAttribution: dilvish commentedworks well, 6.15 and 6.16 install bases on CentOS, using SSL. Tested with IE 6, 7, and 8.
Comment #37
heyqule CreditAttribution: heyqule commentedmlsamuelson's patch works well on my 6.15
Comment #38
greg.1.anderson CreditAttribution: greg.1.anderson commentedThis bug persists in ie8, and the workaround in #3 is not effective.
The patch in #35 works perfectly in 6.16. any chance we can commit this, or does it have to go in d7 first?
Comment #39
Gábor HojtsyLet's get committed to Drupal 7 first as with our normal procedures.
Comment #40
greg.1.anderson CreditAttribution: greg.1.anderson commentedThe patch in #35 is for 6.x; there is already a patch ported for d7 at #181036: cannot download from https using IE.
Changing the status back; don't want anyone to spend time porting something that's already been ported. Apologies if I get this wrong... but marking this as 'postponed' (pending commit of #181036).
Comment #41
Damien Tournoud CreditAttribution: Damien Tournoud commentedSo this is a duplicate of #181036: cannot download from https using IE. I reviewed the patch there.
Comment #42
greg.1.anderson CreditAttribution: greg.1.anderson commentedHere is an update of the d6 patch, tested.
Comment #43
pescetti CreditAttribution: pescetti commentedI tested the patch in #42 with Open Atrium 1.0-beta7 (which includes Drupal 6.17) and it still had problems.
Before the patch: Firefox worked, IE was completely unable to download files.
After the patch: Both Firefox and IE prompted to download the file, but filename was empty in both cases.
The following modified version of the patch in #42 fixed the problem, even though it can likely be improved further.
Comment #44
webengr CreditAttribution: webengr commentedwonder if this will be fixed in drupal 7,
this has been an issue for years
Comment #45
izmeez CreditAttribution: izmeez commentedI'm not sure if this is the active thread to post to since it is marked "duplicate" as detailed in comment #41
I was puzzled because changing a Drupal 6.x site to private downloads on an ssl site did not give me problems with IE.
Reviewing the posts gave me the answer in comment #29 which says that using "no-store" solves this. This reminded me that the site has the "no-store" hack as described in http://drupal.org/node/197786#comment-1055633 to ensure privileged pages cannot be viewed after logout. I realize there is still a lot of controversy on that solution.
Comment #46
greg.1.anderson CreditAttribution: greg.1.anderson commentedYes, this is being tracked in #181036: cannot download from https using IE, but it has not been committed yet.
Comment #47
mdelahoyde CreditAttribution: mdelahoyde commentedWe've had this problem on our Drupal 6.17 site, which the patch in issue #43 fixed.
Since the thread mentioned in #46 (http://drupal.org/node/181036) seems to be a Drupal 7 thread, meaning the patches aren't applicable for Drupal 6, is it possible to apply the patch in this thread to Drupal 6 going forward?
Comment #48
mdelahoyde CreditAttribution: mdelahoyde commentedTurns out the patch in #43 breaks swfobject embedded flash over https due to the Content-Disposition: attachment header.
I've implemented the patch from #42, which seems to work without fault.
Comment #49
Ron Collins CreditAttribution: Ron Collins commented#42 seems to have solved the problem for me. thanks. i don't this is a duplicate. the other ticket is for d7 afaict. it should probably still get applied to d6 core.
Comment #50
greg.1.anderson CreditAttribution: greg.1.anderson commented#181036: cannot download from https using IE is for d7, but will not be committed because the issue was fixed by #898036: Private images broken.
So, the question is, what to do in d6? There are two choices; one would be to back-port #898036 to d6 (re-open as 'patch to be ported'), the other would be to commit #43 above to d6. #898036 introduces hook_file_download, which is more flexible, but is also a larger-impact change to d6. My opinion is that the patch on this issue is easier and sufficient.
Comment #51
Gábor HojtsyOk, while reviewing this, it looked logical to have the two additional headers (from #42) to the $headers array, but after looking at the code more, it seems like it would be painful rather then useful to try and shoehorn it there. People could still override these two headers in the $headers array since that is processed later, so we should not loose customizability here.
So all in all, I've committed the patch from #42 and pushed to 6.x-dev. It should be fixed in the next stable Drupal version.
Comment #52
greg.1.anderson CreditAttribution: greg.1.anderson commentedThanks!
Comment #53
webengr CreditAttribution: webengr commentedthanks... years in the fixing...
while this was not a critical issue, it has been a pain for private ssl websites.
Comment #54
wickedwookie CreditAttribution: wickedwookie commentedthx for the fix, #43 did the trick for me
Comment #56
ChristopheMaertens CreditAttribution: ChristopheMaertens commentedwebengr, wickedwookie,
Is it fix for you? Can you explain how you did ?
I will explain you how i made:
1) I create an .htaccess to restrict the file download for users only & i placed it into sites/default/files wich contains:
2) I placed the following patch into the includes/file.inc like described on #43
Does someone have any idea to help me ?
Comment #57
webengr CreditAttribution: webengr commentedthe patch was suppose to go into the core,
have you updated your drupal 6 or drupal 7, if using 5 DONT
btw, 6-22 and 7-2 came out yesterday I think.
Comment #58
cyberto CreditAttribution: cyberto commentedHi all!
I am experiencing this issue even if my Drupal core is updated to the 6.22 version. I recently switched my website to SSL and the problem of downloading attachments with IE 8 and private file system appeared. To add a bit of info, files attached to nodes as CCK filefield dowload regularly. Whed I try download node attachments clicking on the related link Explorer seems to load something and then stops without reporting any message... With Chrome and Firefox everything is OK.
I am quite a newbie so I hope to have been clear reporting the issue.
Thanks
Comment #59
cyberto CreditAttribution: cyberto commentedComment #60
pmcdougl CreditAttribution: pmcdougl commentedJust thought I would leave a note for people who are running drupal behind an ssl offloader. I had to hack the files.inc file (hacking core is bad...etc.) to include a check for a header my reverse proxy set for me X-FORWARDED-PROTO. Hope this helps someone else.