브라우저에서 iframe 캐싱 방지

88

Firefox와 Safari가 iframe 콘텐츠를 캐싱하지 못하도록하려면 어떻게해야합니까?

다른 사이트의 페이지에 iframe이있는 간단한 웹 페이지가 있습니다. 외부 페이지와 내부 페이지에는 모두 캐시를 방지하기 위해 HTTP 응답 헤더가 있습니다. 브라우저에서 "뒤로"버튼을 클릭하면 외부 페이지가 제대로 작동하지만 브라우저는 항상 iframed 페이지의 캐시를 검색합니다. IE는 잘 작동하지만 Firefox와 Safari가 문제를 일으키고 있습니다.

내 웹 페이지는 다음과 같습니다.

<html>
  <head><!-- stuff --></head>
<body>
  <!-- stuff -->
  <iframe src="webpage2.html?var=xxx" />
  <!-- stuff -->
</body>
</html>

var변수는 항상 변경합니다. iframe의 URL이 변경 되었음에도 불구하고 (따라서 브라우저가 해당 페이지에 대해 새 요청을해야 함) 브라우저는 캐시 된 콘텐츠를 가져옵니다.

HTTP 요청과 응답을 앞뒤로 조사한 결과, 외부 페이지에이 포함되어 있어도 <iframe src="webpage2.html?var=222" />브라우저는 여전히 webpage2.html?var=111.

지금까지 시도한 내용은 다음과 같습니다.

  • 임의의 var 값으로 iframe URL 변경
  • Expires, Cache-Control 및 Pragma 헤더를 외부 웹 페이지에 추가
  • 내부 웹 페이지에 Expires, Cache-Control 및 Pragma 헤더 추가

동일 출처 정책에 의해 차단 되었기 때문에 JavaScript 트릭을 수행 할 수 없습니다.

아이디어가 부족합니다. 누구든지 브라우저가 iframed 콘텐츠를 캐싱하는 것을 중지하는 방법을 알고 있습니까?

최신 정보

Daniel이 다른 테스트를 수행 할 것을 제안한대로 Fiddler2를 설치했지만 안타깝게도 여전히 동일한 결과를 얻고 있습니다.

이것은 내가 수행 한 테스트입니다.

  1. 외부 페이지 Math.random()는 JSP에서 사용하여 난수를 생성 합니다.
  2. 외부 페이지는 웹 페이지에 임의의 숫자를 표시합니다.
  3. 외부 페이지는 iframe을 호출하여 임의의 숫자를 전달합니다.
  4. 내부 페이지는 임의의 숫자를 표시합니다.

이 테스트를 통해 업데이트중인 페이지와 캐시 된 페이지를 정확하게 확인할 수 있습니다.

시각적 테스트

빠른 테스트를 위해 페이지를로드하고 다른 페이지로 이동 한 다음 "뒤로"를 누릅니다. 결과는 다음과 같습니다.

원본 페이지 :

  • 외부 페이지 : 0.21300034290246206
  • 내부 페이지 : 0.21300034290246206

페이지를 떠난 후 다시 누르십시오.

  • 외부 페이지 : 0.4470929019483644
  • 내부 페이지 : 0.21300034290246206

이는 외부 페이지가 URL에서 다른 GET 매개 변수를 사용하여 호출하더라도 내부 페이지가 캐시되고 있음을 보여줍니다. 어떤 이유로 브라우저는 iframe이 새 URL을 요청한다는 사실을 무시합니다. 단순히 이전 것을로드합니다.

피들러 테스트

물론 Fiddler도 똑같은 사실을 확인합니다.

(페이지를로드합니다.)

외부 페이지가 호출됩니다. HTML :

0.21300034290246206
<iframe src="http://ipv4.fiddler:1416/page1.aspx?var=0.21300034290246206" />

http : //ipv4.fiddler : 1416 / page1.aspx? var = 0.21300034290246206 이 호출됩니다.

(나는 페이지를 벗어나서 뒤로 쳤다.)

외부 페이지가 호출됩니다. HTML :

0.4470929019483644
<iframe src="http://ipv4.fiddler:1416/page1.aspx?var=0.4470929019483644" />

http : //ipv4.fiddler : 1416 / page1.aspx? var = 0.21300034290246206 이 호출됩니다.

이 테스트에서 웹 브라우저가 페이지를 캐싱하지 않는 것처럼 보이지만 iframe의 URL을 캐싱 한 다음 해당 캐싱 된 URL에 대해 새 요청을 만드는 것입니다. 그러나이 문제를 해결하는 방법에 대해 여전히 난처합니다.

웹 브라우저가 iframe URL을 캐싱하지 못하도록하는 방법에 대한 아이디어가 있습니까?

browser  caching  iframe  back-button 
— JR.
소스
11
+1-당신의 글은 고통을 아주 멋지게 포착합니다.
— nickf 2012 년
1
문제에 대한 매우 상세한 설명에 감사드립니다. 이것은 제가 사이트에서 경험하고있는 것과 정확히 100 %입니다. 7 년이 지났고 파이어 폭스 버그 보고서 가 여전히 존재합니다.
— Scuzzy

