FWIW: After much trial and error (and more error) I've been able to narrow down an issue I'm haveing to the same problem described above.

I've been using Apache/1.3.23 and php version 4.1.2, and php version 4.2 RC1 as Apache modules on the win2000 platform.  specifying a content-disposition type works great in http://, does not work properly in https://
(let me know if you need more detail, I'll gladly provide it) =)

I'm going to see if I can isolate this further and see if it happens with 4.1.1

With best regards,

Erik

I had the same problem and I'm trying to fix it.

Anyone can help us?????
It's urgent.

This is probably related to IE security settings.

You should go to: Tools -> Internet Options -> Advanced Tab -> scroll down to Security Settings and check the Do not save encrypted pages to disk box.

Anyway this is not a PHP bug.

This bug appears to occur only with PHP, and when running on a win2k server. 

It occurs with both IE5.5 and IE6 even when the "Do not save encrypted files to disk" is enable (or disabled). The errant behavior *does not* change. 

It is possible that it is a IIS bug in handling the PHP output during https encryption, or something specific to the win2k version of PHP 4.1.2 (et al). I'm guessing that something about the content disposition header is corrupted the headers being output by IIS when delivering content via SSL (https)

Its important not to identify bugs as "bogus" unless one actually TESTS the proposed solution first. This still appears to be a PHP-specific issue, interfacing with IIS.

This is problem of Internet Explorer. Other browsers should work fine. To solve this add:

header("Pragma: ");
header("Cache-Control: ");

And then it should work with https.

Best regards,
Andrzej

This is not just IIS related.
I run Apache 1.3.26 on Linux (RD7.2) and PHP 4.1.2 and I also suffer the problem.
I believe it is just related to IE clients.

And 
header("Pragma: ");
header("Cache-Control: ");
does not work for me.

I also believe the problem is that headers are corrupted.

Pedro.

The "magic" headers that andrzejw@lomac.net do work, but note:
header("Pragma: ");
header("Cache-Control: ");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");  // HTTP/1.1
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");        // HTTP/1.0

Does not work because of the last header !!
It works when I comment it out !!

Pedro.

Apache 1.3.26 and PHP 4.2.1 

I also came across this issue, and pgarre@ijcreditor.es headers (minus the last one) FIX the problem.  However in trying to tack down the issue I found that taking out the session check on the page also fixed the problem?  It seems odd that using sessions would change the behavior of IE.

this isn't just an issue in https and windows, its also http, and also on linux. If you have session_start in there and just put out a content-type and content-disposition, it will barf on you if you try to choose "open" instead of "save" .. "save" works fine. If you take out the session-start() it works great. If you use the headers trick noted two posts up, it also works great. 

Tested under ie4/5/5.5/6 ns4.78/4.79/6

This is an Internet Explorer Bug. Search the Microsoft Knowledgebase. It has something to do with the caching headers.

the relevant article is:
http://support.microsoft.com/default.aspx?scid=kb;en-us;316431

Well, seems like the workaround from the user end is just choosing an appropriate encoding when viewing a webpage. I was trying to see a squirrelmail login page from my home box thru https and it did not display. When i chose "view source", i can see everything in notepad. Then i found that under View > Encoding the selected option is Estonian(ISO) which is marked gray (as unavailable). When I changed the encoding to any else (even if it wasn't right for that page), i could see that page. 
in my case, the server is FreeBSD + apache-ssl + php, and the client is my home box running Win98+IE6.0

I experienced this problem on a FreeBSD platform with Apache 1.3.27 and PHP 4.2.3.
I originally thought it was the 'Set-Cookie: ' header because removing my session_start(); function fixed the problem, but then I noticed that this also caused the following header to be sent:
'Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0'
I then changed the 'session.cache_limiter' directive in php.ini from 'nocache' to 'private' which fixed the problem. This is the header it sends:
'Cache-Control: private, max-age=10800, pre-check=10800'
After some more experimaentation, it would appear to be the 'no-cache' part of the 'Cache-Control: ' header that is causing the problem.
--Marko.