<HTTP权威指南>记录 ---- Web代理

Web代理

Web的中间实体

Web代理(Web proxy)服务器是网络的中间实体。代理位于客户端和服务器之间，扮演"中间人"的角色，在各端点之间来回传送HTTP报文。Web上的代理服务器是代表客户端完成事务处理的中间人。如果没有Web代理，Web客户端就要直接与Web服务器进行对话。有了Web代理，客户端就可以与代理进行对话，然后由代理代表客户端与服务器进行交流。客户端仍然会完成对事务的处理，但它是通过代理服务器提供的优质服务来实现的。HTTP的代理服务器既是Web服务器又是Web客户端。Web客户端会向代理发送请求报文，代理服务器必须像Web服务器一样，正确地处理请求和连接，然后返回响应。同时，代理自身要向服务器发送请求，这样，其行为就必须像正确的Web客户端一样，要发送请求并接收响应。如果要创建自己的Web代理，就要认真地遵循为Web客户端和Web服务器制定的规则。

• 对于Web客户端来说：代理扮演的是Web服务器的角色，接受请求报文，返回响应报文；
• 对于Web服务器来说：代理扮演的是Web客户端的角色，发送请求报文，接收响应报文。

代理服务器可以是某个客户端专用的，也可以是很多客户端共享的。单个客户端专用的代理被称为私有代理。众多客户端共享的代理被称为公共代理。

• 公共代理：大多数代理都是公共的共享代理。集中式代理的成本效率更高，更容易管理。某些代理应用，比如高速缓存代理服务器，会利用用户间共同的请求，这样的话，汇入同一个代理服务器的用户越多，它就越有用。
• 私有代理：专用的私有代理并不常见，但它们确实存在，尤其是直接运行在客户端计算机上的时候。有些浏览器辅助产品，以及一些ISP服务，会在用户的PC上直接运行一些小型的代理，以便扩展浏览器特性，提高性能，或为免费ISP服务提供主机广告。

代理与网关

严格来说，代理连接的是两个或多个使用相同协议的应用程序，而网关连接的则是两个或多个使用不同协议的端点。网关扮演的是"协议转换器"的角色，即使客户端和服务器使用的是不同的协议，客户端也可以通过它完成与服务器之间的事务处理。实际上，代理和网关之间的区别很模糊。由于浏览器和服务器实现的是不同版本的HTTP，代理也经常要做一些协议转换工作。而商业化的代理服务器也会实现网关的功能来支持SSL安全协议、SOCKS防火墙、FTP访问，以及基于Web的应用程序。

代理的功能

代理服务器可以实现各种时髦且有用的功能。它们可以改善安全性，提高性能，节省费用。代理服务器可以看到并接触到所有流过的HTTP流量，所以代理可以监视流量并对其进行修改，以实现很多有用的增值Web服务。

