브라우저의 캐싱에서 Tomcat 배포 파일을 컨텍스트로 어떻게 유지합니까?

Question

Tomcat 6.0.10을 사용하는 Java/Struts 애플리케이션을 작업 중입니다. 사용자가 일부 양식을 편집하고 PDF를 스트리밍 할 수있는 일반적인 웹 응용 프로그램입니다. 거슬러 올라가면 다음을 추가했습니다.

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

비 스트리밍 페이지 중 하나는 HTTP로 강제로 만들어지고 캐시되지 않았습니다 (우리는 생각했습니다). 시스템의 스트리밍 페이지에 대해 별도의 제약 조건 항목이 있습니다.

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에서 발생할 수 있습니까?

업데이트: 우리는 확인했고 Tomcat은 Pragma, 캐시 제어 및 매개 변수를 올바르게 보내고 있습니다. 따라서 문제가되지 않습니다 (음, 없음 및 최대 연령 값은 전송되지 않지만 여전히 문제가되지 않습니다).

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

일부 요청이 복제 된 이유 (그러나 다른 세션 ID)는 여전히 미스터리입니다 ...

폴.

Answer 1

브라우저는 SSL을 통해 수신하는 항목을 캐시해서는 안되므로 IE6의 버그로 기대어 있습니다. 당신은 1 대신 만료 값으로 0 또는 -1을 시도 할 수 있지만, 당신이하고있는 다른 모든 것은 나에게 괜찮아 보입니다.

response.setHeader("Expires", 0);