Cache-Control change in #109941 breaks private downloads over SSL in IE6/7

We're experiencing this exact problem as well. Changing to "no-store" seems to fix the problem.

This is a known bug in IE6/IE7. See http://support.microsoft.com/kb/316431

Unfortunately, it is a design bug; Microsoft says the behavior is by design.

I'm not sure I understand the underlying issue well enough to comment, but what happens if you go to bootstrap.inc and change the existing

header("Cache-Control: store, no-cache, must-revalidate");

to

 header("Cache-Control: must-revalidate");
 

}

I am guessing there are other factors at work since we do send no-cache and must-revalidate in either case.

The ideal solution would be to send non-ie-bug-triggering headers for file downloads, and keep the present headers for everything else.

Hi,

I'm new here,

This problem is occurring for me on a new 5.7 install. (I upgraded from 4 over the weekend).

Should the Version be changed to 5.7. Is it proper for me to do this? or should someone else.

Thanks.

I'm wondering if this also affects cacheing of images located above root in drupal's private file system. My site will not cache images above root although it does cache files that are within the drupal root.
See my other post: http://drupal.org/node/272082

I just used:

header("Cache-Control: store, must-revalidate");

Seems to work.

It seems that commenting out the entire line

header("Cache-Control: store, no-cache, must-revalidate");

everything works just swimmingly.

Would commenting out that line cause problems elsewhere? bmherold, let us know if you notice any wonkiness. Thanks.

I stumbled on this with the same problem - trying to use private downloads over SSL. Here's how I've solved it (apparently - still early). I created a module I called sslfiles.module:

<?php
/**
 * Implements hook_file_download
 */
function sslfiles_file_download($file)
{
  // Use PHP's header() function to return the same cache-control headers as
  // drupal_page_header(), defined in bootstrap.inc
  // except remove no-cache, and add maxage
  header("Cache-Control: store, must-revalidate, maxage=1", TRUE);
  header("Cache-Control: post-check=0, pre-check=0", FALSE);
}

So, basically instead of returning headers, I'm using php's header() function to blow away Drupal's regular Cache-Control headers. But since this is in hook_file_download, this only happens for file downloads.

Are there any problems with this approach that I'm missing? I can definitely verify that it works. Enable the module and the problem goes away. Disable it, and it's back.

I am very interested in this "sslfiles.module". I hate making changes to anything in core at all, so a modular solution is best for me. What was your experience with this sslfiles experiment? How exactly did you implement it?

Here's a patch for D7 against HEAD that solves the issue properly.

My considerations:
- drupal_page_head() changes made in #109941 from no-store to store does break SSL-based downloads.
- drupal_page_head() should not assume that everything is uncachable if a user is logged in. static files are, for example.
- drupal_page_head() should be moved to a position later in the code, but this point does not exist, as then we're already deep inside menu_execute_active_handler() and the menu.
- modules should NOT have to fix something that is wrong for all file downloads.
- modules must be able to overrule the settings taken.
- file_download's should be cacheable (--> cache)

Thus implementation goes inside file.inc:function file_transfer() before the header-settings code-block, giving the modules through hook_file_download a chance to correct the "Cache-Control" header.

THIS is the same issue for D5, D6, that is in a different thread dealing with the upload.module,

may want to see also:

http://drupal.org/node/163445#comment-1654466

Basically Microsoft says you should not cache SSL downloads, thus we need to send Cache-Control: no-store
when ssl according to:
http://support.microsoft.com/kb/815313

This looks like a duplicate of #163445: Internet Explorer cannot download private files. Please refer to the other issue.