Cache-Control: no-cache로 프록시 다운로드 재검증하기

다운로드 URL을 바꾸지 않고 검증된 응답을 요청하고, 재검증을 저장 금지와 혼동하지 마세요.

다운로드 URL은 맞지만 공유 프록시에 저장된 응답이 아직 남아 있습니다. 작업에 원본과 검증된 응답이 필요하다면 그 요구 사항을 요청에 실으세요:

from urllib.request import ProxyHandler, Request, build_opener
import shutil

opener = build_opener(ProxyHandler({
    "https": "http://proxy.example:8080",
}))
request = Request(download_url, headers={"Cache-Control": "no-cache"})
with opener.open(request, timeout=15) as response:
    shutil.copyfileobj(response, output)

이 조각은 애플리케이션이 바이너리 출력 스트림을 소유하고 HTTPS download_url을 제공한다고 가정합니다. 프록시 인증 없이 허용된 공개 다운로드를 시험하려면 opener에서 HTTP 프록시 목록의 HTTP 엔드포인트 후보를 사용하세요. 요청의 캐시 요구 사항은 그대로입니다. 원래 리소스 URL을 유지하면서 요청 경로의 캐시에 재사용 전 검증을 요구합니다.

검증은 저장된 바이트를 재사용할 수 있다

no-cache를 받은 규격 준수 캐시는 원본과의 검증이 성공하지 않는 한 저장된 응답으로 이 요청을 충족할 수 없습니다. 원본은 저장된 표현이 여전히 유효함을 확인할 수 있으므로, 작업이 변경되지 않은 파일을 원본에서 다시 전송할 필요는 없습니다.

요청의 max-age=0은 나이 제한을 표현합니다. 애플리케이션이 그 제한보다 오래되지 않은 응답을 원할 때 유용하지만, 저장 금지는 아닙니다. 방금 생성된 응답도 이를 충족할 수 있습니다.

임의의 쿼리 매개변수를 추가하면 다른 대상 URI를 요청하게 됩니다. 그러면 다른 캐시 항목이 생기거나 애플리케이션의 응답 자체가 바뀔 수 있습니다. 쿼리 매개변수는 리소스의 의도된 인터페이스의 일부일 때만 사용하세요.

일반 HTTPS CONNECT에서는 터널링 프록시가 TLS 내부의 이 헤더를 볼 수 없습니다. 그래도 정책은 원본과 복호화된 HTTP 교환을 처리하는 캐시에 도달할 수 있습니다. 저장된 응답을 터널 탓으로 돌리기 전에 그것이 실제로 어디에 있는지 확인하세요.

관련 글