요약

  • 2010년 5월의 RFC 5861은 독립 제출 정보 문서로, 검증 중 옛 응답을 내보내는 stale-while-revalidate와 오류 때 옛 응답을 쓰는 stale-if-error를 따로 정의했다.
  • 예시는 두 시계를 구분한다. max-age=600, stale-while-revalidate=30은 10분의 신선도와 추가 30초를 뜻한다. max-age=600, stale-if-error=1200에서는 총 나이 900초에 나온 500을 Age: 900이 붙은 저장된 200으로 대신할 수 있다.
  • 2022년 6월의 RFC 9111은 오래된 응답을 보내려면 명시적 허가가 필요하다는 경계를 유지하고, 예전 Warning 필드를 폐지했다.

새 확인보다 오래된 문서가 빨리 온다

캐시는 같은 내용을 매번 원본 서버에서 가져오는 일을 줄이려고 응답을 저장한다. 신선한 기간이 지나면 사본이 아직 맞는지 확인해야 한다. 내용이 그대로여도 네트워크 왕복과 서버 처리에는 시간이 든다. 독자 가까이에 사본이 있어도 확인이 끝날 때까지 기다리게 된다.

RFC 5861은 게시자가 짧은 여유를 줄 수 있게 했다. Cache-Control: max-age=600, stale-while-revalidate=30이면 처음 600초는 신선하다. 뒤따르는 30초 동안 캐시는 오래된 사본을 먼저 보내고 백그라운드에서 원본에 확인을 요청할 수 있다. 독자는 즉시 페이지를 보고, 확인 결과는 뒤따르는 요청에 반영된다. 게시자는 수정 내용이 잠깐 늦게 보이는 비용을 받아들인 셈이다.

그 30초 안에 확인을 일으키는 요청이 없거나 확인 결과가 불분명해도 여유 시간은 끝난다. 이후의 요청은 일반 처리 과정을 기다린다. 방문이 드문 페이지는 속도 향상을 거의 누리지 못한다. 여유 시간의 길이와 실제 요청 빈도가 성능을 결정한다. 캐시가 오래된 사본을 내보내더라도 사본이 갑자기 새것이 되는 것은 아니다.

200 뒤에 숨은 원본의 오류

stale-if-error는 다른 사건에 반응한다. 캐시가 최신 답을 얻으려다 500, 502, 503, 504로 이어질 상황을 만난다. 미리 정한 나이 한도 안이라면 오래된 성공 사본을 보내도 된다. 클라이언트는 현재 원본의 실패 대신 이전에 성공한 내용을 받는다.

RFC의 예시 응답에는 max-age=600, stale-if-error=1200이 적혀 있다. 총 나이 900초에 검증을 시도했더니 원본이 500을 보낸다. 캐시는 저장된 본문을 200 OK와 Age: 900으로 전달할 수 있다. 200은 이번에 전달된 사본의 상태를 나타내고, Age는 원본 생성이나 마지막 성공 검증 이후 흐른 시간을 보여 준다. 장애는 사라진 것이 아니라 제한된 시간 동안 독자 앞에서 가려졌다.

추가 1,200초는 신선한 600초 뒤에 이어진다. 예시에서 총 나이가 1,800초를 넘으면 오류를 고객에게 통과시켜야 한다. 기록 보관용 페이지는 짧은 장애 때 20분 전 내용을 보여 주는 편이 나을 수 있다. 권한이나 결제 정보는 같은 20분이 위험할 수 있다. 허용할 나이는 가동률 숫자보다 내용의 결과를 보고 정해야 한다.

두 지시어를 하나의 “오래된 내용 허용” 옵션으로 뭉개면 원인이 사라진다. stale-while-revalidate는 진행 중인 확인의 지연을 숨긴다. stale-if-error는 확인 실패를 덮는다. 각자 다른 조건과 상한이 있다. 원본 게시자가 범위를 정하고 캐시가 그 안에서 실행한다.

경고 표지는 먼저 퇴장했다

2010년 문서는 당시 규칙에 따라 오래된 응답에 0보다 큰 Age와 Warning을 예상했다. RFC 9111은 2022년에 Warning을 폐지했다. 실제로 거의 생성되지 않았고 사용자에게 표시되는 일도 드물었기 때문이다. Age는 원본이 응답을 만들거나 성공적으로 검증한 뒤의 시간을 추정한다. 오늘날 200만 보고 최신 원본 답이라고 판단하면, 캐시가 가려 준 500을 놓친다.

2022년 표준은 허가의 선도 분명히 그었다. no-cache, must-revalidate 같은 지시가 오래된 응답을 막으면 캐시는 이를 보내지 못한다. 그 밖에도 연결 단절, 고객이나 원본의 명시적 허가, 또는 별도 계약이 필요하다. RFC 5861의 두 확장은 명시적 허가의 사례로 언급된다. 캐시는 모든 저장 내용의 유효 기간을 제멋대로 정하는 기관이 아니다.

RFC 5861은 독립 제출 정보 문서였고, RFC 9111은 2022년의 표준 경로 캐시 규격이다. 뒤의 문서가 앞의 확장을 허가의 예로 든다는 사실은 규칙의 자리를 보여 준다. 실제 도입을 확인하려면 날짜가 남은 응답 헤더, 캐시 설정, 장애 때의 통신 기록이 필요하다. 문서상의 거래는 뚜렷하다. 원본은 옛 답의 허용 시간을 주고, 캐시는 그 시간으로 속도와 연속성을 산다.