• 访问控制：可以用代理服务器在大量Web服务器和Web资源之间实现统一的访问控制策略，创建审核跟踪机制。这在大型企业环境或其他分布式机构中是很有用的。在集中式代理服务器上可以对所有访问控制功能进行配置，而无需在众多由不同组织管理、不同厂商制造、使用不同模式的Web服务器上进行经常性的访问控制升级。
• 安全防火墙：网络安全工程师通常会使用代理服务器来提高安全性。代理服务器会在网络中的单一安全节点上限制哪些应用层协议的数据可以流入或流出一个组织。还可以提供用来消除病毒的Web和E-mail代理使用的那种挂钩程序，以便对流量进行详细的检查。
• Web缓存：代理缓存维护了常用文档的本地副本，并将它们按需提供，以减少缓慢且昂贵的因特网通信。
• 反向代理：代理可以假扮Web服务器。这些被称为反向代理(reverse proxy)的代理接收发给Web服务器的真实请求，但与Web服务器不同的是，它们可以发起与其他服务器的通信，以便按需定位所请求的内容。可以用这些反向代理来提高访问慢速Web服务器上公共内容时的性能。在这种配置中，通常将这些反向代理称为服务器加速器(server accelerator)。还可以将反向代理与内容路由功能配合使用，以创建按需复制内容的分布式网络。
• 内容路由器：代理服务器可以作为"内容路由器"使用，根据因特网流量状况以及内容类型将请求导向特定的Web服务器。内容路由器也可以用来实现各种服务级的请求。比如，如果用户或内容提供者付费要求提供更高的性能，内容路由器可以将请求转发到附近的复制缓存，或者如果用户申请了过滤服务，还可以通过过滤代理来转发HTTP请求。可以用自适应内容路由代理来构建很多有趣的服务。
• 转码器：代理服务器在将内容发送给客户端之前，可以修改内容的主体格式。在这些数据表示法之间进行的透明转换被称为转码(transcoding)。转码代理可以在传输GIF图片时，将其转换成JPEG图片，以减小尺寸。也可以对图片进行压缩，或降低颜色的色彩饱和度以便在电视上观看。同样，可以对文本文件进行压缩，并为能够使用因特网的呼机和智能手机生成小型的文本摘要Web页面。代理甚至可以在传输文档的过程中将其转换成外语。

• 匿名者：匿名者代理会主动从HTTP报文中删除身份特性(比如客户端IP地址、From首部、Referer首部、cookie、URI的会话 ID)，从而提供高度的私密性和匿名性。

  • 从User-Agent首部删除用户的计算机与OS类型。
  • 删除From首部以保护用户的E-mail地址。
  • 删除Referer首部来掩盖用户访问过的其他站点。
  • 删除Cookie首部以剔除概要信息和身份的数据。

代理会做些什么

代理服务器的部署位置

可以根据其目标用途，将代理放在任意位置。

• 出口代理：可以将代理固定在本地网络的出口点，以便控制本地网络与大型因特网之间的流量。可以在公司网络中使用出口代理，提供针对公司外部恶意黑客的防火墙保护，或降低带宽费用，提高因特网流量的性能。
• 访问(入口)代理：代理常被放在ISP访问点上，用以处理来自客户的聚合请求。ISP使用缓存代理来存储常用文档的副本，以提高用户(尤其是高速连接用户)的下载速度，降低因特网带宽耗费。
• 反向代理：代理通常会被部署在网络边缘，在Web服务器之前，作为反向代理使用，在那里它们可以处理所有传送给Web服务器的请求，并只在必要时向Web服务器请求资源。反向代理可以提高Web服务器的安全特性，或者将快速的Web服务器缓存放在较慢的服务器之前，以提高性能。反向代理通常会直接冒用Web服务器的名字和IP地址，这样所有的请求就会被发送给代理而不是服务器了。
• 网络交换代理：可以将具有足够处理能力的代理放在网络之间的因特网对等交换点上，通过缓存来减轻因特网节点的拥塞，并对流量进行监视。

代理的层次结构

可以通过代理层次结构(proxy hierarchy)将代理级联起来。在代理的层次结构中，会将报文从一个代理传给另一个代理，直到最终抵达原始服务器为止(然后通过代理传回给客户端)。代理层次结构中的代理服务器被赋予了父(parent)和子(child)的关系。下一个入口(inbound)代理(靠近服务器)被称为父代理，下一个出口(outbound)代理(靠近客户端)被称为子代理。

代理服务器可以根据众多因素，将报文转发给一个不断变化的代理服务器和原始服务器集。访问代理会根据不同的情况将报文转发给父代理或原始服务器。

• 负载均衡：子代理可能会根据当前父代理上的工作负载级别来决定如何选择一个父代理，以均衡负载。
• 地理位置附近的路由：子代理可能会选择负责原始服务器所在物理区域的父代理。
• 协议/类型路由：子代理可能会根据URI将报文转发到不同的父代理和原始服务器上去。某些特定类型的URI可能要通过一些特殊的代理服务器转发请求，以便进行特殊的协议处理。
• 基于订购的路由：如果发布者为高性能服务额外付费了，它们的URI就会被转发到大型缓存或压缩引擎上去，以提高性能。在不同的产品中，动态父路由逻辑的实现方式各有不同，包括使用配置文件、脚本语言和动态可执行插件等。