답변:

-3

iframe의 URL이 iframe의 실제 콘텐츠를 검색하고 반환하는 프록시 역할을하는 사이트의 페이지를 가리 키도록합니다. 이제 더 이상 동일 출처 정책에 구속되지 않습니다 (편집 : iframe 캐싱 문제를 방지하지 않음).

— kmoser
소스
41
이것은 캐시를 방지하지 않습니다.
— baash05
@ baash05 나는 그것을 주장하지 않았다; 나는 그것이 동일 출처 정책을 피한다고 말했습니다.
— kmoser
1
사실 ..하지만 op 제목은 "브라우저에서 iframe 캐싱 방지"로 표시되며 귀하의 답변이 브라우저에서 iframe 캐싱을 방지하지 않는다면 실제로는 답변이 아닙니다. 아는 것은 깔끔하지만 캐싱을 방지하려는 사람에게는 여전히 좋은 조언이 아닙니다.
— baash05
영업 이익은 캐싱을 해결하기 위해 찾고 있었어요 와 동일 출처 정책을 피할 수 있습니다. 부분적인 대답이없는 것보다 낫습니다 :)
— kmoser
2
토스트 항상 잼 측면 아래로 : 폭포
— baash05
59

이것은 Firefox의 버그입니다.

https://bugzilla.mozilla.org/show_bug.cgi?id=356558

이 해결 방법을 시도하십시오.

<iframe src="webpage2.html?var=xxx" id="theframe"></iframe>

<script>
var _theframe = document.getElementById("theframe");
_theframe.contentWindow.location.href = _theframe.src;
</script>
— Caleb
소스
3
오늘 27.2.2014이 스레드를 발견하게되어 기쁩니다. 서버 측의 캐싱을하지 않으면 해결할 수 있다고 생각했습니다. FF 27에는 여전히이 버그가 있습니다.
— Robert
7
7.8.2014-8 년 후, 아직 수정되지 않았습니다.
— Łukasz Zaroda
이것은 srcdoc 속성에도 적용됩니다. 너무 이상합니다.
— elundmark 2014
2
Chrome에서 이와 동일한 캐싱 문제를 발견했으며 두 줄의 JavaScript로 해결되었습니다. 감사합니다!
— Thorn
2
와, 똑같은 문제가있었습니다. Firefox에만 해당됩니다. IE, Chrome 등에서 잘 작동했습니다. 감사합니다. @caleb. 이것이 그렇게 오래 지속되었다는 것을 믿을 수 없습니다.
— Voodoo
33

nameiframe에 고유 한 속성을 설정하여이 버그를 해결할 수있었습니다. 어떤 이유로 든 캐시가 망가진 것 같습니다. 어떤 동적 데이터를 name속성으로 사용하거나 사용중인 템플릿 언어에서 현재 ms 또는 ns 시간을 사용할 수 있습니다. 이것은 JS를 직접 요구하지 않기 때문에 위의 것보다 더 좋은 솔루션입니다.

제 특별한 경우에는 iframe이 JS를 통해 빌드되고 있습니다 (그러나 PHP, Ruby 등을 통해 동일한 작업을 수행 할 수 있음) Date.now().

return '<iframe src="' + src + '" name="' + Date.now() + '" />';

이것은 내 테스트의 버그를 수정합니다. window.name내부 창이 변경 되었기 때문일 것입니다 .

— STRML
소스
2
이 답변은 2015 년 말부터 Chrome, Firefox 및 Safari에서 작동합니다.
— rovermicrover
13

말했듯이 여기서 문제는 iframe 콘텐츠 캐싱 이 아니라 iframe url 캐싱 입니다.

2018 년 9 월 현재 Chrome에서는 문제가 계속 발생하지만 Firefox에서는 발생하지 않는 것 같습니다.

나는 많은 것을 시도했다 (변경 GET 매개 변수 추가, onbeforeunload에서 iframe URL 지우기, 쿠키를 사용하여 "캐시에서 다시로드"감지, 다양한 응답 헤더 설정).

1- 쉬운 방법 : 자바 스크립트에서 동적으로 iframe 생성

예를 들면 :

const iframe = document.createElement('iframe')
iframe.id = ...
...
iframe.src = myIFrameUrl 
document.body.appendChild(iframe)

2- 복잡한 방법

여기 에 설명 된대로 서버 측에서는 iframe 또는 상위 페이지에 대해 제공하는 콘텐츠에 대해 콘텐츠 캐싱을 사용 중지 합니다 (둘 중 하나라도 사용).

과

다음과 같이 추가 변경 검색 매개 변수를 사용하여 자바 스크립트에서 iframe URL을 설정합니다.

const url = myIFrameUrl + '?timestamp=' + new Date().getTime()
document.getElementById('my-iframe-id').src = url

(단순 버전, 다른 검색 매개 변수에주의)

— 스테파니 643
소스
5

다른 모든 것을 시도한 후 (iframe 콘텐츠에 프록시 사용 제외) 동일한 도메인에서 iframe 콘텐츠 캐싱을 방지하는 방법을 찾았습니다 .

