上面的请求消息例子符合这个格式，不过一般格式中还有一个位于各个头部(及额外的回车符和换行符)之后的“附属体”(毗叮body)。附属体不在GET方法中使用，而是在POST方法中使用。POST方法适用于需由用户填写表单的场合，如往google搜索引擎中填入待搜索的词。用户提交表单后，浏览器就像用户点击了超链接那样仍然从服务器请求一个Web页面，不过该页面的具体内容却取决于用户填写在表单各个字段中的值。如果浏览器使用POST方法提出该请求，那么请求消息附属体中包含的是用户填写在表单各个字段中的值。与GET方法类似的是HEAD方法，两者的差别只是服务器在对HEAD方法的响应消息中去掉了所请求的对象，其他内容则与对GET方法的响应消息一样。HEAD方法通常用于HTTP服务器软件开发人员进行调试。
　　
　　HTTP响应消息
　　
　　下面是一个典型的HTTP响应消息:
　　
　　HTTP/1.1 200 0K
　　Connectlon:close
　　Date: Thu, 13 Oct 2005 03:17:33 GMT
　　Server: Apache/2.0.54 (Unix)
　　Last—Nodified:Mon,22 Jun 1998 09;23;24 GMT
　　Content—Length:682l
　　Content—Type:text/html
　　
　　(数据 数据 数据 数据 数据…………)
　　
　　这个响应消息分为3部分：1个起始的状态行(status line)，6个头部行、1个包含所请求对象本身的附属体。状态行有3个字段:协议版本字段、状态码字段、原因短语字段。本例的状态行表明，服务器使用HTTP/1.1版本，响应过程完全正常(也就是说服务器找到了所请求的对象，并正在发送)。
　　
　　现在看一下本例中的各个头部行。服务器使用Connectlon:close头部行告知客户自己将在发送完本消息后关闭TCP连接。Date:头部行指出服务器创建并发送本响应消息的日期和时间。注意，这并不是对象本身的创建时间或最后修改时间，而是服务器把该对象从其文件系统中取出，插入响应消息中发送出去的时间。Server:头部行指出本消息是由Apache服务器产生的;它与HTTP请求消息中的User-agent:头部行类似。Last—Nodified:头部行指出对象本身的创建或最后修改日期或时间。Last—Nodified:头部对于对象的高速缓存至关重要，且不论这种高速缓存是发生在本地客户主机上还是发生在网络高速缓存服务器主机(也就是代理服务器主机)上。Content—Length:头部行指出所发送对象的字节数。Content—Type:头部行指出包含在附属体中的对象是HTML文本。对象的类型是由Content—Type:头部而不是由文件扩展名正式指出的。
　　
　　注意，如果服务器收到一个HTTP/1.0的请求，那么它即使是一个HTTP/1.1服务器，也不会使用持久连接。相反，这样的HTTP/1.1服务器会在发出所请求的对象后关闭TCP连接。这么做是必要的，因为HTTP/1.0客户期待服务器马上关闭连接。
　　
　　我们接着看一下如下图所示的响应消息的一般格式。前面的响应消息例子完全符合这个格式。响应消息中的状态码和原因短语指示相应请求的处理结果，下面列出了一些常见的状态码和相应的原因短语:
　　

　　
　　●200 0K;请求成功，所请求信息在响应消息中返回。
　　
　　●301 Moved Permanently:所请求的对象己永久性迁移;新的URL在本响应消息的Location:头部指出。客户软件会自动请求这个新的URL。
　　
　　●400 Bad Request;表示服务器无法理解相应请求的普通错误的状态码
　　
　　●404 Not Found:服务器上不存在所请求的文档。
　　
　　●HTTP Version Not Support:服务器不支持所请求的HTTP协议版本。
　　
　　你想如何看到一个真实的H1TP应答消息呢?这非常简单。可以使用nc工具连接到你喜欢的服务器(nc/netcat是一个黑客很喜欢用的工具，可以方便在主机之间建立TCP连接)，然后输入一行请求消息，用来请求位于该服务器上的某个对象。例如，如果你可以输入以下指令:
　　
　　nc www.chinaitlab.com 80
　　GET /index.shtml　HTTP/1.0
　　
　　(在输入第二行之后，敲两次回车)，这就打开了一个到主机www.chinaitlab.com的端口80的TCP连接，然后发送HTTP GET命令。你应该能看到包含着YESKY主页的基本HTML文件的应苔消息。如果你想只看到HTTP消息行而不接收该对象本身，那么就把上面的GET换成HEAD。最后，看一下能得到什么样的应答消息。
　　
　　在这里我们讨论了大量能够在HTTP请求和应答消息中使用的头部行。HTTP规范(尤其是HTTP/1.1)定义了更多可以由浏览器、Web服务器和网络缓冲服务器插入的头部行。
　　
　　我们可以便用nc工具完全控制在请求消息中包含哪些头部，那么浏览器如何决定该在请求消息个包含哪些头部呢?Web服务器又是如何决定该在响应消息中包含哪些头部?浏览器是根据自己的用户代理类型、所支持的HTTP版本(HTTP/1.0版本的浏览器自然不会产生HTTP/1.1版本的头部)、用户对浏览器的配置(如所偏爱的语言)等因素生成请求消息中的各个头部的。web服务器有类似的情形:它们有不同的产品、版本和配置，所有这些因素都会影响在响应消息中包含哪些头部。
　　
　　本文讨论过的和即将讨论的用于HTTP请求消息和响应消息中的头部仅仅是很小的一部分，HTTP规范中定义了更多可用的头部，可以查阅相关的RFC文档进行更详细的了解。

