Summary

  • 1997 年的 HTTP/1.1 RFC 2068 已写明 Accept-Language：浏览器可以用带权重的语言列表告诉服务器自己偏好什么。
  • 服务器若按这张单子选择页面，就可以用 Vary: Accept-Language 告知缓存：下次同一网址到来，先比对语言请求，再决定能否复用这份内容。

浏览器访问网页时，常把一张看不见的菜单跟网址一起递过去。1997 年 1 月的 RFC 2068给出的例子依次偏好丹麦语、英式英语和其他英语，q 值表示相对权重。服务器可以据此挑一份页面。读者无需先面对一张语言选择页，网页就有机会用顺耳的语言打招呼。

麻烦从第二位读者开始。第一位要丹麦语，第二位要法语，两人都请求同一个 /news。服务器会分别选版本；夹在中间的共享缓存则可能只看见同一个网址。如果它把第一次拿到的页面当作这个地址的唯一答案，第二位读者就会得到一份措手不及的外语晨报。缓存需要知道，服务器当初是依据什么选的。

HTTP 给这条依据取名 Vary。现行 HTTP 语义规范说明，Vary: accept-language 表示响应版本受请求中的语言字段影响。HTTP 缓存规范进一步规定：存储响应带有 Vary 时，缓存不能在相关请求字段不匹配的情况下直接复用它，除非重新验证。缓存可以记住丹麦语那份，也得记住当时为什么拿了丹麦语。

少了一张标签，错误反而很普通。RFC 9111 特别提醒：如果服务器在默认响应上漏掉 Vary，缓存可能继续选这份默认内容，即使后来的请求本有更合适的版本。服务员没偷懒；他只是按一张没有桌号的单子上菜。

响应中的 Content-Language 则说明送来的内容面向什么语言读者。它与浏览器送出的 Accept-Language、给缓存看的 Vary 分工不同：一个是愿望，一个是实际版本，一个是复用规则。RFC 9110把这些字段分开定义，正是为了让选择过程有迹可循。

浏览器的愿望也未必等于眼前这个人的愿望。W3C 的语言协商指南举了借用别人浏览器的情况：机器原有的语言设置会替新读者发言。页面提供看得见的语言切换，人才有机会自己改口。1997 年的 RFC 还注意到，完整的语言偏好列表若每次请求都发出去，会暴露个人可能想保留的线索；现行规范继续要求让用户控制这张单子。

这套流程像一间忙碌的小餐馆：浏览器报偏好，服务器挑版本，缓存保存桌号，读者可以重新点菜。任何一环把“我猜他想要”和“他真的选了”混为一谈，网页就可能端错盘子。