代理是如何获取流量的

客户端通常会直接与Web服务器进行通信，有四种常见方式可以使客户端流量流向代理。

• 修改客户端：很多Web客户端，都支持手工和自动的代理配置。如果将客户端配置为使用代理服务器，客户端就会将HTTP请求有意地直接发送给代理，而不是原始服务器。
• 修改网络：网络基础设施可以通过若干种技术手段，在客户端不知道，或没有参与的情况下，拦截网络流量并将其导入代理。这种拦截通常都依赖于监视HTTP流量的交换设备及路由设备，在客户端毫不知情的情况下，对其进行拦截，并将流量导入一个代理。这种代理被称为拦截(intercepting)代理。
• 修改DNS的命名空间：放在Web服务器之前的代理服务器——反向代理，会直接假扮Web服务器的名字和IP地址，这样，所有的请求就会发送给这些反向代理，而不是服务器了。要实现这一点，可以手工编辑DNS名称列表，或者用特殊的动态DNS服务器根据需要来确定适当的代理或服务器。有时在安装过程中，真实服务器的IP地址和名称被修改了，反向代理得到的会是之前的地址和名称。
• 修改Web服务器：也可以将某些Web服务器配置为向客户端发送一条HTTP重定向命令(响应码305)，将客户端请求重定向到一个代理上去。收到重定向命令后，客户端会与代理进行通信。

客户端的代理设置

所有现代的Web浏览器都允许用户对代理的使用进行配置。实际上，很多浏览器都提供了多种配置代理的方式，其中包括以下几种。

• 手工配置：显式地设置要使用的代理。
• 预先配置浏览器：浏览器厂商或发行商会在将浏览器发送给其客户之前预先对浏览器(或所有其他Web客户端)的代理设置进行手工配置。手工代理配置很简单但有些死板。只能为所有内容指定唯一的一个代理服务器，而且不支持故障转移。手工代理配置还会给大型组织带来管理问题。如果配置过的浏览器基数很大，那么需要进行修改的时候，重新配置每个浏览器是非常困难，甚至是不可能的。
• 代理的自动配置(Proxy Auto-Configuration，PAC)：提供一个URI，指向一个用JavaScript语言编写的代理自动配置文件；客户端会取回这个JavaScript文件，并运行它以决定是否应该使用一个代理，如果是的话，应该使用哪个代理服务器。
• WPAD的代理发现：有些浏览器支持Web代理自动发现协议(Web Proxy Autodiscovery Protocol，WPAD)，这个协议会自动检测出浏览器可以从哪个"配置服务器"下载到一个自动配置文件。WPAD协议的算法会使用发现机制的逐级上升策略自动地为浏览器查找合适的PAC文件。WPAD会使用一系列的资源发现技术来判定适当的PAC文件。并不是所有组织都能够使用所有的发现技术，所以WPAD使用了很多种发现技术。WPAD会一个接一个地对每种技术进行尝试，直到成功为止。

PAC文件是一些小型的JavaScript程序，可以在运行过程中计算代理设置，因此，是一种更动态的代理配置解决方案。访问每个文档时，JavaScript函数都会选择恰当的代理服务器。要使用PAC文件，就要用JavaScript PAC文件的URI来配置浏览器[配置方式与手工配置类似，但要在"automatic configuration"(自动配置)框中提供一个URI]。浏览器会从这个URI上获取PAC文件，并用JavaScript逻辑为每次访问计算恰当的代理服务器。PAC文件的后缀通常是".pac"，MIME类型通常是"application/x-ns- proxy-autoconfig"。每个PAC文件都必须定义一个名为"FindProxyForURL(url,host)"的函数，用来计算访问URI时使用的适当的代理服务器。

