Hello,
This posting is to share a solution for a bug in Internet Explorer (all
relevant versions that are not extinct).
Environment Info:
The webapp had <security-constraint> enabled and mapped to one of the
user-password-role in tomcat-users.xml.
Problem Observation:
A servlet dynamically generated a .pdf file (thanks to FOP-Apache fellas),
which was successfully displayed on all mozilla based browsers. But,
Internet Explorer failed to display the file in Adobe Acrobat Reader plugin
and complained about no data to display.
If the <security-constraint> was removed, the same web application would
successfully display the pdf contents in the Acrobat Reader Plugin.
Investigation:
investigations revealed that tomcat introduces these three http directives
in the response when application is configured with <security-constraint>
tag in web.xml:
1. Pragma: No-cache
2. Expires: Thu, 01 Jan 1970 00:00:00 GMT
3. Cache-Control: no-cache
Internet Explorer plugin behavior:
NOTE: Information in following paragraph is observed and is not verified by
source code examination. The first observation is mentioned just in case
some one is struggling with it.
1. Internet Explorer supplies request URL the plugin after truncating it to
255 characters.
2. Internet Explorer intercepts plugin's request to the URL and tries to
supply data to plugin from it's cache.
Explanation of scenario:
Internet explorer receives response for a http request and analyses it. If a
plugin invocation is required, Internet Explorer invokes it and the original
URL string is passed to it after processing (read next observation). The
plugin then request the URL which is intercepted by Internet Explorer.
Internet Explorer finds the contents in it's local cache (which it had just
received as part of the same request before invoking the plugin). The cache
decides that the data is stale because they were marked as onetime usable
(non cacheable) by tomcat. Hence, plugin gets no data.
Solution:
This is a dirty workaround. As IE can't be fixed by us, we had to modify
tomcat not to set the three http directives mentioned above (under heading
Investigation).
modify source of org.apache.catalina.authenticator.AuthenticatorBase and
comment out these three lines and recompile Tomcat-4.0.3:
sresponse.setHeader("Pragma", "No-cache");
sresponse.setHeader("Cache-Control", "no-cache");
sresponse.setDateHeader("Expires", 1);
That is it! New Tomcat(vulnerable to stale data issue in caching web proxies
or browser) saved the day!!
- Manish
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
