Location与Content-Location

内容协商（content negotiation）

为了说明Content-Location的含义，必须先明白http的内容协商机制。

考虑支持多语言的服务器端：一个相同的URL可以返回不同语言版本的文档， 其实服务器端就是利用内容协商来识别客户端的，具体可以参见《http权威指南》第17章。  在请求的头信息中，包含有Accept开头的内容协商首部，服务器端可以根据这些内容协商首部来判断出客户端的需求。 除此之外，服务器端还可以根据诸如User-Agent这种首部信息进行推测，例如老版本的浏览器可能不支持JavaScript，如果User-Agent代表老版本的浏览器，那么服务器可以向其响应不包含JavaScript的文档。

在上面的请求头部中，我们看到了多个内容协商首部。 在Accept-Languoge中我们还发现了q值，这叫做质量值。 考虑这种情况，假如服务器端仅仅拥有中文和英文两个版本，并没有日文，但是客户端却最希望能请求到日文内容，这样服务器端就无法提供合适的文档给它了。 而q值的意义就是让客户端可以提供多个候选方案，q值（0.0-1.0）越大表明优先级越高，例如上图中表明：优先选择日文，如果没有日文优先选择en-US，没有en-US,那就选择en。

上面这种内容协商机制叫做服务器端协商。 为了减轻服务器端的压力，我们可以使用中间代理来代替服务器端来与客户端协商，这叫做透明协商。 中间代理如果可以代替服务器，那么代理必须有能力可以完全像服务器那样处理协商逻辑。对于每一种不同的请求服务器端响应的不同版本的文档，我们可以称作是一个 变体。 代理需要有能力根据每一个请求的信息，从缓存的副本中选择 或者 向服务器请求（当副本中没有对应的时候），得到准确的变体。 从上面服务器端协商的讨论中我们知道除了内容协商首部外，服务器能够根据其他首部（例如user-agent）来识别客户端，从而响应不同的变体。 为了让代理具有完全相同的处理协商逻辑的能力，服务器在响应代理的时候，必须告诉代理除了内容协商首部外还根据什么信息处理协商逻辑了，这个首部叫做vary，例如vary：User-Agent。

值得注意的是 协商首部是客户端请求中的头信息，用来向服务器端说明自身的请求特性；而vary是服务器端响应中的头信息，主要作用是用来帮助中间代理处理与客户端的协商逻辑。

Location

Location 首部指定的是需要将页面重新定向至的地址。一般在响应码为3xx的响应中才会有意义。

发送新请求，获取Location指向的新页面所采用的方法与初始请求使用的方法以及重定向的类型相关：

• 303 (See Also) 始终引致请求使用 GET 方法，而，而 307 (Temporary Redirect) 和 308 (Permanent Redirect) 则不转变初始请求中的所使用的方法；
• 301 (Permanent Redirect) 和 302 (Found) 在大多数情况下不会转变初始请求中的方法，不过一些比较早的用户代理可能会引发方法的变更（所以你基本上不知道这一点）。

状态码为上述之一的所有响应都会带有一个Location首部。

除了重定向响应之外， 状态码为 201 (Created) 的消息也会带有Location首部。它指向的是新创建的资源的地址。

Location有相对地址（相对于要访问的URL）和绝对地址。

Location 与 Content-Location是不同的，前者（Location ）指定的是一个重定向请求的目的地址（或者新创建的文件的URL），而后者（ Content-Location） 指向的是经过内容协商后的资源的直接地址，不需要进行进一步的内容协商。Location 对应的是响应，而Content-Location对应的是要返回的实体。

Content-Location

Content-Location首部表明表明作为内容协商结果响应的资源的URL。

响应GET请求，当请求的资源具有多种可用表示形式（例如多种语言）时，可以使用HTTP中的Content-Location。返回的资源的选择将取决于原始GET请求中的Accept标头。

通常，Content-Location标头中指定的位置与原始请求的URI中指定的位置不同。