代理自动配置脚本的返回值：

"FindProxyForURL(url,host)"的返回值	描述
DIRECT	不经过任何代理，直接进行连接
PROXY host:port	应该使用指定的代理
SOCKS host:port	应该使用指定的SOCKS服务器

实现 WPAD 协议的客户端需要：

• 用WPAD找到PAC的URI；
• 从指定的URI获取PAC文件；
• 执行PAC文件来判定代理服务器；
• 为请求使用代理服务器。

当前的 WPAD 协议规范按顺序定义了下列技术：

• 动态主机配置协议(DHCP)；
• 服务定位协议(Service Location Protocol，SLP)；
• DNS知名主机名；
• DNS SRV记录；
• TXT记录中的DNS服务URI。

代理请求

代理URI与服务器URI的不同

除了一点之外，Web服务器报文和Web代理报文的语法是一样的。客户端向服务器而不是代理发送请求时，HTTP请求报文中的URI会有所不同。客户端向Web服务器发送请求时，请求行中只包含部分URI(没有方案、主机或端口)。但当客户端向代理发送请求时，请求行中则包含完整的URI。</p>
<p>为什么会有两种不同的请求格式，一种用于代理，另一种用于服务器呢？在原始的HTTP设计中，客户端会直接与单个服务器进行对话。不存在虚拟主机，也没有为代理制定什么规则。单个的服务器都知道自己的主机名和端口，所以，为了避免发送冗余信息，客户端只需发送部分URI即可，无需发送方案和主机(以及端口)。代理出现之后，使用部分URI就有问题了。代理需要知道目标服务器的名称，这样它们才能建立自己与服务器的连接。基于代理的网关要知道URI的方案才能连接到FTP资源和其他方案上去。"HTTP/1.0"要求代理请求发送完整的URI，解决了这个问题，但它为服务器请求保留部分URI的形式(已经有相当多的服务器都改为支持完整URI了)。因此，我们要将部分URI发送给服务器，将完整URI发送给代理。在显式地配置客户端代理设置的情况下，客户端就知道要发布哪种类型的请求了。

代理"缺少方案/主机/端口"的问题与虚拟主机Web服务器面临的问题相同。虚拟主机Web服务器会在很多Web站点间共享同一个物理Web服务器。包含部分URI的请求到达时，虚拟主机Web服务器需要知道目的Web站点的主机名。

尽管它们出现的问题相似，但解决方法却有所不同：

• 显式的代理要求在请求报文中使用完整URI来解决这个问题；
• 虚拟主机 Web 服务器要求使用Host首部来承载主机和端口信息。

拦截代理会收到部分URI

只要客户端正确地实现了HTTP，它们就会在请求中包含完整的URI，发送给经过显式配置的代理。这样解决了部分问题，但还有一个问题：客户端并不总是知道它是在和代理进行对话，因为有些代理对客户端可能是不可见的。即使没有将客户端配置为使用代理，客户端的流量也可能会经过替代物或拦截代理。在这两种情况下，客户端都会认为它在与Web服务器进行对话，不会发送完整的URI。

• 反向代理是一个用来取代原始服务器的代理服务器，它通常会通过假扮服务器的主机名或IP地址来做到这一点。它会收到Web服务器请求，可能会向真正的服务器提供缓存的响应或者代理请求。客户端无法区分反向代理和Web服务器，因此它会发送部分URI。
• 拦截代理是网络流量中的代理服务器，它会拦截从客户端发往服务器的请求，并提供一个缓存响应，或对其进行转发。由于拦截代理拦截了从客户端到服务器的流量，所以它会收到发送给Web服务器的部分URI。

处理服务器请求

由于将流量重定向到代理服务器的方式有所不同，通用的代理服务器既应该支持请求报文中的完整URI，也应该支持部分URI。如果是显式的代理请求，代理就应该使用完整URI，如果是Web服务器请求，就应该使用部分URI和虚拟Host首部。

