理解HTTP协议之报文(三)

理解HTTP协议之报文(三)

首部

    前一个小节的重点是请求和响应报文的第一行(方法、状态码、原因短语和版本号)。

跟在起始行后面的就是零个、一个或多个HTTP首部字段。

    HTTP首部字段向请求和响应报文中添加了一些附加信息。本质上说，他们只有一些名/值对的列表。

比如，下面的首部行会向Content-Length首部字段赋值19：

Content-length: 19

 

1.首部分类

HTTP规范定义了几种首部字段。应用程序也可以随意发明自己所用的首部。HTTP首部可以分为以下几类。

 

• 通用首部

    既可以出现在请求报文中，也可以出现在相应报文中

• 请求首部

    提供更多有关请求的信息。

• 相应首部

    提供更多有关相应的信息。

• 实体首部

    描述主体的长度和内容，或者资源自身。

• 扩展首部

    规范中没有定义的新首部。

 

每个HTTP首部都有一种简单的语法：名字后面跟着冒号（:)，然后跟上可选的空格，再跟上字段值，最后是一个CRLF(换行符)。

常见首部如:

Date:Tue,30ct 1997 02:16:03 GMT  服务器产生相应的日期

Content-length: 15040    实体的主体部分包含了15040字节的数据

Content-type: image/gif   实体的主体部分是一个GIF图片

Accept: image/gif,image/jpeg,text/html  客户端可以接受GIF图片和JPEG图片及HTML

 

2.首部的延续行

将长的首部行分为多行可以提高可读性，多出来的每行前面至少有一个空格或制表符(tab)

例如：

Server: Test Server

    Version 1.0

在这个例子中，相应报文里面包含了一个Server首部，其值被划分成多个延续行。该首部的完整值为Test Server Version 1.0。

 

实体的主体部分

HTTP报文的第三部分是可选的实体主体部分。实体的主体是HTTP报文的负荷。

就是HTTP要传输的内容。

HTTP报文可以承载很多类型的数字数据：图片、视频、HTML文档、软件应用程序、信用卡事务、电子邮件等。

 

版本0.9的报文

HTTP版本0.9是HTTP协议的早期版本。也是有请求和响应组成，但请求中只包含方法和请求URL，响应中只包含实体。

它没有版本信息（它是第一个，而且是当时唯一的版本），没有状态码或原因短语，也没有首部。

这种简单的协议无法提供更多的灵活性，也无法实现本书中描述的大部分HTTP特性和应用。这里对其进行简要的描述，是仍然有一些客户端、服务器和其他应用程序在使用这个协议，应用程序的编写者应该清楚它的局限性。

方法

并不是每个服务器都实现了所有的方法。如果一台服务器要与HTTP1.1兼容，那么只要为其资源实现GET方法和HEAD方法就可以了。

即使服务器实现了所有的方法，这些方法的使用很可能也是受限制的。这些限制通常都是在服务器的配置中进行设置的，因此随着站点和服务器的不同而有所不同。

GET

GET是最常用的方法。通常用于请求服务器发送某个资源。HTTP/1.1要求服务器实现此方法。

HEAD

HEAD方法与GET方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就是允许客户端在未获取实际资源的情况下，对资源的首部进行检查。使用HEAD，可以：

• 在不获取资源的情况下了解资源的情况（比如，判断其类型）；
• 通过查看响应中的状态码，看看某个对象是否存在；
• 通过查看首部，测试资源是否被修改。

服务器开发者必须确保返回的首部与GET请求所返回的首部完全相同。遵循HTTP/1.1规范，就必须实现HEAD方法。

 

例如:

请求报文：

HEAD /seasonal/index-fall.html HTTP/1.1

Host: www.joes-hardware.com

Accept: *

 

响应报文：

HTTP/1.1 200 OK

Content-Type: text/html

Context-Length: 617

HEAD的相应报文没有实体的主体部分。

 

PUT

与GET从服务器读取内容相反，PUT方法会向服务器写入文档。有些发布系统允许用户创建web页面，并用PUT直接将其安装到服务器上去。

PUT方法的语义就是让服务器用请求的主体部分来创建一个由所请求的url命名的新文档，或者，如果那个URL已经存在的话，就用跟这个主体来替代它。

因为PUT允许用户对内容进行修改，所以很多web服务器都要求在执行put之前，用密码登陆。

POST

POST方法起初是用来向服务器发送数据的。PUT用于向服务器上的资源中存储数据。POST通常用它来支持HTML的表单。表单中填好的数据通常会被送给服务器，然后有服务器处理传过来的数据。

TRACE

    客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求。TRACE方法允许客户端在最终将请求发给服务器时，看看它变成了什么样子。

    TRACE请求会在目的服务器发起一个“环回”诊断。行程最后一站的服务器会弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间HTTP应用程序组成的请求/响应链上，原始报文是否，以及如何被摧毁或修改过。

    TRACE方法主要用于诊断；也就是说，用于验证请求是否如愿穿过了请求/相应链。他也是一种很好的工具，可以用来查看代理或其他应用程序对用户请求所产生的效果。

    尽管TRACE可以很方便的用于诊断，但它也有缺点，它假定中间应用程序对各种不同类型的请求（不同的方法---GET\HEAD\POST等）的处理时相同的。很多HTTP应用程序会根据方法的不同做出不同的事情。比如，代理可能会将POST请求直接发送给服务器，而将GET请求发送给另一个HTTP应用程序(比如WEB缓存)。TRACE并不提供区分这些方法的机制。通常，中间应用程序会自行决定对TRACE请求的处理方式。

    TRACE请求不能带有实体的主体部分。TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。

 

OPTIONS

OPTIONS方法请求WEB服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。

这位客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判定访问各种资源的最优方式。

DELETE

DELETE方法所做的事情就是请求服务器删除请求URL所指定的资源。

但是，客户端应用程序无法保证删除操作一定会执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。

扩展方法

HTTP被设计成字段可扩展的，这样新的特性就不会是老的软件失效了。扩展方法指的就是没有在HTTP/1.1规范中定义的一些方法。服务器会为他所管理的资源实现一些HTTP服务，这些方法为开发者提供了一种扩展这些HTTP服务能力的手段。