新一篇: 中国龙即将腾飞 | 旧一篇: Linux程序设计——用getopt处理命令行参数
<script>function StorePage(){d=document;t=d.selection?(d.selection.type!='None'?d.selection.createRange().text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://www.365key.com/storeit.aspx?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t),'keyit','scrollbars=no,width=475,height=575,left=75,top=20,status=no,resizable=yes'));keyit.focus();}</script>本文对ＨＴＴＰ协议的内容做了一个简单的框架式的总结，主要记述了ＨＴＴＰ消息头部的各个选项，在文中对所有
选项都进行了简单的说明，需要详细说明的可以直接查看ＨＴＴＰ１.０的ＲＦＣ文档。
ＲＦＣ文档地址： http://man.chinaunix.net/develop/rfc/RFC1945.txt
一、HTTP URL定义
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]。
“http”表示要通过HTTP协议来定位网络资源。
host = <合法的Internet主机域名或IP地址（用十进制数及点组成）。
port = 如果没有指定缺省为８０。
二、ＨＴＴＰ 消息（HTTP消息由客户端到服务器的请求和由服务器到客户端的回应组成）
消息分为完整的消息和简单的消息，完整消息将进行详细说明，简单消息ＲＦＣ不推荐使用。
2.1、 简单的消息不允许使用任何标题域，并限制只能使用唯一的请求方法ＧＥＴ
简单的请求： Simple-Request = "GET" SP Request-URI CRLF
简单的响应： Simple-Response = [ Entity-Body ]
2.2、 完整的消息（请求或响应）包括请求行（响应状态行）、标题域和实体主体
三、请求行和响应状态行
3.1 请求行
格式： Request-Line = ＧＥＴ｜ＰＯＳＴ｜ＨＥＡＤ SP Request-URI SP HTTP-Version CRLF
3.2 响应状态行
格式：Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
四、 消息标题域
ＨＴＴＰ请求标题域包括主标题（Ｇｅｎｅｒａｌ－Ｈｅａｄｅｒ）、请求标题（Ｒｅｑｕｅｓｔ－Ｈｅａｄｅｒ）、实体标题（Ｅｎｔｉｔｙ－Ｈｅａd
ｅｒ），发送的顺序并不是必须的，最好是主标题，请求标题，实体标题，可以省略其中的一个或多个。
ＨＴＴＰ响应标题域包括主标题、响应标题、实体标题，发送的顺序也不是必须的，最好是主标题，响应标题，实体
标题， 可以省略其中的一个或多个。
五、主标题（Ｇｅｎｅｒａｌ－Ｈｅａｄｅｒ）
主标题是请求和响应都要使用的，但并不用于被传输的实体，这些标题只用于被传输的消息。
主标题包括Ｄａｔｅ和Ｐｒａｇｍａ两个。
5.1、Ｄａｔｅ（日期）
格式： Date: Tue, 15 Nov 1994 08:12:31 GMT
Ｄａｔｅ表示消息产生的时间，使用ＨＴＴＰ时间格式
5.2、Ｐｒａｇｍａ（注解）
格式： Pragma: "no-cache" | token [ "=" word ]
Prama主标题域包括一些可能对请求/回应链中的任一接收方有用的特殊指示信息。
六、请求标题域（Ｒｅｑｕｅｓｔ－Ｈｅａｄｅｒ）
请求标题域允许客户端向服务器端传递该请求的附加信息及客户端信息。包括Authorization、From、
If-Modified-Since、Referer、User-Agent。
6.1 Authorization（授权）
授权域值由信任证书组成，其中有对用户代理所请求资源领域的授权信息，对包含授权信息域的请求来说，其
回应是不能被缓存的。
6.2 From（来自）
格式： From: 1977_zlp@163.com
From请求标题域，如果给出来，则应包括一个使用此用户代理的人类用户的Internet e-mail地址。
6.3 If-Modified-Since（从何时更改）
格式： If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-Modified-Since请求标题域和GET方法一起使用，用于处理下面情况：当在该域指定的日期以来，请求资源没有
发生任何变更。这时，服务器将不会下传该资源的拷贝，即，回应不带任何实体主体，只是304状态码（未修改）。
6.4 Referer（提交方）
格式： Referer: www.baidu.com
提交方请求标题域是出于服务器端利益方面的考虑，允许客户端指明该链接的出处，即该指向资源地址的请求
URI是从哪里获得的。这样，服务器将产生一个备份链接（back-links）列表，用于维护受欢迎的资源、登录、缓存优化
等活动。
6.5 User-Agent（用户代理）
格式： User-Agent: wget/1.10.2
用户代理请求标题域包含用户原始请求的信息，这可用于统计方面的用途。通过跟踪协议冲突、自动识别用户代
理以避免特殊用户代理的局限性，从而做到更好的回应。虽然没有规定，用户代理应当在请求中包括此域。该域可包
含多个产品标识（3.7节）及注释以标识该代理及其重要的子产品。按照习惯，产品标识将按子产品对应用的重要性顺
序排列。
七、响应标题域（Response-Header）
回应标题域中包括不能放在状态行中的附加回应信息。该域还可以存放与服务器相关的信息，以及在对请求URL
所指定资源进行访问的下一步信息。包括Location、Server和WWW-Authenticate。
7.1 Location(位置)
格式：Location: http://www.w3.org/hypertext/WWW/NewLocation.html
Location回应标题域定义了由请求URI指定的资源的位置。对于3xx（重定向）回应，位置域必须能帮助服务器找到
相应的URL，以实现对资源的重定向。只允许用绝对URL。
7.2 Server（服务器）
格式：Server: Apache
服务器回应标题域包含由原始服务器用来处理请求的软件信息。该域可包含多个产品标识（3.7节）及注释以标识
服务器及重要的子产品。按照习惯，产品标识将按其应用的重要性顺序排列。
7.3 WWW-Authenticate（WWW-授权）
WWW-授权回应标题域必须被包括在401（未授权）回应消息中。该域值由一个以上的challenge组成，这些
challenge可用于指出请求URI的授权方案及参数。
八、主体标题域（Entity Header）
实体标题域中定义了一些可选的元信息，如有无实体、请求资源。包括Allow、Content-Encoding、Content-Length、 Content-Type、Expires、Last-Modified、extension-header。
8.1 Allow（允许）
格式： Allow: GET,HEAD
表示由请求URI所指定的资源支持在Allow实体标题域中列出的方法，目的是让接收方更清楚地知道请求此资源
的合法方式。Allow标题域不允许在POST方法中使用，如果非这么做，将被忽略。
8.2 Content-Encoding（内容编码）
格式： Content-Encoding: x-gzip
内容编码的实体标题域（entity-header）用作介质类型（media-type）的修饰符。它指明要对资源采用的附加内容
译码方式，因而要获得内容类型（Content-Type）标题域中提及的介质类型，必须采用与译码方式一致的解码机制。内
容编码主要用来记录文件的压缩方法。
8.3 Content-Length（内容长度）
格式： Content-Encoding: 1024
内容长度（Content-Length）实体标题域指明了发送到接收方的实体主体（Entity-Body）长度，用字节方式存储的
十进制数字表示。对于HEAD方法，其尺寸已经在前一次GET请求中发出了。
8.4 Content-Type（内容类型）
格式： Content-Type: text/html
值得格式为主类型/子类型格式。
8.5 Expires（过期）
格式： Expires: Thu, 01 Dec 1994 16:00:00 GMT
过期实体标题域中的日期/时间值指定了实体过期的时间。这为信息提供方提供了使信息失效的手段。当超过此
期限时，应用程序不应再对此实体进行缓存了。过期并不意味着原始资源会在此期限后发生改变或停止存在。在实践
应用中，信息提供者通过检查过期标题域中所指定的时间，从而获知或预测资源将会发生改变的确切日期。该格式用
的是绝对日期时间。
8.6 Last-Modified（最近更改）
格式： Last-Modified: Thu, 01 Dec 1994 16:00:00 GMT
Last-Modified实体标题域表示由发送方设定的资源最近修改日期及时间。该域的精确定义在于接收方如何去解
释它：如果接收方已有此资源的拷贝，但此拷贝比Last-Modified域所指定的要旧，该拷贝就是过期的。
8.7 extension-header（扩展标题）
标题（extension-header）机制允许在不改变协议的前提下定义附加的实体标题域，但是不能假定接收方可以识
别这些域。对于不可识别的标题域，接收方一般是忽略不管，而代理则继续将其向前推送。
九、主体实体（Entity Body）
实体主体只在请求方法有要求时才会被放在请求消息中。请求消息标题域处的内容长度标题域（Content-
Length header field）的标志将指明请求中的实体主体是否存在。包含实体主体的HTTP/1.0请求必须包含合法的内容
长度标题域。对回应消息来说，消息中是否包含实体主体取决于请求方法和回应代码。所有的HEAD请求方法的回应
都不应包括主体，即便是实体标题域中指明有主体也一样。在主体中不应包括这些回应信息，全部1xx（信息）、204（无
内容）和304（未修改）。而其它的回应必须包括实体主体或其内容长度标题（Content-Length header）域的定义值为
0。 当消息中包括实体主体，主体的数据类型由标题域中的内容类型（Content-Type）和内容编码（Content－
Encoding）决定。
总结：
在文中没有对响应状态的状态码进行详细的说明，也没有对字符集，介质类型等等进行说明，更详细的信息需
要查阅上面提到的ＲＦＣ文档，如果有什么问题，希望大家及时指正，共同进步！
发表于 @ 2008年05月28日 16:04:16|评论(0<script type="text/javascript">AddFeedbackCountStack("2490827")</script>)|编辑
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
