Maybe IEs implementation existed before HTTP 1.1 and before the
"no-store" option was introducted, which seems to clarify the matter
of what isn't allowed to be stored to disk, there is nothing else in
the specififcation that mandates the user-agent or cache can not (in
the process of serving the orginary request) store it to disk (if the
implementation needs to).
That's a charitable way to look at it, and an interesting observation.
However, MS explicitly justifies the behavior in reference to the
"no-cache" directive (see second link below), and I believe that neither
the HTTP 1.0 Pragma semantics nor the HTTP 1.1 Pragma and Cache-Control
semantics support the behavior. Given, as you pointed out, that the
"no-store" option in HTTP 1.1 clears it up, then I think IE's
implementation is even more unreasonable, as there is a check-box for
HTTP 1.1 support.
I've worked with dynamic HTML for quite a few years and can't remember
stumbling over this problem, what is the simplest server response that
triggers this problem in IE ?
The problem occurs when using IE over an SSL connection, when the server
includes either "cache-control: no-cache" or "pragma: no-cache" headers,
or both, in the response, and the user is attempting to download a file
that is not rendered in the browser (e.g., the file is either to be
saved to disk or launched in some app other than a browser). Note that
IE does not manifest the problem when the no-cache directives are sent
in the response for non-SSL connections. I believe that Tomcat sends the
no-cache directives when serving a resource from a protected context,
i.e. one for which a <security-constraint> is defined.
(Mary-Beth reported here earlier that she got IE to behave properly by
unchecking the option "Do not save encrypted pages to disk," but I tried
this and it did not alleviate the problem. I believe Mary-Beth was
dealing with a different issue. It's worth noting that MS does not list
unchecking this option as a workaround in their bug report response for
this issue.)
The Tomcat bug report on it can be found here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=27122
And the IE bug report and MS response can be found here:
http://support.microsoft.com/?id=316431
The issue is especially vexing IMO because of how it manifests. IE
actually draws the download box with the progress bar, showing the
correct web address and even the correct mime type of the resource. Then
instead of beginning the download it suddenly throws up a window that
says the site is unreachable.
-Mark
Darryl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
