정의
presigned URL(만료 시간·액세스 서명이 쿼리에 붙은 임시 객체 스토리지 URL)을 HTTP 캐시·Service Worker·프록시 LRU에 넣을 때, 인증·만료용 쿼리만 제거하고 리소스 의미를 바꾸는 쿼리는 유지해, 같은 파일의 중복 캐시와 잘못된 키 충돌을 동시에 피하는 정규화 규칙이다.
왜 필요한가
객체 스토리지 presigned URL은 호출마다 Signature, X-Amz-Expires, X-Amz-Credential 등이 달라진다. URL 전체를 캐시 키로 쓰면 동일 이미지가 서명마다 별도 항목으로 쌓여 hit율이 없고 저장 공간만 낭비한다.
반대로 쿼리를 전부 제거하면 masked=1(마스킹 결과)과 원본이 같은 키로 합쳐져 잘못된 이미지가 보인다. 정규화는 "무엇을 빼고 무엇을 남길지" 명시적 분류가 필요하다.
동작 원리
- URL 파싱:
origin + pathname + searchParams. - strip 목록(예):
X-Amz-*,Signature,Expires,AWSAccessKeyId— 인증·만료 전용. - keep 목록(예):
masked,v,version, 리사이즈w/h— 응답 바이트가 달라지는 의미. - 남은 쿼리를 정렬해 직렬화:
pathname + '?' + sortedParams. - SW·서버 프록시·클라이언트가 동일 규칙을 공유해야 한다.
프록시 패턴: 브라우저는 /api/image-proxy?url=<encoded>만 보면 되고, SW 캐시 키는 프록시 URL 기준으로 정규화한다.
실무 적용
- 404·410 응답 시 해당 키(또는 prefix) purge.
- cache-generation-stale-write-guard와 함께 in-flight revalidate가 옛 바이트를 되살리지 않게 한다.
- CDN
Vary: Accept등과 브라우저 키 정책이 어긋나지 않는지 확인한다.
트레이드오프
- keep 목록이 너무 넓으면 여전히 중복 캐시가 생긴다 — 정말 바이트가 달라지는 파라미터만 남긴다.
- keep 목록이 너무 좁으면 마스킹·리사이즈 변형이 충돌한다.
- 서버와 SW 규칙이 다르면 "프록시는 hit, SW는 miss" 같은 이중 동작이 생긴다.
사용하면 안 되는 경우
- URL 자체가 불변하고 버전이 path에만 있는 CDN(
/v2/asset.png) — 쿼리 strip이 불필요할 수 있다. - 서명이 path 일부에 embedded된 스킴 — 쿼리 규칙만으로는 부족하다.
- 사용자별로 응답 바디가 달라지는데 키를 pathname만 쓰는 경우 — 권한 모델과 충돌한다.
흔한 실수
search전체 삭제로 masked/original 충돌.- 리사이즈
w까지 strip해 다른 크기가 같은 캐시 항목으로 합쳐짐. - SW만 정규화하고 서버 프록시 LRU는 raw URL 사용.
- presigned 만료 후에도 stale 항목을 무한히 serve — revalidate·TTL 정책 필요.
관련 개념
- presigned-url-direct-upload — 업로드용 presigned 발급
- service-worker-stale-while-revalidate — 정규화된 키로 SWR
- server-image-proxy-transcoding-cache — 프록시 쪽 LRU 키 설계