Summary

  • 2015년 W3C의 첫 공개 초안은 사이트 데이터가 브라우저 곳곳에 흩어져 있고 페이지 스크립트 하나로는 모두 치울 수 없다는 문제를 짚었다.
  • 2017년 작업 초안은 응답 헤더 Clear-Site-Data에 cache, cookies, storage, executionContexts 또는 *를 적어 브라우저에 정리를 요청하는 형식을 제시했다.

화면은 “로그아웃 완료”라고 말한다. 기기에는 아직 방문의 흔적이 남는다. 세션을 나타내던 쿠키, 오프라인에서 쓰던 로컬 데이터, 다시 열 때 시간을 아껴 주는 캐시, 켜진 채 돌아가는 탭이 각각 다른 자리를 차지한다. 현관에 폐점 표지를 붙였다고 창고까지 청소되는 것은 아니다.

W3C가 2015년 8월 공개한 첫 초안은 이 어색한 청소를 다뤘다. JavaScript로 없앨 수 있는 데이터가 있지만 HttpOnly 쿠키에는 손댈 수 없다. 그 쿠키를 스크립트에서 지키려는 설계다. HTTP 응답으로 쿠키를 만료시키려면 사이트는 자신이 설정한 쿠키를 빠짐없이 알고 있어야 한다. 저장소와 캐시는 또 다른 청소 방법을 요구했다. 버튼 하나 뒤에 열쇠 꾸러미가 매달린 셈이다.

초안은 부탁할 통로를 바꾸었다. 사이트가 HTTP 응답에 지울 대상을 적으면, 로컬 서랍의 주인인 브라우저가 처리한다. 사이트는 언제 세션을 마치거나 사고를 수습할지 안다. 브라우저는 데이터가 실제로 어디에 쌓였는지 안다. 두 지식을 한 장의 지시서로 잇자는 발상이었다.

2017년 11월 작업 초안에는 지시서의 어휘가 나왔다. Clear-Site-Data 값으로 따옴표를 붙인 "cookies", "storage", "cache", "executionContexts"를 나열한다. 여러 종류를 함께 적을 수 있다. "*"는 이 헤더가 아는 모든 종류를 뜻하며 훗날 추가될 종류도 포함한다. 별표는 큰 빗자루이고, 각각의 이름은 서랍별로 맞는 작은 도구다.

일상적인 로그아웃이라면 쿠키와 저장소를 지우는 응답을 생각할 수 있다. 로그인 흔적과 현지에 남은 자료가 함께 빠진다. 초안에는 더 거친 날의 사례도 있다. 침해를 발견한 사이트가 이용자 브라우저에 남았을 수 있는 악성 상태를 없애려고 캐시와 실행 문맥까지 치우는 장면이다. 헤더가 같은 이름을 쓰더라도 지시 목록에 따라 작업의 크기가 달라진다.

서랍마다 경계가 다르다. 저장소는 응답의 오리진에 묶인다. 쿠키는 하위 도메인 사이에서 쓰일 수 있어 초안의 절차는 등록 도메인까지 살핀다. 네트워크 캐시는 호스트를 기준으로 항목을 고른다. 청소를 시작할 응답에는 안전하고 인증된 연결 조건도 붙는다. 브라우저가 사이트의 요청을 듣는다고 해서 다른 사이트의 자료까지 뒤질 만능 열쇠를 주는 것은 아니다.

"executionContexts"는 아직 근무 중인 사람을 찾는 절차다. 쿠키를 지워도 열린 탭의 코드는 곧바로 멈추지 않는다. 워커도 옛 상태를 붙잡고 있을 수 있다. 2017년 초안은 관련 문맥을 준비하고 지정한 데이터를 지운 뒤, 요청된 경우 영향을 받은 화면을 다시 불러오게 한다. 바닥을 닦는 동안 누군가 먼지를 다시 뿌리는 일을 막으려는 것이다.

넓은 청소에는 비용이 따른다. 캐시를 비우면 다음 방문 때 자원을 다시 내려받는다. 등록 도메인의 쿠키를 지우면 여러 하위 도메인의 로그인도 끝날 수 있다. 저장소를 비우면 오프라인 작업물이 사라질 수 있다. 종류를 나누어 적는 이유가 여기 있다. 평범한 퇴장과 사고 뒤의 전면 정리에 같은 빗자루를 들 필요는 없다.

W3C 발행 기록에는 2015년, 2016년, 2017년의 공개 작업 초안이 차례로 놓여 있다. 브라우저가 잠깐 보는 창을 넘어 보관함이 되던 시절의 기록이다. 웹이 기억을 얻자, 작별 인사에도 정리할 방의 목록이 필요해졌다.