使用完整和部分URI的规则如下所示。

• 如果提供的是完整URI，代理就应该使用这个完整URI；
• 如果提供的是部分URI，而且有Host首部，就应该用Host首部来确定原始服务器的名字和端口号；

• 如果提供的是部分URI，而且没有Host首部，就要用其他方法来确定原始服务器：

  • 如果代理是代表原始服务器的替代物，可以用真实服务器的地址和端口号来配置代理；
  • 如果流量被拦截了，而且拦截者也可以提供原始的IP地址和端口，代理就可以使用拦截技术提供的IP地址和端口号；
  • 如果所有方法都失败了，代理没有足够的信息来确定原始服务器，就必须返回一条错误报文(通常是建议用户升级到支持Host首部的现代浏览器)。

修改URI的规则

代理服务器要在转发报文时修改请求URI的话，需要特别小心。对URI的微小修改，甚至是看起来无害的修改，都可能给下游服务器带来一些互操作性问题。尤其是，现在已知有些代理会在将URI转发给下一跳节点之前将URI"规范"为标准格式。有些看起来无害的转换行为，比如用显式的":80"来取代默认的HTTP端口，或者用适当的换码转义符来取代非法的保留字符以校正URI，就可能造成互操作性问题。总之，代理服务器要尽量宽容一些。它们的目标不是成为强制实现严格协议一致性的"协议警察"，因为这样可能会严重破坏之前能正常工作的服务。特别是，HTTP规范禁止一般的拦截代理在转发URI时重写其绝对路径部分。唯一的例外是可以用"/"来取代空路径。

URI的客户端自动扩展和主机名解析

根据是否有代理，浏览器对请求URI的解析会有所不同。没有代理时，浏览器会获取你输入的URI，尝试着寻找相应的IP地址。如果找到了主机名，浏览器会尝试相应的IP地址直到获得成功的连接为止。但是，如果没有找到主机，很多浏览器都会尝试着提供某种主机名自动“扩展”机制，以防用户输入的是主机“简短”的缩写形式。

• 很多浏览器会尝试着加入前缀"www."和后缀".com"，以防用户只输入了常见Web站点名的中间部分。
• 有些浏览器甚至会将未解析出来的URI传递给第三方站点，这个站点会尝试着校正拼写错误，并给出一些用户可能希望访问的URI建议。
• 而且，大多数系统中的DNS配置允许用户只输入主机名的前缀，然后DNS会自动搜索域名。

追踪报文

现在，在将Web请求从客户端传送到服务器的路径上，经过两个或多个代理是很常见的。比如，出于安全和节省费用的考虑，很多公司都会用缓存代理服务器来访问因特网，而且很多大型ISP都会使用代理缓存来提高性能并实现各种特性。现在，有相当比例的Web请求都是通过代理转发的。同时，出于性能原因，把内容复制到遍布全球的替代物缓存库中的情形也越来越常见了。代理是由不同厂商开发的。它们有不同的特性和缺陷，由各种不同的组织负责管理。随着代理的逐渐流行，我们要能够追踪经过代理的报文流，以检测出各种问题，其重要性就跟追踪经过不同交换机和路由器传输的IP分组流一样。

Via首部

Via首部字段列出了与报文途经的每个中间节点(代理或网关)有关的信息。报文每经过一个节点，都必须将这个中间节点添加到Via列表的末尾。Via首部字段用于记录报文的转发，诊断报文循环，标识请求/响应链上所有发送者的协议能力。代理也可以用Via首部来检测网络中的路由循环。代理应该在发送一条请求之前，在Via首部插入一个与其自身有关的独特字符串，并在输入的请求中查找这个字符串，以检测网络中是否存在路由循环。

