두 사용자가 같은 HTTP 자원을 수정합니다. ETag와 If-Match는 낡은 덮어쓰기를 어떻게 막나요?

ETag는 특정 자원 표현의 버전을 식별하는 validator이고 If-Match는 그 버전이 현재와 맞을 때만 변경하라는 조건입니다. 서버는 비교와 변경을 원자적으로 수행해야 합니다.

동작 원리와 전제

A와 B가 같은 ETag를 읽고 A가 먼저 저장하면 B의 조건 요청은 실패해야 합니다. 애플리케이션에서 ETag를 비교한 뒤 조건 없는 DB UPDATE를 하면 그 사이 경쟁이 남으므로 DB version 조건과 연결합니다. If-Match에는 strong comparison 의미가 적용됩니다.

선택과 실패 처리

조건이 맞지 않으면 일반적으로 412로 충돌을 알리고 최신 상태를 읽어 병합하거나 사용자 확인을 받습니다. ETag는 인증 토큰이 아니므로 자원 인가를 별도로 수행합니다. 서로 다른 압축·언어 표현과 실제 변경 버전의 관계도 정해야 합니다.

구체적인 사례와 검증

예를 들어 두 사용자가 ETag v7을 가진 문서를 편집하면 첫 저장은 v8을 만들고 두 번째는 412를 받아야 합니다. 두 번째 요청이 412를 받은 뒤 ETag만 v8로 바꿔 같은 전체 본문을 보내면 첫 사용자의 변경을 지우므로 자동 재시도가 아닙니다. 원래 읽은 문서·사용자 수정·현재 문서를 비교해 충돌을 해결합니다. 조건 요청이 없는 쓰기를 허용할지도 API 정책으로 정하고 필요하면 전제 조건을 요구합니다. 캐시 재검증의 If-None-Match와 쓰기 보호의 If-Match는 사용하는 비교와 목적이 다릅니다. 인가 실패를 version 충돌처럼 반환해 다른 문서의 존재를 노출하지 않는지도 검토합니다.

동시 수정·삭제·동일 내용 재저장·프록시 캐시·권한 철회를 시험합니다. 304 재검증과 변경 전제 조건을 혼동하지 않습니다. 실패 응답을 받았다고 새 ETag로 자동 덮어쓰면 충돌 보호의 목적을 없애는 것이므로 사용자 의도와 병합 정책을 유지합니다.