（技术文章翻译）HTTP 消息（三）

get

get是一种最常见的方法。它通常用来请求服务器获得资源。支持http1.1的服务器都实现了这个方法。在图3-7中可以看出客户端发送了一个get方法的httprequest请求。

3-7

head

head方法的表现就像get方法。但是服务器返回的只有头部信息，并没有实体。他允许客户端检阅资源，而不需要实际获得资源。使用head方法，你能

• 找到一个资源而并不需要获取它。

• 看一个资源是否存在，可以查看response的状态码

• 测试，如果一个资源被修改，查看头信息可以看出。

服务器开发者必须确保，head方法返回的 头部信息和get方法是一样的。head方法在http1.1中也被使用。在图3-8中展示了head方法的行为

3-8

PUT

put方法是写文档到服务器中，和get从服务器读取文档相反。一些发行的系统，可以让你创建一个webpages页面，安装他们直接在服务器上，他们使用put方法，具体看图3-9

put方法的语义指，其为一个request的请求，使用它可以创建一个名为request url的文档。如果url已经存在，那么就替换它。因为put方法允许你改变内容。大多数web服务器需要你登录，然后才能在平台中使用put方法,你可以在第12章中阅读关于密码的权限。

POST

post方法被设计用来向服务器发送表单数据。

在实践中，他主要支持html的表单数据。在图3-10中展示了http request请求，向服务器发送数据。使用post方法。

TRACE

当客户端发出一个request请求，这个请求，将会穿过防火墙，代理，路由器，或者其他的一些应用。中间每一个过程都有机会修改原始的request请求。trace方法，将会允许到客户端，看到最终从server处理后的数据

一个request trace会初始化一个回路，server最终的响应信息，将会通过回路发送给客户端。

3-11

客户端可以通过response的实体来查看到这些消息。以及在request、response响应连上，查看是否被毁坏过，或者修改过。trnace通常主要被用诊断。用于验证，request请求是否如愿通过了请求，响应连。它同时也是一种很好的工具，用来查看代理，或者其他应用的一些影响。虽然在诊断方面trace方法有很多好处，但是，它假定中间应用程序对对各种不同类型的请求处理是相同的（get，head，post）。但是很多http应用会根据不同类型的请求作出不同的事。例如代理会直接发送一个post的request给服务器，但是他也许会尝试发送一个get请求，给其他的http应用。（例如web cache），trace不提供区分这些方法的机制。

trace的request请求中，不能带有实体。trace的响应实体，包括来自服务器的响应实体。

options

options 方法请求服务器告诉我们，web server支持哪几种方法、你可以询问服务器对通常，或者特别的资源支持哪几种方法？（一些服务器，在特别的资源上，支持特别的操作。）这位客户端提供一种通道，能够准确找到最好获取资源的方法。图3-12展示了使用options的方法

delete

delete方法即你通过一个request的url告诉服务器你需要删除的资源。然后客户端，不能保证delete是否被执行了。因为http规范，允许服务器请求被覆盖，而不告诉客户端。图3-13展示了一个delete方法。

extension method

http 被设计的可以扩展。所以一些新的特征，在一些比较旧的软件将会出现问题。扩展方法是一种在http1.1规范中没有定义的方法。服务器将会为它管理的资源实现一些http服务。这些方法，为开发这者提供一种扩展这些http服务能力的一些手段。表3-5列出了这些方法，这些方法就是webdavhttp的扩展。（详细看19章），这些方法有助于通过http将web发布到服务器上去。

表3-5

并不是所有的方法都是在http规范中定义的。认识到这一点很重要。如果你定义了一种扩展方法。很可能大部分http应用都不能理解。因此，你的http应用中所用的扩展方法，对于其他的应用而言不能被理解。

在这些情况下，扩展方法应该是宽容的。如果能在不破坏端到端的行为下，将未知的报文传向下一个服务器。代理会尝试传输这些报文。否则将会返回一个501的错误。最好的规则是，对所发的内容严格一点，对所接收的内容松一点。

Status Codes

http状态码被分为5大类。在表3-2中，已经有简单的总结。状态码提供了一种简单的方式，帮助客户端理解结果处理情况。在这一节中，我们列出了原因短语。尽管美欧实际的规范对原因短语进行指导。在这里还包含了http1.1的规范使用的原因短语。

100-199状态码信息：

http1.1向协议引入了信息性状态码。这些状态码相对较新，由于其对复杂性和感知价值存在争论。在表3-6中列出了定义的信息状态码。

100 continue状态码，尤其让人疑惑。他的目的是对这样的情况进行优化：http应用客户端有一个实体的主体部分要发送给服务器。但在发送之前希望查看一下服务器是否接受。这可能会给http程序员带来困扰。因此在这里我们将讨论更多的细节

客户端发送一个实体给服务器，并且愿意等待100 continue的响应在发送之前。那么客户端就要发送一个写来了100-continue的expect请求首部。如果客户端没有发送实体。就不应该发送100-continue expect的首部。因为这样服务器会认为你要发送一个实体。

100-continue，在多方面来看，是一种优化。一个客户端应用应该使用100-continue从而避免发送给服务器一个较大的实体，从而导致了服务器不能处理，使用。因为围绕着100-continue状态有一些争论。（而且以前一些实现在这里出过一些问题）因此发送了100-continue expext的客户端不用一直等待，服务器响应发送一个100-continue的状态码。如果超时了，客户端应该发送实体。

在实践中。客户端实现应该准备处理100-continue的状态码有些出错的http应用，会无故的发送这些代码。