HTTP 301 영구 리디렉션과 관련된 문제를 디버깅 중입니다. 빠른 테스트 후 Safari는 다시 시작될 때 301 캐시를 지우지 만 Firefox는 그렇지 않습니다.

IE, Chrome, Firefox 및 Safari는 언제 301 캐시를 삭제합니까?

업데이트 : 예를 들어로 리디렉션 example1.com하고 example2.com싶지만 실수로로 리디렉션하도록 설정 example3.com하면 문제가됩니다. 실수를 바로 잡을 수는 있지만 example1.com그 동안 방문한 사람은에 대한 잘못된 리디렉션을 캐시 example3.com했기 때문에 캐시가 지워질 때까지 example1.com또는 도달 할 수 없습니다 example2.com. 조사 결과, 나는이 더 있다고 찾을 Cache-Control및 Expires헤더를 설정합니다. 잘못된 301 응답의 헤더는 다음과 같습니다.

HTTP/1.1 301 Moved Permanently
Date: Wed, 27 Feb 2013 12:05:53 GMT
Server: Apache/2.2.21 (Unix) DAV/2 PHP/5.3.8
X-Powered-By: PHP/5.3.8
Location: http://example3.com/
Content-Type: text/html

내 자신의 테스트는 다음을 보여줍니다.

IE7, IE8, Android 2.3.4는 전혀 캐시하지 않습니다.
Firefox 18.0.2, Safari 5.1.7 (Windows 7) 및 Opera 12.14는 모든 캐시이며 브라우저를 다시 시작할 때 캐시를 지우십시오.
IE10 및 Chrome 25가 캐시되지만 브라우저를 다시 시작할 때 지워지지 않으므로 언제 지워 집니까?

답변

Chrome과 Firefox의 두 개 이상의 브라우저는 만료 날짜없이 301 리디렉션을 캐시 합니다 .

즉, 브라우저의 캐시가이를 수용 할 수있는 한 캐시 된 상태로 유지됩니다. 캐시를 수동으로 지우거나 캐시 항목을 제거하여 새 캐시를위한 공간을 확보하면 캐시에서 제거됩니다.

about:cache디스크 캐시 로 가서 찾아서 최소한 Firefox에서이를 확인할 수 있습니다 .

IE10 / IE11과 같은 다른 브라우저의 동작에 대해 모르겠습니다. 그러나 다른 브라우저가 무기한으로 캐시하는 경우 어쨌든이를 수용해야합니다.

Chrome / Firefox를 포함한 모든 브라우저에서 아래에 설명 된대로 헤더를 사용하여이 기본 동작을 무시할 수 있습니다.

참고 :이 답변은 2014 년에 작성되었으며 브라우저 동작은 시간이 지남에 따라 변경 될 수 있습니다.

리디렉션을 캐시하지 않으려는 경우

이 무기한 캐싱은 Cache-Control 헤더가없는 경우 이러한 브라우저에 의한 기본 캐싱입니다. 논리는 “영구적”리디렉션을 지정하고 다른 캐싱 명령을 제공하지 않기 때문에 마치 영구적으로 캐시되기를 원하는 것처럼 취급합니다.

브라우저는 여전히 지정된 경우 다른 응답과 마찬가지로 Cache-Control 및 Expires 헤더를 유지합니다.

당신은 같은 헤더를 추가 할 수 있습니다 Cache-Control: max-age=3600또는 Expires: Thu, 01 Dec 2014 16:00:00 GMT귀하의 301 리디렉션에. 당신은 추가 할 수 Cache-Control: no-cache가 브라우저에 의해 영구적으로 캐시되지 않거나, 그래서 Cache-Control: no-store그래서 심지어 브라우저에 의해 임시 저장소에 저장 될 수 없습니다.

그러나 내 의견으로는 더 나은 대안은 302 또는 307 리디렉션을 사용하는 것입니다. 이것들은 브라우저가 “영구적”리다이렉션하고 따라서 Cache-Control 헤더가없는 상태에서 캐싱되어서는 안된다는 것을 암시하지 않습니다.

나에게는 301 리디렉션을 발행하는 것처럼 보이지만 캐시 할 수 없음으로 표시하는 것은 기술적으로 유효하더라도 301 리디렉션 의 정신 에 위배 됩니다. YMMV 및 “영구적”리디렉션이 시간 제한을 갖는 것이 적합한 경우를 찾을 수 있습니다.

이전에 301 리디렉션을 발행했지만 실행을 취소하려는 경우

