사용자 정보 유출을 막으라는 말을 들었는데, 응답으로 “no-cache”만으로는 충분하지 않습니다. “no-store”도 필요합니다.
Cache-Control: no-cache, no-store
이 사양 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html을 읽은 후에도 왜 그런지 잘 모르겠습니다.
내 현재 이해는 중간 캐시 서버 전용이라는 것입니다. “no-cache”가 응답하더라도 중간 캐시 서버는 여전히 콘텐츠를 비 휘발성 저장소에 저장할 수 있습니다. 중간 캐시 서버는 다음 요청에 저장된 콘텐츠를 사용할지 여부를 결정합니다. 그러나 응답에 “no-store”가 있으면 중간 캐시 서버가 콘텐츠를 저장하지 않습니다. 따라서 더 안전합니다.
“no-cache”와 “no-store”가 모두 필요한 다른 이유가 있습니까?
답변
캐시no-cache 하지 않는다는 의미 가 아님을 명확히해야합니다 . 실제로 모든 요청에 대해 캐시 된 응답을 사용하기 전에 “서버에서 재 검증”을 의미합니다.
must-revalidate반면에 리소스가 오래된 것으로 간주 될 때만 재 검증하면됩니다.
서버가 리소스가 여전히 유효하다고 말하면 캐시가 해당 표현으로 응답 할 수 있으므로 서버가 전체 리소스를 다시 보낼 필요가 줄어 듭니다.
no-store사실상 전체 캐시 금지 지시문이며 어떤 형태의 캐시로도 표현이 저장되는 것을 방지하기위한 것입니다.
나는 무엇이든 말하지만 RFC 2616 HTTP 사양에서 이것을 주목하십시오.
히스토리 버퍼는 정상적인 작동의 일부로 이러한 응답을 저장할 수 있습니다.
그러나 이것은 잠재적으로 no-store더 강력 하게 만들기 위해 새로운 RFC 7234 HTTP 사양에서 생략되었습니다 .
http://tools.ietf.org/html/rfc7234#section-5.2.1.5
답변
특정 상황에서 IE6는 Cache-Control: no-cache응답 헤더에있는 경우에도 파일을 캐시합니다 .
no-cache 지시문이 field-name을 지정하지 않으면, 캐시는 원 서버와의 성공적인 재 검증없이 후속 요청을 만족시키기 위해 응답을 사용해서는 안됩니다.
내 응용 프로그램에서 no-cache헤더 가있는 페이지를 방문한 다음 로그 아웃 한 다음 브라우저에서 다시 누르면 IE6는 여전히 캐시에서 페이지를 가져옵니다 (서버에 대한 새 / 유효성 확인 요청없이). no-store헤더에 추가하면 중단되었습니다. 그러나 W3C를 사용하면 실제로이 동작을 제어 할 방법이 없습니다.
히스토리 버퍼는 정상적인 작동의 일부로 이러한 응답을 저장할 수 있습니다.
브라우저 기록과 일반 HTTP 캐싱 간의 일반적인 차이점은 사양의 특정 하위 섹션에 설명 되어 있습니다.
답변
로부터 HTTP 1.1 사양 :
노점 :
노 점포 의 목적지침은 민감한 정보 (예 : 백업 테이프)의 부주의 한 공개 또는 보존을 방지하는 것입니다. no-store 지시문은 전체 메시지에 적용되며 응답 또는 요청으로 전송 될 수 있습니다. 요청으로 전송되는 경우 캐시는이 요청 또는 이에 대한 응답의 일부를 저장해서는 안됩니다. 응답으로 전송되는 경우 캐시는이 응답 또는이를 유도 한 요청의 일부를 저장해서는 안됩니다. 이 지시문은 비공유 및 공유 캐시 모두에 적용됩니다. 이 문맥에서 “저장해서는 안된다”는 것은 캐시가 정보를 비 휘발성 저장소에 의도적으로 저장해서는 안되며, 정보를 전달한 후 가능한 한 빨리 휘발성 저장소에서 정보를 제거하기 위해 최선을 다해야 함을 의미합니다. 이 지시문이 응답과 연관되어 있어도 사용자는 이러한 응답을 캐싱 시스템 외부에 명시 적으로 저장할 수 있습니다 (예 : “다른 이름으로 저장”대화 상자 사용). 히스토리 버퍼는 정상적인 작동의 일부로 이러한 응답을 저장할 수 있습니다. 이 지침의 목적은 캐시 데이터 구조에 대한 예상치 못한 액세스를 통해 우발적 인 정보 공개에 대해 우려하는 특정 사용자 및 서비스 작성자의 명시된 요구 사항을 충족하는 것입니다. 이 지침을 사용하면 경우에 따라 개인 정보가 향상 될 수 있지만, 우리는 이것이 개인 정보 보호를위한 신뢰할 수 있거나 충분한 메커니즘이 아니라는 점에주의합니다. 특히 악의적이거나 손상된 캐시는이 지침을 인식하거나 준수하지 않을 수 있으며 통신 네트워크는 도청에 취약 할 수 있습니다. 히스토리 버퍼는 정상적인 작동의 일부로 이러한 응답을 저장할 수 있습니다. 이 지침의 목적은 캐시 데이터 구조에 대한 예상치 못한 액세스를 통해 우발적 인 정보 공개에 대해 우려하는 특정 사용자 및 서비스 작성자의 명시된 요구 사항을 충족하는 것입니다. 이 지침을 사용하면 경우에 따라 개인 정보가 향상 될 수 있지만, 우리는 이것이 개인 정보 보호를위한 신뢰할 수 있거나 충분한 메커니즘이 아니라는 점에주의합니다. 특히 악의적이거나 손상된 캐시는이 지침을 인식하거나 준수하지 않을 수 있으며 통신 네트워크는 도청에 취약 할 수 있습니다. 히스토리 버퍼는 정상적인 작동의 일부로 이러한 응답을 저장할 수 있습니다. 이 지침의 목적은 캐시 데이터 구조에 대한 예상치 못한 액세스를 통해 우발적 인 정보 공개에 대해 우려하는 특정 사용자 및 서비스 작성자의 명시된 요구 사항을 충족하는 것입니다. 이 지침을 사용하면 경우에 따라 개인 정보가 향상 될 수 있지만, 우리는 이것이 개인 정보 보호를위한 신뢰할 수 있거나 충분한 메커니즘이 아니라는 점에주의합니다. 특히 악의적이거나 손상된 캐시는이 지침을 인식하거나 준수하지 않을 수 있으며 통신 네트워크는 도청에 취약 할 수 있습니다. 이 지침을 사용하면 경우에 따라 개인 정보가 향상 될 수 있지만, 우리는 이것이 개인 정보 보호를위한 신뢰할 수 있거나 충분한 메커니즘이 아니라는 점에주의합니다. 특히 악의적이거나 손상된 캐시는이 지침을 인식하거나 준수하지 않을 수 있으며 통신 네트워크는 도청에 취약 할 수 있습니다. 이 지침을 사용하면 경우에 따라 개인 정보가 향상 될 수 있지만, 우리는 이것이 개인 정보 보호를위한 신뢰할 수 있거나 충분한 메커니즘이 아니라는 점에주의합니다. 특히 악의적이거나 손상된 캐시는이 지침을 인식하거나 준수하지 않을 수 있으며 통신 네트워크는 도청에 취약 할 수 있습니다.
답변
모든 캐싱을 방지하려면 (예 : 뒤로 버튼을 사용할 때 강제로 다시로드) 다음이 필요합니다.
-
IE 용 캐시 없음
-
Firefox 용 매장 없음
여기에 대한 내 정보가 있습니다.
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
답변
no-store정상적인 상황에서는 필요하지 않으며 속도와 사용 편의성을 모두 손상시킬 수 있습니다. HTTP 응답에 민감한 정보가 포함되어있어 사용자에게 부정적인 영향을 미치더라도 디스크 캐시에 전혀 기록되지 않아야하는 경우 사용하기위한 것입니다.
작동 원리 :
-
일반적으로 브라우저와 같은 사용자 에이전트가 응답을 캐시하지 않아야한다고 결정하더라도 사용자 에이전트 내부의 이유로 디스크 캐시에 저장할 수 있습니다. 이 버전은 “소스보기”, “뒤로”, “페이지 정보”등과 같은 기능에 활용 될 수 있습니다. 사용자가 반드시 페이지를 다시 요청하지는 않았지만 브라우저는이를 새 페이지보기로 간주하지 않습니다. 사용자가 현재보고있는 것과 동일한 버전을 제공하는 것이 좋습니다.
-
을 사용
no-store하면 해당 응답이 저장되지 않지만 이는 브라우저가 서버에 대해 별도의 새 요청을하지 않고 “소스보기”, “뒤로”, “페이지 정보”등을 제공하는 기능에 영향을 미칠 수 있으며 이는 바람직하지 않습니다. 즉, 사용자가 소스를 보려고 시도 할 수 있으며 브라우저가이를 메모리에 저장하지 않은 경우 이것이 가능하지 않다는 메시지가 표시되거나 서버에 새로운 요청이 발생합니다. 따라서no-store이러한 기능이 제대로 작동하지 않거나 빠르게 작동하지 않는 사용자 경험을 방해하는 것이 콘텐츠가 캐시에 저장되지 않도록하는 것의 중요성보다 더 중요한 경우에만 사용해야합니다.
내 현재 이해는 중간 캐시 서버 전용이라는 것입니다. “no-cache”가 응답하더라도 중간 캐시 서버는 여전히 콘텐츠를 비 휘발성 저장소에 저장할 수 있습니다.
이것은 올바르지 않습니다. HTTP 1.1과 호환되는 중간 캐시 서버는 no-cache및 must-revalidate지침 을 준수하여 콘텐츠가 캐시되지 않도록합니다. 이 명령을 사용하면 응답이 중간 캐시에 의해 캐시되지 않고 모든 후속 요청이 원본 서버로 다시 전송되는지 확인할 수 있습니다.
중간 캐시 서버가 HTTP 1.1을 지원하지 않으면 Pragma: no-cache최선을 다해 사용 하고 희망 해야합니다 . HTTP 1.1을 지원하지 않으면 no-store어쨌든 관련이 없습니다.
답변
캐싱 시스템이 no-store를 올바르게 구현하면 no-cache가 필요하지 않습니다. 그러나 모두가 그렇지는 않습니다. 또한 일부 브라우저는 저장소가없는 것처럼 캐시를 구현하지 않습니다. 따라서 반드시 필요한 것은 아니지만 둘 다 포함하는 것이 가장 안전 할 것입니다.
답변
버전 5에서 8까지의 Internet Explorer는 https 및 서버 전송 Cache-Control: no-cache또는 Pragma: no-cache헤더 를 통해 제공되는 파일을 다운로드하려고 할 때 오류를 발생시킵니다 .
참조 http://support.microsoft.com/kb/812935/en-us를
의 사용 Cache-Control: no-store과는 Pragma: private여전히 작동 가장 가까운 일이 될 것으로 보인다.