• Via的语法：Via首部字段包含一个由逗号分隔的路标(waypoint)。每个路标都表示一个独立的代理服务器或网关，且包含与那个中间节点的协议和地址有关的信息。
  每个Via路标中最多包含4个组件：一个可选的协议名(默认为HTTP)、一个必选的协议版本、一个必选的节点名和一个可选的描述性注释。

  • 协议名：中间节点收到的协议。如果协议为HTTP的话，协议名就是可选的。否则，要在版本之前加上协议名，中间用"/"分隔。网关将HTTP请求连接到其他协议(HTTPS、FTP等)时，可能会使用非HTTP协议。
  • 协议版本：所收到的报文版本。版本的格式与协议有关。HTTP使用的是标准版本号(1.0、1.1等)。版本包含在Via字段中，这样，之后的应用程序就会知道前面所有中间节点的协议能力了。
  • 节点名：中间节点的主机和可选端口号(如果没有包含端口号，可以假定使用的是协议的默认端口号)。在某些情况下，出于隐私方面的考虑，某个组织可能不愿意给出真实的主机名，在这种情况下可以用一个假名来代替。
  • 节点注释：进一步描述这个中间节点的可选注释。通常会在这里包含厂商和版本信息，有些代理服务器还会在注释字段中包含一些与此设备上所发生事件有关的诊断信息。
• Via的请求和响应路径：请求和响应报文都会经过代理进行传输，因此，请求和响应报文中都要有Via首部。请求和响应通常都是通过同一条TCP连接传送的，所以响应报文会沿着与请求报文相同的路径回传。
• Via与网关：有些代理会为使用非HTTP协议的服务器提供网关的功能。Via首部记录了这些协议转换，这样，HTTP应用程序就会了解代理链上各点的协议处理能力以及所做的协议转换了。
• Server和Via首部：Server响应首部字段对原始服务器使用的软件进行了描述。如果响应报文是通过代理转发的，一定要确保代理没有修改Server首部。Server首部是用于原始服务器的。代理应该添加的是Via条目。
• Via的隐私和安全问题：有时候，我们并不希望在Via字符串中使用确切的主机名。总地来说，除非显式地允许了这种行为，否则，当代理服务器作为网络防火墙的一部分使用时，是不应该转发防火墙后面那些主机的名字和端口号的，因为防火墙后面的网络结构信息可能会被恶意群体利用。如果不允许进行Via节点名转发，作为安全防线的一部分使用的代理就应该用适当的假名来取代那台主机的名字。一般来说，即使隐藏了真实名称，代理也应该尝试着为每台代理服务器保留一个Via路标条目。对那些有着非常强烈的隐私要求，需要隐藏内部网络设计和拓扑结构的组织来说，代理应该将一个(接收协议值相同的)有序Via路标条目序列合并成一个联合条目。除非这些条目都在同一个组织的控制之下，而且已经用假名取代了主机名，否则就不能将其合并起来。同样，接收协议值不同的条目也不能合并起来。

TRACE方法

代理服务器可以在转发报文时对其进行修改。可以添加、修改或删除首部，也可以将主体部分转换成不同的格式。代理变得越来越复杂，开发代理产品的厂商也越来越多，互操作性问题也开始逐渐显现。为了便于对代理网络进行诊断，我们需要有一种便捷的方式来观察在通过HTTP代理网络逐跳转发报文的过程中，报文是怎样变化的。通过"HTTP/1.1"的TRACE方法，用户可以跟踪经代理链传输的请求报文，观察报文经过了哪些代理，以及每个代理是如何对请求报文进行修改的。TRACE对代理流的调试非常有用。当TRACE请求到达目的服务器时，整条请求报文都会被封装在一条HTTP响应的主体中回送给发送端。当TRACE响应到达时，客户端可以检查服务器收到的确切报文，以及它所经过的代理列表(在Via首部)。TRACE响应的Content-Type为message/http，状态为"200 OK"。</p>
<p>Max-Forwards：通常，不管中间插入了多少代理，TRACE报文都会沿着整条路径传到目的服务器上。可以使用Max-Forwards(最大转发次数)首部来限制TRACE和OPTIONS请求所经过的代理跳数，在测试代理链是否是在无限循环中转发报文，或者查看链中特定代理服务器的效果时，它是很有用的。Max-Forwards也可以限制OPTIONS报文的转发。Max-Forwards请求首部字段包含了一个整数，用来说明这条请求报文还可以被转发的次数。如果Max-Forwards的值为零(Max-Forwards:0)，那么即使接收者不是原始服务器，它也必须将TRACE报文回送给客户端，而不应该继续转发。如果收到的Max-Forwards值大于零，转发的报文中就必须包含一个更新了的Max-Forwards字段，其值会被减一。所有的代理和网关都应该支持Max-Forwards。可以用Max-Forwards来查看在代理链的任意一跳上接收到的请求。