사람들이 여전히 브라우저에 캐시 된 301 리디렉션을 가지고 있다면 소스 페이지에 여전히 리디렉션이 있는지 여부에 관계없이 대상 페이지로 계속 이동합니다. 이 문제를 해결하기위한 옵션은 다음과 같습니다.

가장 간단하고 최상의 솔루션은 다시 301 리디렉션을 다시 발행하는 것입니다.

브라우저는 이전에 사용 중지 된 URL이라고 생각했던 것으로 되돌아 가고 있음을 인식하고, 이로 인해 해당 URL을 다시 가져 와서 이전 리디렉션이 아직 존재하지 않음을 확인해야합니다.

편집 : 일부 의견은 이것에 의문을 제기합니다 (아래 참조).
이전 리디렉션 대상이있는 사이트를 제어 할 수없는 경우 운이 좋을 것입니다. 사이트 소유자에게 다시 리디렉션하도록 요청하십시오.

또한 예방은 치료보다 낫습니다. 이전 URL을 영구적으로 해제하지 않으려면 301 리디렉션을 피하십시오.

답변

Chrome에서 71

영구 리디렉션을 지우려면 chrome : // settings / clearBrowserData로 이동하여 “캐시 된 이미지 및 파일”만 지우면 리디렉션이 지워집니다.

크롬 48-70

chrome : // net-internals로 이동하십시오. 상단 빨간색 상태 표시 줄의 오른쪽에서 아래쪽 화살표 ▼를 클릭하여 드롭 다운 메뉴를 열고 “도구”그룹에서 “캐시 지우기”를 선택하십시오.

버전 48부터는 캐시 된 301을 지우는 데 도움이 된 유일한 방법이었습니다.

답변

리디렉션 캐시를 필사적으로 제거하려는 사람들을 돕는 답변 :

Chrome은 로컬 디스크 캐시에서 301 리디렉션을 무한 캐시합니다. 이 캐시를 지우려면

당신의 열 DevTools로 (보도를 F12)
온 네트워크 탭 확인 “사용 안함 캐시” 체크 박스를
DevTools를 연 상태로 유지 하고 페이지를 다시로드 하십시오 (을 누르십시오 F5)

모든 것이 정상이면 “캐시 비활성화”를 선택 해제하면 모든 것이 예상대로 계속 작동합니다.

답변

사용자가 해당 URL에 게시 양식을 제출하고 캐시 된 리디렉션이 사라지게합니다. 🙂

<body onload="document.forms[0].submit()">
<form action="https://forum.pirati.cz/unreadposts.html" method="post">
    <input type="submit" value="fix" />
</form>
</body>

답변

301는 HTTP RFC 당 캐시 가능한 응답이며 브라우저는 응답에있는 HTTP 캐싱 헤더에 따라이를 캐시합니다. FireBug 또는 Charles를 사용하여 응답 헤더를 검사하여 응답이 캐시되는 정확한 기간을 알 수 있습니다.

당신은 캐싱 시간을 제어하려는 경우, 당신은 HTTP 응답 헤더를 사용 Cache-Control하고 Expires동일한 작업을 수행 할 수 있습니다. 또는 301응답을 전혀 캐시하지 않으려면 다음 헤더를 사용하십시오.

Cache-Control: no-store, no-cache, must-revalidate
Expires: Thu, 01 Jan 1970 00:00:00 GMT

답변

http 리디렉션 (예 : 301, 307 등)을위한 브라우저 캐시를 제거하는 매우 간단한 방법이 있습니다.

개발자 콘솔에서 네트워크 패널을 크롬으로 열 수 있습니다. 네트워크 통화를 선택하십시오. 마우스 오른쪽 버튼으로 클릭 한 다음 브라우저 캐시 지우기 를 클릭 하여 캐시 된 리디렉션을 제거하십시오.

답변

확인 !! 사용자가 영향을받는 URL에 게시 요청을 제출하도록하고 캐시 된 리디렉션을 잊어 버립니다.

가능한 경우 브라우저 콘솔에 입력하면됩니다.

fetch('example.com/affected/link', {method: 'post'}).then(() => {})

영향을받는 브라우저 (특히 개발 중)를 알고있는 경우 유용합니다.

또는 이전 301 리디렉션 페이지에 액세스 할 수있는 경우이 스크립트를 페이지에 추가하고 방문 할 때마다 캐시 된 301을 잊어 버릴 수 있습니다.