다음을 통해 공유


ASP.NET Core Blazor 앱을 업그레이드할 때 HTTP 캐싱 문제 방지

참고 항목

이 문서의 최신 버전은 아닙니다. 현재 릴리스는 이 문서의 .NET 8 버전을 참조 하세요.

Important

이 정보는 상업적으로 출시되기 전에 실질적으로 수정될 수 있는 시험판 제품과 관련이 있습니다. Microsoft는 여기에 제공된 정보에 대해 어떠한 명시적, 또는 묵시적인 보증을 하지 않습니다.

현재 릴리스는 이 문서의 .NET 8 버전을 참조 하세요.

Blazor 앱을 잘못 업그레이드하거나 구성하면 기존 사용자가 원활하게 업그레이드할 수 없습니다. 이 문서에서는 주요 버전에서 앱을 업그레이드 Blazor 할 때 발생할 수 있는 몇 가지 일반적인 HTTP 캐싱 문제에 대해 설명합니다. 또한 사용자에게 원활한 전환을 보장하기 위한 몇 가지 권장 조치도 제공합니다.

향후 Blazor 릴리스는 HTTP 캐싱 문제를 처리하기 위한 더 나은 솔루션을 제공할 수 있지만 궁극적으로 캐싱을 올바르게 구성하는 것은 앱에 달려 있습니다. 적절한 캐싱 구성을 사용하면 앱의 사용자가 항상 최신 버전의 앱을 갖도록 하여 환경을 개선하고 오류가 발생할 가능성을 줄입니다.

사용자 업그레이드 환경에 부정적인 영향을 주는 일반적인 문제는 다음과 같습니다.

  • 프로젝트 및 패키지 업데이트의 잘못된 처리: 동일한 주 프레임워크 버전을 사용하도록 앱의 배포된 프로젝트를 모두 업데이트하지 않거나 최신 버전을 주 업그레이드의 일부로 사용할 수 있는 경우 이전 버전의 패키지를 사용하는 경우에 발생합니다.
  • 캐싱 헤더의 잘못된 구성: HTTP 캐싱 헤더는 앱의 응답이 캐시되는 방법, 위치 및 기간을 제어합니다. 헤더가 올바르게 구성되지 않은 경우 사용자는 부실 콘텐츠를 받을 수 있습니다.
  • 다른 계층의 잘못된 구성: CDN(콘텐츠 배달 네트워크) 및 배포된 앱의 다른 계층은 잘못 구성된 경우 문제를 일으킬 수 있습니다. 예를 들어 CDN은 성능을 향상시키고 대기 시간을 줄이기 위해 콘텐츠를 캐시하고 제공하도록 설계되었습니다. CDN이 캐시된 버전의 자산을 잘못 제공하는 경우 사용자에게 오래된 콘텐츠 배달이 발생할 수 있습니다.

업그레이드 문제 감지 및 진단

업그레이드 문제는 일반적으로 브라우저에서 앱을 시작하지 못한 것으로 나타납니다. 일반적으로 경고는 부실 자산 또는 앱이 없거나 일치하지 않는 자산이 있음을 나타냅니다.

  • 먼저 앱이 클린 브라우저 인스턴스 내에서 성공적으로 로드되는지 검사. 프라이빗 브라우저 모드를 사용하여 Microsoft Edge InPrivate 모드 또는 Google Chrome Incognito 모드와 같은 앱을 로드합니다. 앱이 로드되지 않는 경우 하나 이상의 패키지 또는 프레임워크가 올바르게 업데이트되지 않았음을 의미합니다.
  • 앱이 클린 브라우저 인스턴스에서 올바르게 로드되는 경우 앱이 부실 캐시에서 제공될 가능성이 높습니다. 대부분의 경우 Ctrl+F5를 사용하여 하드 브라우저 새로 고침은 캐시를 플러시하므로 앱이 최신 자산으로 로드 및 실행되도록 허용합니다.
  • 앱이 계속 실패하는 경우 부실한 CDN 캐시가 앱을 제공하고 있는 것일 수 있습니다. CDN 공급자가 제공하는 메커니즘을 통해 DNS 캐시를 플러시해 보세요.

