If-Unmodified-Since

사용법

클라이언트는 다른 쪽이 만든 변경 사항을 덮어쓰지 않도록 If-Unmodified-Since를 포함시킵니다. 가장 흔한 시나리오는 HTTP PUT이나 DELETE 요청으로, 클라이언트가 리소스가 앞서 관찰한 상태 그대로임을 확신해야 하는 경우입니다. 헤더에 적힌 날짜 이후에 다른 클라이언트가 리소스를 수정했다면 서버는 412 Precondition Failed 응답으로 요청을 거부합니다.

이는 업데이트 유실 문제를 해결합니다. 두 클라이언트가 같은 리소스를 가져와 각자 편집한 뒤 둘 다 업데이트를 보냅니다. 전제 조건이 없으면 두 번째 업데이트가 첫 번째를 조용히 덮어씁니다. 두 번째 요청에 If-Unmodified-Since를 추가하면 서버가 충돌을 감지할 수 있습니다.

헤더 값은 HTTP 날짜 형식을 사용합니다. 서버는 이 날짜를 리소스의 Last-Modified 타임스탬프와 비교합니다. 리소스의 수정 날짜가 If-Unmodified-Since의 값과 같거나 그보다 이르면 조건이 통과하고 서버는 처리를 계속합니다.

더 강력한 일관성 보장이 필요하면 ETag 값을 사용하는 If-Match를 선호하십시오. ETag는 바이트 수준의 정밀도를 제공하지만, 날짜 기반 조건은 1초 단위의 해상도를 가집니다.

HTTP-date

값은 IMF-fixdate 형식을 따릅니다. 이 날짜는 해당 리소스에 허용되는 가장 늦은 수정 시각을 나타냅니다.

If-Unmodified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT

예시

클라이언트가 2025년 2월 15일에 문서를 가져왔고 이제 업데이트를 보냅니다. If-Unmodified-Since 값은 원래 응답에서 받은 Last-Modified 날짜와 일치합니다. 이 타임스탬프 이후 문서가 변경되었다면 서버는 412 Precondition Failed로 응답합니다.

PUT /docs/report.json HTTP/1.1
Host: api.example.re
Content-Type: application/json
If-Unmodified-Since: Sat, 15 Feb 2025 10:30:00 GMT

부분 업로드를 위한 Range 요청과 함께 사용하면 If-Unmodified-Since는 청크 사이에 기반 리소스가 변경되지 않았음을 보장합니다.

PATCH /files/dataset.csv HTTP/1.1
Host: api.example.re
If-Unmodified-Since: Fri, 14 Feb 2025 08:00:00 GMT
Content-Range: bytes 0-1023/4096