I realize this is the Tomcat list, but I suspect many people here use
Struts in developing their apps... I think it is worth noting that
Struts provides a "nocache" switch for the Request Processor that does
the same thing (setting the no cache headers). I found this out the
hard way about two weeks ago when I ran into this very problem, but it
turned out to be caused by this Struts option as I was running under
Websphere. The point being that even if you can disable the option in
Tomcat (and I'm not sure you can?), if you are using Struts you still
could experience the same issue if you aren't aware the the headers
could be set in two places.
FYI, I wound up writing a filter that lets me define paths that WILL NOT
have the cache headers set, all others they are set for (because all but
three paths in my app needed the headers set, the 3 were where PDFs get
generated). I use this in place of the Struts setting. This filter
will appear in my Sourceforge JavaWebParts project, in case anyone else
might be interested.
Frank
Mark Leone wrote:
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]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
