我有一个多语言环境网站。我需要在用户访问站点时将用户重定向到他们的语言环境而不使用url中的语言环境代码。
e.g。
http://www.mysite.com会自动重定向到http://www.mysite.com/uk或http://www.mysite.com/us
我在看rfc2616，我在犹豫是否使用Code 300（多种选择）：
请求的资源对应于一组中的任何一个 表示，每个都有自己的特定位置，代理人 - 正在提供驱动的谈判信息（第12节） 用户（或用户代理）可以选择首选表示和 将其请求重定向到该位置。
除非是HEAD请求，否则响应应该包含一个实体 包含资源特征和位置的列表 用户或用户代理可以选择最合适的一个。该 实体格式由Content-Type头字段中给出的媒体类型指定。
根据用户代理的格式和功能，可以自动选择最合适的选择。但是，本规范没有为此类自动选择定义任何标准。
如果服务器有首选的表示形式，它应该是 在Location中包含该表示的特定URI 场;
我想我理解，但措辞仍然让我有点神秘。熟悉响应代码的人是否可以确认我是否在正确的轨道上并解释以下摘录？
答案 0 :(得分：1)
在你的情况下，我认为你不想要“代理驱动的谈判”。在您的情况下，您的服务器应该能够从accept-lang标头中选择重定向位置。我想你可以使用303重定向。
仅当服务器不知道客户端想要什么样的表示时才使用代理驱动的协商。在这些情况下，服务器将返回具有不同可用选项的链接列表。然后代理将选择它想要的表示。
如果您想要一些javascript代码来处理300响应并向用户显示选项列表，以便用户可以选择所需的语言，您将使用代理驱动的协商。
答案 1 :(得分：0)
我相信这是正确的回答，是的。事实上，我认为这是唯一的选择，如果您确实希望将其作为响应处理（并且不能进行地理查找），因为所有其他3xx范围响应都是针对确定结果（除了奇怪的305代理）。 / p>
摘录：
......和代理商驱动的谈判 正在提供信息......
这里的目的是表明在所做出的选择中，选择是基于用户代理的特征（潜在地无限变化），这些特征通常在接受头和用户代理头本身中传达。 。谈判可能是一个令人困惑的术语，但它所指的概念是代理和服务器之间确定适当的响应类型。
除非是HEAD请求，否则 回应应该包括一个实体 包含资源列表 特征和地点......
HEAD请求仅用于返回响应标头（因此您可以执行廉价检查内容更新等操作）。因此，他们特别不需要响应主体，因此不需要提供300个GET或POST请求的潜在选择列表。