DO NOT REPLY [Bug 29975] New: - Workaround for bug in IE when fetching documents over HTTPS

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29975>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29975

Workaround for bug in IE when fetching documents over HTTPS

           Summary: Workaround for bug in IE when fetching documents over
                    HTTPS
           Product: Tomcat 5
           Version: 5.0.25
          Platform: All
               URL: http://support.microsoft.com/?id=316431
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: wtff@freenet.de


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...

Thanks

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org