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:[EMAIL PROTECTED]] 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 <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > 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: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]> -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