　　用户—服务器交互
　　
　　身份认证和cookie
　　
　　我们已经知道HTTP服务器是无状态的。这样的处理可以简化服务器程序的设计，以便开发出更高性能的Web服务器软件。然而，一个Web站点往往有标识其用户的需求，因为其web服务器可能希望限制用户的访问，也可能想要根据用户的身份来提供内容。HTTP提供了两种帮助服务器标识用户的机制:身份认证和cookle。
　　
　　身份认证许多web站点要求用户提供一个用户名—口令对才能访问存放在其服务器中的文档。这种要求称为身份认证(authentication)。HTTP提供特殊的状态码和头部来帮助Web站点执行身份认证。我们通过查看一个例子来领会这些特殊的状态码和头部如何工作。假设有—个客户在请求来自某个服务器的一个对象，而该服务器要求用户授予权限。
　　
　　客户首先发送一个不合特殊头部的普通请求消息。服务器以空的附属体和一个“401Authorization Required”状态码作为响应。服务器还在这个响应消息中包含“个WWW-Authenticate:头部，说明具体如何执行身份认证。这个头部的典型值是指出用户需要提供一个用户名—口令对。
　　
　　客户收到这个响应消息后提示用户输入用户名和口令，然后重新发送请求消息。这一回客户在请求消息中包含了一个Authorization:头部，其中包含有用户输入的用户名和口令。
　　
　　取得第一个对象后，客户在同为请求该服务器上对象的后续请求中继续发送这个用户名—口令对。这个做法一般将持续到用户关闭浏览器为止。在浏览器未被关闭之前，这个用户名—口令对是高速缓存着的，因此浏览器不会每请求一个对象就提示用户输入一次用户名和口令。通过上述方式，要求用户授权的Web站点就能标识出每个请求的用户了。
　　
　　我们需要知道，HTTP执行的是一种相当脆弱的身份认证方式，不难攻破。现代有很多更为安全的认证方式，我们会在以后介绍。
　　
　　cookie是一种可让Web站点用来跟踪用户的候选机制，定义在RFC 2109中。有些Web站点使用cookie，其他Web站点则不用。下面查看一个例子。假设一个客户首次联系一个使用cookie的web站点。服务器会在其响应中包含一个Set—Cookie:头部。该头部的值可以是一个由Web服务器产生的客户标识数.例如:
　　
　　Set-Cookie:1678453
　　
　　客户收到这个响应消息，看到其中的Set-Cookie:头部和标识数后，会在存放在客户主机中的某个特殊的cookie文件中添加一行。这一行一般包含服务器主机的主机名和这个与用户关联的标识数。在一段时间(如一个星期)之后请求同一个服务器时，由同一个用户启动的新客户会在请求消息中包含一个cookie头部，其值为早先由该服务器产生的标识数，例如:Cookie:1678453
　　
　　在这种方式中，服务器并不知道提出请求的用户的用户名，但是它确实知道该用户与一个星期前提出请求的用户是同一个。
　　
　　Web服务器有多个使用coohe的目的:
　　
　　●如果服务器要求身份认证，但又不想在同一用户每次访问本Web站点时都麻烦他输入用户名和口令，那么可以设置一个cookie。
　　
　　●如果服务器想要记住用户的偏好，以便在他们后续访问期间有目的地提供广告，那么可以设置一个cookie。
　　
　　●如果web站点提供购物服务，那么服务器可以使用cookie跟踪用户购买的物品，就是建立一个虚拟的购物车。
　　
　　需指出的是，cookie不适用于会从不同主机访问同一web站点的游动用户。这种情况下，该web站点会把同一个用户在不同主机上的使用看成是由新的用户执行的。
　　
　　带条件的GET
　　
　　Web高速缓存技术通过就近存取先前取得的对象来降低对象检索延迟，减少因特网上的web流量。Web的高速缓存既可以驻留在客户主机中，也可以驻留在中间网络高速缓存服务器主机中。我们将在稍后讨论网络高速缓存，这里只关注客户的高速缓存。
　　
　　Web高速缓存在降低用户可感知的响应时间的同时，却引入了一个新的问题——高速缓存中存放的对象的拷贝可能是过期的。换句话说，存放在web服务器中的对象可能己在客户高速缓存下它的一个拷贝之后被修改了。幸运的是，HTTP提供一个专门的机制，使得在允许客户进行高速缓存的同时，仍确保传递给浏览器的所有对象都是最新的。这个机制称为带条件的0ET(conditional GET)。满足条件(1)使用GET方法和(2)包含If-Modified-S1nce:头部的HTTP请求消息就是所谓的带条件的Get消息。
　　
　　我们通过查看一个例子来说明带条件的GET如何工作，向服务器请求一个尚未高速缓存的对象:
　　
　　GET /fruit/kiwi.gif HTTP/1.0
　　User—agent: Mozilla/4.0
　　
　　接着，web服务器把带这个对象的一个响应消息发送给客户:
　　
　　HTTP/1.0 200 OK
　　Date: Thu, 13 Oct 2005 05:33:47 GMT
　　Server: Apache/2.0.54 (Unix)
　　Last-Modified:Thu, 13 Oct 2005 02:32:47 GMT
　　Content-Type:image/gif
　　
　　(数据 数据 数据 数据 数据……)
　　
　　客户把这个对象显示给用户，同时把它保存在自己的本地高速缓存中客户还随该对象本身高速缓存最后修改日期与时间。一个星期之后，同一个用户请求同一个对象，而该对象仍然存放在高速缓存中。既然web服务器中的该对象有可能已在最近一个星期被修改过，于是浏览器发出一个带条件的GET消息，执行判定高速缓存的对象拷贝是否为最新的检查;
　　
　　GET /fruit/kiwi.gif HTTP/1.0
　　User—agent: Mozilla/4.0
　　If—Modlfied—Since:Thu, 13 Oct 2005 02:32:47 GMT
　　
　　其中，If—Modlfied—Since:头部的值就等于一个星期前由服务器发送的Last-Modified:头部的值。这个带条件的GET消息告知服务器，只有在该对象自所指定的时间以来被修改了的前提下才发送它。假设该对象在这段时间内未曾被修改过，那么服务器将发送一个附属体为空的响应消息给客户;
　　
　　HTTP/1.0 304 Not Modified
　　Date: Thu, 20 Oct 2005 05:33:47 GMT
　　Server: Apache/2.0.54 (Unix)
　　
　　我们看到，web服务器仍然发送——个响应消息作为带条件的GET消息的响应，不过其中不包含所请求的对象。包含该对象只会浪费带宽，并延长用户可感知的响应时间，特别是在该对象很大的时候。注意，这个响应消息的状态为“304 Not Modified”，它告知客户可以放心使用所请求对象的高速缓存版本。