HTTP版本
在HTTP的发展过程中，出现了很多HTTP版本，其中的大部分协议都是向下兼容的。在进行HTTP请求时，客户端在请求时会告诉服务器它采用的协议版本号，而服务器则会在使用相同或者更早的协议版本进行响应。
HTTP/0.9
这是HTTP最早大规模使用的版，现已过时。在这个版本中 只有GET一种请求方法，在HTTP通讯也没有指定版本号，也不支持请求头信息。该版本不支持POST等方法，因此客户端向服务器传递信息的能力非常有限。
HTTP/1.0
这个版本是第一个在HTTP通讯中指定版本号的协议版本，HTTP/1.0至今仍被广泛采用，特别是在代理服务器中。
HTTP/1.0支持：GET、POST、HEAD三种HTTP请求方法。
HTTP/1.1
HTTP/1.1是当前正在使用的版本。该版本默认采用持久连接，并能很好地配合代理服务器工作。还支持以管道方式同时发送多个请求，以便降低线路负载，提高传输速度。
HTTP/1.1新增了：OPTIONS、PUT、DELETE、TRACE、CONNECT五种HTTP请求方法。
HTTP/2
这个版本是最新发布的版本，于今年5月（2015年5月）做HTTP标准正式发布。HTTP/2通过支持请求与相应的多路重用来减少延迟，通过压缩HTTP头字段将协议开销降到最低，同时增加了对请求优先级和服务器端推送的支持。
HTTP Method
GET
GET 是最常用的方法。通常用于请求服务器发送某个资源。HTTP/1.1 要求服务器实现此方法。
HEAD
HEAD 方法与 GET 方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。使用 HEAD，可以:
- 在不获取资源的情况下了解资源的情况(比如，判断其类型);
- 通过查看响应中的状态码，看看某个对象是否存在;
- 通过查看首部，测试资源是否被修改了。
服务器开发者必须确保返回的首部与 GET 请求所返回的首部完全相同。遵循 HTTP/1.1 规范，就必须实现 HEAD 方法。
PUT
与 GET 从服务器读取文档相反，PUT 方法会向服务器写入文档。有些发布系统允许用户创建 Web 页面，并用 PUT 直接将其安装到 Web 服务器上去。
PUT 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的 URL 命名的新文档，或者，如果那个 URL 已经存在的话，就用这个主体来替代它。
因为 PUT 允许用户对内容进行修改，所以很多 Web 服务器都要求在执行 PUT 之前，用密码登录。
和POST方法一样，PUT方法也改变了资源的状态，所以是 非安全 的。但是有一点和POST不同，它是 幂等 的，这是为什么呢？想想setter函数吧，重复调用，只要参数是一样的，表述就是不变的。
POST
POST 方法起初是用来向服务器输入数据的。实际上，通常会用它来支持 HTML 的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方(比如，送到一个服务器网关程序中，然后由这个程序对其进行处理)。
注： POST 用于向服务器发送数据。PUT 用于向服务器上的资源(例如文件)中存储数据。
TRACE
客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在 最终将请求发送给服务器时，看看它变成了什么样子。
TRACE 请求会在目的服务器端发起一个 环回 诊断。行程最后一站的服务器会弹回一条 TRACE 响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间 HTTP 应用程序组成的请求 / 响应链上，原始报文是否，以及如何被毁坏或修改过。
TRACE 方法主要用于诊断；也就是说，用于验证请求是否如愿穿过了请求 / 响应链。它也是一种很好的工具，可以用来查看代理和其他应用程序对用户请求所产生 效果。
尽管 TRACE 可以很方便地用于诊断，但它确实也有缺点，它假定中间应用程序对各种不同类型请求(不同的方法——GET、HEAD、POST 等)的处理是相同的。
很多 HTTP 应用程序会根据方法的不同做出不同的事情——比如，代理可能会将 POST 请求直接发送给服务器，而将 GET 请求发送给另一个 HTTP 应用程序(比如 Web 缓存)。TRACE 并不提供区分这些方法的机制。通常，中间应用程序会自行决定对 TRACE 请求的处理方式。
TRACE 请求中不能带有实体的主体部分。TRACE 响应的实体主体部分包含了响应服务器收到的请求的精确副本。
当 TRACE 请求到达目的服务器时，16 整条请求报文都会被封装在一条 HTTP 响应的主体中回送给发送端。当 TRACE 响应到达时，客户端可以检查服务器收到的确切报文，以及它所经过的代理列表(在 Via 首部)。TRACE 响应的 Content-Type 为 message/http，状态为 200 OK。
Via
Via 首部字段列出了与报文途经的每个中间节点(代理或网关)有关的信息。报文每经过一个节点，都必须将这个中间节点添加到 Via 列表的末尾。
代理也可以用 Via 首部来检测网络中的路由循环。代理应该在发送一条请求之前， 在 Via 首部插入一个与其自身有关的独特字符串，并在输入的请求中查找这个字符 串，以检测网络中是否存在路由循环。
Via 首部字段包含一个由逗号分隔的 路标(waypoint)。每个路标都表示一个独立的 代理服务器或网关，且包含与那个中间节点的协议和地址有关的信息。下面是一个 带有两个路标的 Via 首部实例:
Via = 1.1 cache.joes-hardware.com, 1.1 proxy.irenes-isp.netVia 首部的正规语法如下所示:
Via = "Via" ":" 1#( waypoint )
waypoint = ( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
received-by = ( host [ ":" port ] ) | pseudonym注意，每个 Via 路标中最多包含 4 个组件:一个可选的协议名(默认为 HTTP)、一 个必选的协议版本、一个必选的节点名和一个可选的描述性注释。
OPTIONS
OPTIONS 方法请求 Web 服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。(有些服务器可能只支持对一些特殊类型的对象使用特定的操作)。
通过使用 OPTIONS，客户端可以在与服务器进行交互之前，确定服务器的能力，这样它就可以更方便地与具备不同特性的代理和服务器进行互操作了。
这为客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判定访问各种资源的最优方式。
如果 OPTIONS 请求的 URI 是个星号(*)，请求的就是整个服务器所支持的功能。
比如:
OPTIONS * HTTP/1.1如果 URI 是个实际资源地址，OPTIONS 请求就是在查询那个特定资源的可用特性:
OPTIONS http://www.joes-hardware.com/index.html HTTP/1.1如果成功，OPTIONS方法就会返回一个包含了各种首部字段的200 OK响应，这些 字段描述了服务器所支持的，或资源可用的各种可选特性。HTTP/1.1 在响应中唯一 指定的首部字段是 Allow 首部，这个首部用于描述服务器所支持的各种方法(或者 服务器上的特定资源)。OPTIONS 允许在可选的响应主体中包含更多的信息，但并没有对这种用法进行定义。
Allow首部
Allow 实体首部字段列出了请求 URI 标识的资源所支持的方法列表，如果请求 URI为 * 的话，列出的就是整个服务器所支持的方法列表。例如:
Allow: GET, HEAD, PUT可以将 Allow 首部作为请求首部，建议在新的资源上支持某些方法。并不要求服务 器支持这些方法，但应该在相应的响应中包含一个 Allow 首部，列出它实际支持的方法。
因为客户端可能已经通过其他途径与原始服务器进行了交流，所以即使代理无法理解指定的所有方法，也不能对 Allow 首部字段进行修改。
DELETE
顾名思义，DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源。 但是，客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务 器在不通知客户端的情况下撤销请求。
和POST方法一样，DELETE方法也改变了资源的状态，所以是非安全的。但是有一点和POST不同，它是幂等的，也就是说，就算是服务器在前一个请求中已经删除了资源，它也必须返回200.这就意味着，我们在实现服务端的该方法是，需要跟踪已经删除的资源，否则就会返回404的。
CONNECT
CONNECT方法是HTTP/1.1协议预留的，能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接与非加密的HTTP代理服务器的通信。
PATCH
PATCH方法出现的较晚，它在2010年的 RFC 5789 PATCH Method for HTTP 标准中被定义。PATCH请求与PUT请求类似，同样用于资源的更新。二者有以下两点不同：
- 但PATCH一般用于资源的部分更新，而PUT一般用于资源的整体更新。
- 当资源不存在时，PATCH会创建一个新的资源，而PUT只会对已在资源进行更新。
