304를 반환하는 요청을 방지하는 방법

304를 반환하는 요청을 방지하는 방법

---

브라우저는 언제 서버에 파일을 요청하지 않습니까?

즉, JavaScript 파일이 제공되고 있습니다. 그것의 HTTP 응답 헤더는이 ETag, Cache-Control: public그리고 Expires: Tue, 19 Jan 2038 03:14:07 GMT.

서버는 304브라우저 캐시가 준비된 후 a 를 반환합니다 .

내 질문은 왜 브라우저가 서버를 확인 304하고 처음부터 확인하는 것입니까? 나는 브라우저가 새 버전이 있는지 묻고 싶지 않습니다. 스크립트를 제공하는 서버의 수정 사항을 확인하지 않고 브라우저 캐시에서 직접로드해야합니다.

이 작업을 수행하는 HTTP 응답 헤더 조합은 무엇입니까?

---

첫째, 관련 HTTP 사양은 RFC 7234 입니다. 사양을 살펴보면 다음 두 가지를 볼 수 있습니다.

• 사양 은 어떤 상황에서도 캐시가 재 검증없이 캐시 된 버전의 콘텐츠를 제공하도록 요구 하지 않습니다 . 사양에서 캐시가 요청을 충족시키기 위해 캐시 된 콘텐츠를 사용해서는 안된다고 명시하는 곳이 많이 있지만, 반드시 그렇게해야하거나 재 검증해서는 안된다고 지시하는 곳은 전혀 없습니다. 따라서 브라우저 공급 업체는 원하는 경우 언제든지 재 검증 할 수 있습니다.

• 둘째, 당신은 당신의 입장에서 잘못한 것이 없습니다. 브라우저는 응답을 캐시하고 반환하는 헤더가 주어지면 캐시 된 응답을 사용할 수 있습니다. 요점은 섹션 4 에 있으며 캐시 된 응답을 제공하기위한 조건 중 하나는 응답이 다음 중 하나라는 것입니다.

  • 신선함 (섹션 4.2 참조) 또는

  • 부실로 제공되도록 허용 (섹션 4.2.4 참조) 또는

  • 성공적으로 검증되었습니다 (섹션 4.3 참조).

  Expires먼 미래 의 헤더를 뱉어 내고 있고 미래의 시점에 아직 도달하지 않았으므로 응답은 '신선'이므로 재 검증이 필요하지 않습니다. 그래서 당신은 당신이 당신의 입장에 있어야한다고 제안하는 모든 것을하고 있습니다. ( Cache-Control: max-age=foo사용은 Expires:헤더를 사용하는 것보다 캐시 만료 시간을 설정하는 더 현대적인 방법 이지만 )

따라서 브라우저의 캐싱 동작을 변경하려면 운이 좋지 않습니다.

그러나 상황이 생각만큼 나쁘지는 않을 수도 있습니다. 테스트 할 때 브라우저에서 페이지를 새로 고치기 때문에 요청과 304 만 표시 될 것 입니다. 브라우저는 요청이 트리거 된 방법에 따라 캐시 된 리소스를 다르게 처리합니다.

<script>JS 파일을 <img>가리키는 태그, 이미지를 <link>가리키는 태그, CSS 스타일 시트를 가리키는 태그 가 포함 된 HTML 페이지를 만드는 간단한 테스트를 실행했습니다 . 이러한 모든 파일은 다음과 함께 제공되도록 구성된 Apache 서버에서 호스팅되었습니다.

• E-Tag 헤더,
• 최종 수정 날짜,
• Cache-Control: max-age=172800헤더

당연히 모든 리소스는 첫 페이지로드시 200 개의 코드로 제공되었습니다. 그 후 Chrome 또는 Firefox에서 테스트하면 기본 설정으로 설치됩니다.

• 이 경우 새로 고침 통하여, 페이지를 F5키 또는 새로 고침 버튼, 페이지의 모든 자원을 재 검증 (즉, 요청이 각 리소스에 대한 서버로 만들어 304이 반환됩니다).
• 새 탭에서 URL 표시 줄에 링크 나 URL을 입력을 통해 페이지로 돌아 경우 에는 재 검증 (즉 더 요청이 이루어지지 않습니다) 수행되지 않습니다.
• Chrome에서 URL 표시 줄을 선택하고 Enter 키를 눌러 페이지를 새로 고치면 페이지 자체가 재 검증되지만 다른 리소스는 수행하지 않습니다. Firefox에서는 페이지 나 리소스의 유효성을 다시 검사하지 않습니다.

이 페이지 는 Internet Explorer의 동작이 동일 함을 나타냅니다.

Internet Explorer가 캐시 된 항목이 유효한지 여부를 확인해야하는 여러 상황이 있습니다.

• 캐시 된 항목에는 만료 날짜가 없으며 브라우저 세션에서 처음으로 콘텐츠에 액세스합니다.
• 캐시 된 항목에 만료 날짜가 있지만 만료되었습니다.
• 사용자가 새로 고침 버튼을 클릭하거나 F5를 눌러 페이지 업데이트를 요청했습니다.

즉, 일반적으로 사용자가 명시 적으로 페이지를 새로 고치는 경우에만 이러한 재확인 요청이 표시됩니다. 브라우저 캐시의 동작 방식에 대한 매우 특별한 요구 사항이없는 한이 동작은 완벽하게 합리적으로 보입니다.

Google 과 Mozilla는 모두 HTTP 캐싱에 대한 문서를 가지고 있지만 (MSDN 또는 Apple Developers 사이트에서 이에 상응하는 것을 찾을 수 없습니다), 브라우저가 사용하는 규칙을 수정하는 데 사용할 수있는 공급 업체별 캐싱 헤더의 존재를 암시하지 않습니다. 재 검증시기를 선택합니다. 당신이 원하는 것은 단순히 불가능합니다.

이 동작에 대해 더 많은 제어가 필요한 경우 HTML5 애플리케이션 캐시를 살펴 보거나 basket.js 처럼 HTML5 로컬 저장소를 사용하여 자체 캐싱 논리를 롤링 할 수 있습니다 .

---

Expires:또는 Cache-Control: max-age=작동해야합니다. 브라우저가 실제로 네트워크 호출을하고 있음을 서버 로그에서 확인 했습니까? 예를 들어, 방화범이 실제로 캐시에 도달 할 때 원격 호출을한다는 것을 암시하는 혼란스러운 출력을 발견했습니다.

---

내 보트에 있고 Angular 앱이 IIS에 배포되어 있다면 다음과 같이 web.config가 URL을 올바르게 다시 작성하도록 구성되어 있는지 확인하십시오.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpErrors errorMode="Detailed" />
        <rewrite>
            <rules>
                <rule name="Angular Routes" stopProcessing="true">
                    <match url=".*" />
                    <conditions logicalGrouping="MatchAll">
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
                    </conditions>
                    <action type="Rewrite" url="/NameOfYourApp_UnderDefaultWebSite/" />
                </rule>
            </rules>
        </rewrite>
  </system.webServer>
</configuration>

특히 URL의 값을 <action type="Rewrite" url="/NameOfYourApp_UnderDefaultWebSite/" />

---

There is a rule that setting an Expires header more than one year in the future violates the HTTP 1.1 RFC.

So, HTTP response header here is invalid (Expires: Tue, 19 Jan 2038 03:14:07 GMT). Fixing this may solve the problem!

ReferenceURL : https://stackoverflow.com/questions/26166433/how-to-prevent-request-that-returns-304