Summary

  • 1997년 1월의 HTTP/1.1 RFC 2068은 브라우저가 Accept-Language에 허용할 언어와 선호도 값을 담아 보내는 방식을 설명했다.
  • 서버가 그 목록으로 판본을 고르면 Vary: Accept-Language가 캐시에 선택 기준을 알려 준다. 캐시는 다음 요청에서 해당 언어 조건을 비교해야 저장된 응답을 다시 쓸 수 있다.

1997년 1월의 RFC 2068에는 덴마크어를 먼저, 영국 영어를 다음으로, 다른 영어를 그 뒤에 놓는 예시가 나온다. 작은 q 값이 순서를 세운다. 브라우저는 주소와 함께 이 주문서를 보낼 수 있으므로, 서버는 첫 화면부터 알맞은 판본을 골라 준다. 손님을 입구의 언어 메뉴 앞에 세워 둘 필요가 없다.

두 번째 손님이 오면 이야기가 복잡해진다. 두 사람 모두 /news를 요청하지만 한 사람은 덴마크어, 다른 사람은 프랑스어를 원한다. 서버는 같은 URL에 서로 다른 내용을 보낼 수 있다. 가운데 있는 공용 캐시가 URL만 기억하면 첫 번째 판본을 재빨리 꺼낼 수는 있어도 왜 그 판본이 선택됐는지는 잊어버린다. 빠른 서비스가 잘못된 신문을 가져오는 순간이다.

HTTP는 선택 이유를 Vary에 적는다. 현행 HTTP 의미 규격 RFC 9110은 Vary: accept-language가 응답 선택에 영향을 준 요청 필드를 가리킨다고 설명한다. 캐시 규격 RFC 9111은 그 필드가 저장 당시 요청과 맞지 않으면 재검증 없이 응답을 다시 써서는 안 된다고 정한다. 캐시는 덴마크어 책을 보관해도 된다. 책을 누구에게 꺼냈는지 적힌 표도 함께 보관해야 한다.

RFC 9111은 평범한 실수 하나를 짚는다. 기본 응답에서 Vary를 빼먹으면, 뒤에 더 적합한 언어판이 있어도 그 기본판이 계속 선택될 수 있다. 번역 품질 문제가 아니다. 서버가 선택 기준을 알려 주지 않아, 부지런한 캐시가 표지 없는 책을 집어 드는 문제다.

응답의 Content-Language는 실제 전달한 콘텐츠가 어느 언어 독자를 대상으로 하는지 밝힌다. RFC 9110에서 Accept-Language는 희망 사항, Content-Language는 보낸 판본, Vary는 재사용 조건이다. 이 세 가지를 구별하면 어긋난 지점을 주문, 조리, 배달 가운데서 찾을 수 있다.

브라우저의 언어 설정이 지금 읽는 사람의 뜻일 필요도 없다. W3C의 언어 협상 안내는 남의 브라우저를 빌려 쓴 사람의 사례를 들고, 독자가 직접 판본을 바꿀 수 있는 눈에 띄는 조작을 권한다. 1997년 RFC는 매 요청에 자세한 언어 목록을 보내는 일이 사적인 취향을 드러낼 수 있다고 이미 적었다. 현행 규격은 그 목록을 사용자가 관리할 수 있도록 요구한다.

브라우저가 주문하고 서버가 고르고 캐시가 좌석표를 챙긴다. 마지막으로 책을 펴는 사람은 다른 언어판을 직접 고를 수 있어야 한다. 그때야 빠른 배달이 친절한 배달이 된다.