Hi,
We've got a problem with displaying files as mentioned in the title. It's an Internet Explorer issue, but it doesn't happen when displaying the same files in the Files area (CORRECTION: it does seem to happen in the Files area as well when the files are not set as Public - my mistake). I know there are issues with IE and secure sites, and I can see in lib/filelib.php a reference to the issue, but I'm not knowledgeable enough to see what's going wrong with the display from the presentation tool.
Anybody else come across this? Any easy solutions?
Jim
P.S.: it seems that either setting IE7 to "Do not save encrypted pages to disk" OR setting the access restrictions for the presentation and the files to Public will allow the files to be viewed. I think the second works for IE6 as well, though I need to do some checking.
Keywords: file display problems, https, Internet Explorer, presentation tool, secure site
Comments
Hi all,
This is not just the presentation tool problem. I recently upgraded the server to https and all files with logged in and private access could not be opened or saved to disk with IE 7. I re uploaded the same files with public access permission and they all worked fine with both IE 6 and 7. The files worked fine with the access restrictions on firefox without any messing around
We had the same problem with our platform.
IE has generally problems with https sites, specially with caching mechanism.
an easy way to solve the problemis is to recode elgg, so that it sets caching to public, regardless of file access, set in elgg.
We've taken a look at recoding. We can apparently make it work by changing mod/file/download.php at lines 31-35 from
else {
// "Cache-Control: private" to allow a user's browser to cache the file, but not a shared proxy
// Also to override PHP's default "DON'T EVER CACHE THIS EVER" header
header("Cache-Control: private");
}
to
} else {
// "Cache-Control: private" to allow a user's browser to cache the file, but not a shared proxy
// Also to override PHP's default "DON'T EVER CACHE THIS EVER" header
//header("Cache-Control: private");
header("Pragma: public");
header("Cache-Control: public");
}
which basically just reproduces the settings from the first if clause. We could also just get rid of if-else construction, but we're keeping it for the moment to minimise changes. We could also implement a check for Internet Explorer, since that seems to be the cause of the problem.
My questions is: does setting caching to public have any negative effects - i.e., the else clause must have been there for some reason in the first place? And if so, are those effects reduced by operating entirely within an SSL environment?
Thanks for any feedback! I'm happy to submit this as a bug, but I'm hoping somebody with a bit more knowledge will be able to clarify the situation first.
Regards, Jim