Return-Path: 
 <tomcat-user-return-128394-apmail-jakarta-tomcat-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-tomcat-user-archive@www.apache.org
Received: (qmail 83462 invoked from network); 10 Jun 2005 01:46:07 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 10 Jun 2005 01:46:07 -0000
Received: (qmail 48224 invoked by uid 500); 10 Jun 2005 01:45:42 -0000
Delivered-To: apmail-jakarta-tomcat-user-archive@jakarta.apache.org
Received: (qmail 48200 invoked by uid 500); 10 Jun 2005 01:45:41 -0000
Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
List-Help: <mailto:tomcat-user-help@jakarta.apache.org>
List-Post: <mailto:tomcat-user@jakarta.apache.org>
List-Id: "Tomcat Users List" <tomcat-user.jakarta.apache.org>
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Delivered-To: mailing list tomcat-user@jakarta.apache.org
Received: (qmail 48107 invoked by uid 99); 10 Jun 2005 01:45:41 -0000
X-ASF-Spam-Status: No, hits=0.2 required=10.0
	tests=DATE_IN_PAST_06_12,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: domain of jak-tomcat-user@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2)
  by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 09 Jun 2005 18:45:38 -0700
Received: from root by ciao.gmane.org with local (Exim 4.43)
	id 1DgYVZ-0008AH-Ay
	for tomcat-user@jakarta.apache.org; Fri, 10 Jun 2005 03:40:34 +0200
Received: from phoenix.nro.mil ([209.22.180.17])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <tomcat-user@jakarta.apache.org>; Fri, 10 Jun 2005 03:40:29 +0200
Received: from midnightjava by phoenix.nro.mil with local (Gmexim 0.1
 (Debian))
        id 1AlnuQ-0007hv-00
        for <tomcat-user@jakarta.apache.org>; Fri, 10 Jun 2005 03:40:29 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: tomcat-user@jakarta.apache.org
From: Mark Leone <midnightjava@cox.net>
Subject: Re: Tomcat, SSL, IE, and .pdf downloads
Date: Thu, 9 Jun 2005 19:04:53 +0000 (UTC)
Lines: 41
Message-ID: <loom.20050609T204140-845@post.gmane.org>
References: 
 <DA2B5151AA55CB4FBCCADEE628154A500A7F30CD@mspexch3.ntdom1.personneldecisions.com>
 <42A7A6AA.5020705@cox.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: main.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 209.22.180.17 (Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0))
Sender: news <news@sea.gmane.org>
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N


Mark Leone <midnightjava <at> cox.net> writes:

> 
> 
> BTW, switching gears, I should have mentioned the following in my 
> previous email. I suspect that the IE workaround you described will only 
> work for SSL connections. Tomcat (and presumably any other good HTTP 
> server) will set the cache control headers to prevent caching of any 
> response generated from a protected context (i.e. one in which there is 
> a <security-constraint> element), whether the connection is made with 
> HTTPS (i.e., SSL) or HTTP. The IE option you described seems to apply 
> only to encrypted data, so it probably won't help IE users who are 
> trying to download files from a protected context via HTTP.
> 

Correction to my previous post: The work-around apparently is not needed for 
non-SSL connections. I did a little experiment and found  that IE doesn't have 
a problem with non-SSL responses that include headers with the "no-cache" cache 
directive. 

This alleviates the security concern I raised, since Tomcat can be configured 
to prohibit caching from protected contexts for non-SSL connections, and this 
behavior only needs to be overriden for SSL connections to satisfy IE, which I 
guess is not as problematic from a security standpoint. It's still a 
compatibility issue, IMO, since implementers will regularly encounter the 
problem with SSL connections and wonder what is going on.

Also, Mary Beth, I was unable to duplicate your results with unchecking 
the "don't allow encrypted data to be cached to disk" option. I commented out 
the <valve> in server.xml so that IE was not working properly for SSL file 
downloads. Then I unchecked the aforementioned option in 
IE, and it did not fix the problem. I'm wondering if you're dealing with a 
different issue. I'd like to know if you apply the <valve> fix in server.xml, 
and if it solves your problem. Did you do anything else to make IE work without 
the <valve> in server.xml?

-Mark





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