代理认证

代理可以作为访问控制设备使用。HTTP定义了一种名为代理认证(proxy authentication)的机制，这种机制可以阻止对内容的请求，直到用户向代理提供了有效的访问权限证书为止。若传输链路中有多个代理，且每个代理都要进行认证时，代理认证通常无法很好地工作。

• 对受限内容的请求到达一台代理服务器时，代理服务器可以返回一个要求使用访问证书的"407 Proxy Authorization Required"状态码，以及一个用于描述怎样提供这些证书的Proxy-Authenticate首部字段。
• 客户端收到407响应时，会尝试着从本地数据库中，或者通过提示用户来搜集所需要的证书。
• 只要获得了证书，客户端就会重新发送请求，在Proxy-Authorization首部字段中提供所要求的证书。
• 如果证书有效，代理就会将原始请求沿着传输链路向下传送；否则，就发送另一条407应答。

代理的互操作性

客户端、服务器和代理是由不同厂商构建的，实现的是不同版本的HTTP规范。它们支持的特性各不相同，也存在着不同的问题。代理服务器位于客户端和服务器设备之间，这些设备实现的协议可能有所不同，可能存在着很棘手的问题。

处理代理不支持的首部和方法

代理服务器可能无法理解所有经其传输的首部字段。有些首部可能比代理自身还要新；其他首部可能是特定应用程序独有的定制首部。代理必须对不认识的首部字段进行转发，而且必须维持同名首部字段的相对顺序。类似地，如果代理不熟悉某个方法，那么只要可能，就应该尝试着将报文转发到下一跳节点上去。

OPTIONS：发现对可选特性的支持

通过OPTIONS方法，客户端(或代理)可以发现Web服务器或者其上某个特定资源所支持的功能(比如，它们所支持的方法)。通过使用OPTIONS，客户端可以在与服务器进行交互之前，确定服务器的能力，这样它就可以更方便地与具备不同特性的代理和服务器进行互操作了。如果OPTIONS请求的URI是个"*"(星号)，请求的就是整个服务器所支持的功能。如果URI是个实际资源地址，OPTIONS请求就是在查询那个特定资源的可用特性。如果成功，OPTIONS方法就会返回一个包含了各种首部字段的"200 OK"响应，这些 字段描述了服务器所支持的，或资源可用的各种可选特性。"HTTP/1.1"在响应中唯一指定的首部字段是Allow首部，这个首部用于描述服务器所支持的各种方法(或者服务器上的特定资源)。OPTIONS允许在可选的响应主体中包含更多的信息，但并没有对这种用法进行定义。

Allow 首部

Allow实体首部字段列出了请求URI标识的资源所支持的方法列表，如果请求URI为"*"(星号)的话，列出的就是整个服务器所支持的方法列表。可以将Allow首部作为请求首部，建议在新的资源上支持某些方法。并不要求服务器支持这些方法，但应该在相应的响应中包含一个Allow首部，列出它实际支持的方法。因为客户端可能已经通过其他途径与原始服务器进行了交流，所以即使代理无法理解指定的所有方法，也不能对Allow首部字段进行修改。