앱을 제공하기 위한 이전 프로세스는 업데이트 프로세스를 더 어렵게 만들 수 있습니다. 예를 들어 과거에 캐싱 헤더를 피하거나 잘못 사용하면 사용자에게 현재 캐싱 문제가 발생할 수 있습니다. 다음 섹션의 작업을 수행하여 문제를 완화하고 사용자의 업그레이드 프로세스를 개선할 수 있습니다.

프레임워크 버전을 사용하여 프레임워크 패키지 정렬

프레임워크 패키지가 프레임워크 버전과 일치하는지 확인합니다. 최신 버전을 사용할 수 있는 경우 이전 버전의 패키지를 사용하면 호환성 문제가 발생할 수 있습니다. 또한 앱의 배포된 모든 프로젝트가 동일한 주 프레임워크 버전을 사용하도록 하는 것도 중요합니다. 이러한 일관성은 예기치 않은 동작 및 오류를 방지하는 데 도움이 됩니다.

올바른 캐싱 헤더가 있는지 확인합니다.

올바른 캐싱 헤더는 리소스 요청에 대한 응답에 있어야 합니다. 여기에는 , Cache-Control및 기타 캐싱 헤더가 포함ETag됩니다. 이러한 헤더의 구성은 호스팅 서비스 또는 호스팅 서버 플랫폼에 따라 달라집니다. 스크립트(blazor.webassembly.js) 및 스크립트가 다운로드하는 모든 항목과 같은 Blazor 자산에 특히 중요합니다.

잘못된 HTTP 캐싱 헤더도 서비스 근로자에게 영향을 미칠 수 있습니다. 서비스 작업자는 캐시된 리소스를 효과적으로 관리하기 위해 캐싱 헤더를 사용합니다. 따라서 잘못된 헤더 또는 누락된 헤더는 서비스 작업자의 기능을 방해할 수 있습니다.

브라우저에서 상태를 삭제하는 데 사용 Clear-Site-Data

브라우저에서 헤더Clear-Site-Data 사용하여 상태를 삭제하는 것이 좋습니다.

일반적으로 캐시 상태 문제의 원인은 HTTP 브라우저 캐시로 제한되므로 지시문을 사용하는 cache 것으로 충분해야 합니다. 이 작업은 브라우저가 캐시에서 부실 콘텐츠를 제공하는 대신 서버에서 최신 리소스를 가져오는 데 도움이 될 수 있습니다.

필요에 따라 HTTP 브라우저 캐시를 storage 지우는 동시에 로컬 스토리지 캐시를 지우는 지시문을 포함할 수 있습니다. 그러나 클라이언트 스토리지를 사용하는 앱은 지시문을 사용하는 경우 storage 중요한 정보가 손실될 수 있습니다.

스크립트 태그에 쿼리 문자열 Blazor 추가

이전 권장 작업이 효과적이지 않거나 배포에 사용할 수 있거나 앱에 적용할 수 없는 경우 스크립트의 <script> 태그 원본에 쿼리 문자열을 일시적으로 추가하는 것이 Blazor 좋습니다. 이 작업은 대부분의 상황에서 브라우저가 로컬 HTTP 캐시를 우회하고 새 버전의 앱을 다운로드하도록 강제하는 데 충분해야 합니다. 앱에서 쿼리 문자열을 읽거나 사용할 필요가 없습니다.

다음 예제에서는 쿼리 문자열 temporaryQueryString=1 이 태그의 상대 외부 원본 URI에 <script> 일시적으로 적용됩니다.

<script src="_framework/blazor.webassembly.js?temporaryQueryString=1"></script>

앱의 모든 사용자가 앱을 다시 로드한 후에는 쿼리 문자열을 제거할 수 있습니다.

또는 관련 버전 관리가 포함된 영구 쿼리 문자열을 적용할 수 있습니다. 다음 예제에서는 앱 버전이 .NET 릴리스 버전(.NET 8용)8 과 일치한다고 가정합니다.

<script src="_framework/blazor.webassembly.js?version=8"></script>

스크립트 태그의 위치는 Blazor ASP.NET Core Blazor 프로젝트 구조를 참조하세요.<script>