You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2002/03/13 00:22:10 UTC
Re: Internet Explorer bug in handling immediately expiring;
non-cacheable response. (Adobe Acrobat reader plugin will fail to display
requested pdf in a enabled web application in To
See comment at the bottom.
On Tue, 12 Mar 2002, Manish Pandya wrote:
> Date: Tue, 12 Mar 2002 18:26:00 -0500
> From: Manish Pandya <ma...@cobite.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Internet Explorer bug in handling immediately expiring;
> non-cacheable response. (Adobe Acrobat reader plugin will fail to display
> requested pdf in a <security-constraint> enabled web application in
> Tomcat).
>
> 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,
Thanks for the detailed analysis of what's going on. I just wanted to add
one point about why those three lines were added in the first place --
without them, proxies in between the browser and the server would cache
content behind a protected URL, which risks exposing that information to
someone else who accesses the same page. Removing these three lines
removes your protection from this.
>
> - Manish
>
Craig McClanahan
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
RE: Internet Explorer bug in handling immediately expiring; non-cacheable response. (Adobe Acrobat reader plugin will fail to display requested pdf in a enabled web application in To
Posted by Manish Pandya <ma...@cobite.com>.
You are welcome Craig,
During my investigation I was following tcp/ip packets in different
configuration environments. one of test env was apache (1.3.23). I
configured ".htaccess" constraint for equivalent environment. Apache did not
produce those three http directives in response.
Do I need to draw attention of Apache fellows for the security hole you are
mentioning?
- Manish
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Tuesday, March 12, 2002 6:22 PM
To: Tomcat Users List
Subject: Re: Internet Explorer bug in handling immediately expiring;
non-cacheable response. (Adobe Acrobat reader plugin will fail to
display requested pdf in a <security-constraint> enabled web application
in To
See comment at the bottom.
On Tue, 12 Mar 2002, Manish Pandya wrote:
> Date: Tue, 12 Mar 2002 18:26:00 -0500
> From: Manish Pandya <ma...@cobite.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Internet Explorer bug in handling immediately expiring;
> non-cacheable response. (Adobe Acrobat reader plugin will fail to
display
> requested pdf in a <security-constraint> enabled web application in
> Tomcat).
>
> 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,
Thanks for the detailed analysis of what's going on. I just wanted to add
one point about why those three lines were added in the first place --
without them, proxies in between the browser and the server would cache
content behind a protected URL, which risks exposing that information to
someone else who accesses the same page. Removing these three lines
removes your protection from this.
>
> - Manish
>
Craig McClanahan
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>