사용 .htaccess및 재 작성 규칙과 iframe이 변경 src속성을.

RewriteRule test/([0-9]+)/([a-zA-Z0-9]+).html$ /test/index.php?idEntity=$1&token=$2 [QSA]

이것을 사용하는 방법은 iframe의 URL이 다음과 같이 보입니다. example.com/test/54/e3116491e90e05700880bf8b269a8cc7.html

여기서 [token]은 무작위로 생성 된 값입니다. 이 URL은 토큰이 동일하지 않기 때문에 iframe 캐싱을 방지하고, iframe은 단일 새로 고침이 완전히 다른 URL을로드하기 때문에 완전히 다른 웹 페이지라고 생각합니다.

example.com/test/54/e3116491e90e05700880bf8b269a8cc7.html
example.com/test/54/d2cc21be7cdcb5a1f989272706de1913.html

둘 다 같은 페이지로 연결됩니다.

숨겨진 URL 매개 변수에 액세스 할 수 있습니다. $_SERVER["QUERY_STRING"]

— 제프 노엘
소스
1
나를 위해 일했습니다-감사합니다!
— Quinn Finney
@QuinnFinney 다행이 다른 사람에게 유용했습니다. 이 문제를 해결하는 데 며칠이 걸렸습니다. :)
— Jeff Noel
맞아요 저도 요! hahaha
— Quinn Finney
3

iframe이 항상 새로운 콘텐츠를로드하도록하려면 현재 Unix 타임 스탬프를 GET 매개 변수 끝에 추가하세요. 그러면 브라우저는이를 '다른'요청으로 인식하고 새 콘텐츠를 찾습니다.

자바 스크립트에서는 다음과 같이 보일 수 있습니다.

frames['my_iframe'].location.href='load_iframe_content.php?group_ID=' + group_ID + '&timestamp=' + timestamp;
— 디비전 6
소스
3

2016 년 3 월 17 일 현재 Mac OS X의 최신 Safari뿐만 아니라 최신 Chrome에서이 문제를 발견했습니다. src를 비어있는 상태로 할당 한 다음 일부 사이트에 추가하는 등 위의 수정 사항 중 어느 것도 저에게 효과가 없었습니다. 무작위로 이름이 지정된 "이름"매개 변수를 사용하거나 해시 후 URL 끝에 임의의 숫자를 추가하거나 src를 할당 한 후 src에 콘텐츠 창 href를 할당합니다.

제 경우에는 Javascript를 사용하여 IFRAME을 업데이트하고 URL의 해시 만 전환했기 때문입니다.

제 경우의 해결 방법은 다른 페이지로 0 초 메타 리디렉션이있는 중간 URL을 생성하는 것입니다. 너무 빨리 일어나서 화면 깜박임이 거의 눈에 띄지 않습니다. 또한 중간 페이지의 배경색을 다른 페이지와 동일하게 만들어 눈에 띄지 않게했습니다.

— Volomike
소스
0

2016 년 iOS Safari에서도이 문제가 발생했습니다. 나를 위해 작동하는 것처럼 보이는 것은 iframe src에 GET 매개 변수를 제공하고 이와 같은 값을 지정하는 것입니다.

<iframe width="60%" src="../other/url?cachebust=1" allowfullscreen></iframe>

— Lauri Kääriäinen
소스
-1

Fiddler2 를 설치 했습니까 ?

요청 된 내용, 반환되는 내용 등을 정확하게 볼 수 있습니다. 브라우저가 다른 URL에 대해 캐시에 실제로 도달하는 것은 그럴듯하게 들리지 않습니다.

— 다니엘 이어 위커
소스
1
Fiddler2에 대한 팁을 주셔서 감사합니다. 이제 브라우저가 iframe 콘텐츠를 캐싱하지 않는다는 것을 알고 있습니다. 단순히 iframe URL을 캐싱하는 것입니다. 그러나 나는 여전히 혼란스럽고 브라우저가 새 페이지의 iframe URL을 무시하고 단순히 이전 URL을 사용하는 이유를 모르겠습니다.
— JR.
-1

당신이 얻고 싶은 경우에 정말 미친 당신은 항상 오히려 쿼리 문자열 옵션보다, 같은 페이지에 해결하는 동적 URL로 페이지 이름을 구현할 수 있을까?

사무실에 있다고 가정하면 네트워크 수준에서 진행중인 캐싱이 있는지 확인합니다. 저를 믿으십시오. 가능성입니다. IT 담당자는 HTTP 캐싱과 관련된 네트워크 인프라가 있는지 알려줄 수 있지만, 이는 iframe에서만 발생하기 때문에 발생하지 않을 것입니다.

— 크리스 웹
소스
-2

iframe 페이지에 no-cache에 대한 다양한 HTTP 헤더 옵션을 추가해 보셨습니까?

— 크리스 웹
소스
예. 각 페이지의 HTTP 헤더와 메타 태그 모두에서 no-cache 지시문을 시도했습니다.
— JR.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.