컨텍스트에서 Tomcat 배포 파일을 브라우저에 캐싱하지 않으려면 어떻게해야합니까?

Question

Tomcat 6.0.10을 사용하는 Java/Struts 응용 프로그램에서 작업하고 있습니다. 사용자가 일부 양식을 편집하고 PDF를 스트리밍 할 수있는 일반적인 웹 응용 프로그램입니다. 돌아 오는 길에, 우리는 추가 :

가 아닌 스트리밍 페이지의 캐시 HTTPS로 강제되지 않도록

<security-constraint> 
    <web-resource-collection> 
     <web-resource-name>GeneralRequests</web-resource-name> 
     <url-pattern>/WR1/*</url-pattern> 
    </web-resource-collection> 
    <user-data-constraint> 
     <transport-guarantee>CONFIDENTIAL</transport-guarantee> 
    </user-data-constraint> 
</security-constraint> 

은 (우리가 생각). 시스템의 스트리밍 페이지에 대한 별도의 제한 조건 항목이 있습니다.

최근의 IE6 테스트에서 우리는 언제쯤 페이지가 캐싱되고 있는지를 알 수 있습니다. 뿐만 아니라 기밀 플래그로, 우리는 또한 가지고 사용 :

 response.setHeader("Pragma", "No-cache"); 
     response.setHeader("Cache-Control", "no-cache,no-store,max-age=0"); 
     response.setDateHeader("Expires", 1); 

을하지만 IE6에서 추악한 재 ​​게시 경고의 원인이 될 듯하기 때문에 우리는이를 제거하고 우리는 기밀 운송 보증도 모두 포함되어 있다고 생각 페이지의 브라우저 캐싱을 막는 적절한 메커니즘. 우리는 문제를 제대로 수행하기 위해 Tomcat에 맡기고 싶습니다.

미래에 어떤 문제가 발생하지 않도록이 작업을 수행하는 "올바른"방법은 무엇입니까?

캐싱 문제는 IE6의 특정 버그로 인해 발생합니까? 아니면 특정 릴리스 세트입니까? 이것이 7 및/또는 8에서 일어날 수 있습니까?

UPDATE : 우리는 확인하고, 그 문제되지 않도록 톰캣이 제대로 잘, 노 문자열과 최대 사용 기간 값이 전송되지 않는 (프라 그마, 캐시 제어, params가 만료을 보내고 있지만, 여전히 문제는 아닙니다).

문제는 Apache Portable Runtime (APR) 1.1.8로 판명되었습니다. 어쨌든, 우리가 완전히 확신 할 수는 없지만 한 번의 요청으로 중복 된 브라우저 동작을 생성합니다. 우리에게는 잘못된 Struts 트랜잭션 토큰이 포함되어 있기 때문에 페이지가 캐시 된 것처럼 보였습니다. 실제로 동일한 요청의 두 번째 실행 버전 (잘못된 세션 ID 포함)이 세션의 원래 요청 토큰을 덮어 쓰는 중이었습니다. 1.1.16로 업그레이드하면 문제가 해결되었습니다. 일부 요청이 중복지고 이유

는

(그러나 다른 세션 ID가) ... 여전히

폴 신비입니다.

Answer 1

브라우저가 SSL을 통해 수신하는 항목을 캐시해서는 안되기 때문에 IE6의 버그에 기울어 질 것입니다. 당신은 1 대신 Expires의 값으로 0이나 -1을 시도 할 수 있습니다. 그러나 당신이하고있는 모든 것은 괜찮습니다.

response.setHeader("Expires", 0);