Bug 29975 - Workaround for bug in IE when fetching documents over HTTPS
Summary: Workaround for bug in IE when fetching documents over HTTPS
Status: RESOLVED DUPLICATE of bug 27122
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.0.25
Hardware: All All
: P3 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL: http://support.microsoft.com/?id=316431
Depends on:
Reported: 2004-07-08 13:21 UTC by Sascha C.
Modified: 2004-11-16 19:05 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Sascha C. 2004-07-08 13:21:08 UTC
when I configure a web application with the user data constraint set to 
confidential, so that tomcat enforces HTTPS access and then try to download a 
PDF document using InternetExplorer, the document cannot be displayed due to a 
bug within IE. The above URL describes the bug but tells that it is "by design" 
(as all Microsoft bugs are ;) ).

The problem occurs because tomcat adds the following two HTTP headers, if and 
only if a webapp has a user-data constraint of confidential:

Pragma: no-cache
Cache-control: no-cache,max-age=0,must-revalidate

I need to secure my web application and I need to workaround this IE bug on the 
server side. Tomcat 4.x does not cause the problem, but tomcat5.x does.

It is not a safe solution to remove the respective http headers within a filter 
because the filter would have to do this after the filterchain invocation and 
the outputstream could already have been committed at that time.

Another way would be to add a filter which tests whether a request is HTTP and 
then manually redirects to HTTPS and then dropping the user-data-constraint 
from the web-descriptor.

Since nearly all IE browsers have this bug, this means that unless tomcat 
provides a workaround solution for this, developers will not be able to 
facilitate the standard way specifying security constraints.

Any ideas for a short-time workaround that I could apply would be very welcome 
since I need to get this fixed quickly...

Comment 1 william.barker 2004-07-08 19:42:42 UTC

*** This bug has been marked as a duplicate of 27122 ***
Comment 2 Juergen Ebert 2004-09-22 14:30:46 UTC
Well, correct me if I'm wrong, but don't the Tomcat developers behave exactly 
as Microsoft in this case? Both parties insist on being right and expect the 
other side to change their code. Not very helpful for the rest of us. Why isn't 
it possible to make the described caching behaviour a configurable option in