HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：
http://host[":"port][abs_path]
http表示要通过HTTP协议来定位网络资源；
host表示合法的Internet主机域名或者IP地址；
port指定一个端口号，为空则使用缺省端口80；
abs_path指定请求资源的URI；
如果URL中没有给出abs_path，那么当它作为请求URI时，
必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。
eg:
1、输入：www.guet.edu.cn
浏览器自动转换成：http://www.guet.edu.cn/
2、http:192.168.0.116:8080/index.jsp
Request and Response messages use the generic message format of RFC 822 [9] for transferring
entities (the payload of the message). Both types of message consist of a start-line,
zero or more header fields (also known as "headers"),
an empty line (i.e., a line with nothing preceding the CRLF)
indicating the end of the header fields, and possibly a message-body.
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
http协议请求和响应内容都由三部分组成，分别是：行(请求行和状态行)、报头(消息头)、正文(消息体)
消息头和消息体之间,用CRLF(回车和换行)隔开,表示报头域的结束.
请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，
格式如下：Method Request-URI HTTP-Version CRLF
其中 Method表示请求方法；
Request-URI是一个统一资源标识符；
HTTP-Version表示请求的HTTP协议版本,当前使用1.1；
CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。
请求方法（所有方法全为大写）有多种，各个方法的解释如下：
GET 请求获取Request-URI所标识的资源
POST 在Request-URI所标识的资源后附加新的数据
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 请求服务器存储一个资源，并用Request-URI作为其标识
DELETE 请求服务器删除Request-URI所标识的资源
TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求
应用举例：
GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，
eg:GET /form.html HTTP/1.1 (CRLF)
POST方法要求被请求服务器接受附在请求后面的数据，常用于提交表单。
eg：POST /reg.jsp HTTP/ (CRLF)
响应的行称为状态行,格式如下：HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服务器HTTP协议的版本；
Status-Code表示服务器发回的响应状态代码；
Reason-Phrase表示状态代码的文本描述。
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
eg：HTTP/1.1 200 OK （CRLF）
HTTP头字段包括4类： general-header ; request-header ; response-header ; entity-header .
general-header是request、response都可用的, 但是不能用于entity.
通用头域包含请求和响应消息都支持的头域，
包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。
Cache-Control
Cache -Control指定请求和响应遵循的缓存机制。
在请求消息或响应消息中设置 Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。
请求时的缓存指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached，
响应消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、
proxy-revalidate、max-age。
经常使用的就是no-cache,表示不缓存。
Date
Date头域表示消息发送的时间，时间的描述格式由rfc822定义。
例如，Date:Mon,31Dec200104:25:57GMT。
Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
Pragma
Pragma头域用来包含实现特定的指令，最常用的是Pragma:no-cache。
在HTTP/1.1协议中，它的含义和Cache- Control:no-cache相同。
请求头域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、
Accept-Language、Authorization、From、Host、If-Modified-Since、
If- Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、
Max-Forwards、 Proxy-Authorization、Range、Referer、User-Agent。
| Header | 解释 | 示例 |
|---|---|---|
| Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html |
| Accept-Charset | 浏览器可以接受的字符编码集。 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
| Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
| Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
| From | 发出请求的用户的Email | From: user@email.com |
| Referer | 先前网页的地址，当前请求网页紧随其后,即来路 | Referer: http://www.zcmhi.com/archives/71.html |
| User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
响应头域允许服务器传递不能放在状态行的附加信息，
这些域主要描述服务器的信息和 Request-URI进一步的信息。
响应头域包含Age、Location、Proxy-Authenticate、Public、
Retry-After、Server、Vary、Warning、WWW-Authenticate。
| Header | 解释 | 示例 |
|---|---|---|
| Age | 从原始服务器到代理缓存形成的估算时间（以秒计，非负） | Age: 12 |
| Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: http://www.zcmhi.com/archives/94.html |
| Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 | Proxy-Authenticate: Basic |
| Server | web服务器软件名称 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Retry-After | 如果实体暂时不可取，通知客户端在指定时间之后再次尝试 | Retry-After: 120 |
| Vary | 告诉下游代理是使用缓存响应还是从原始服务器请求 | Vary: * |
| Warning | 警告实体可能存在的问题 | Warning: 199 Miscellaneous warning |
| WWW-Authenticate | 表明客户端请求实体应该使用的授权方案 | WWW-Authenticate: Basic |
实体头域包含关于实体的原信息，实体头包括Allow、Content- Base、Content-Encoding、
Content-Language、 Content-Length、Content-Location、Content-MD5、
Content-Range、Content-Type、 Etag、Expires、Last-Modified、extension-header。
| Header | 解释 | 示例 |
|---|---|---|
| Allow | 对某网络资源的有效的请求行为，不允许则返回405 | Allow: GET, HEAD |
| Content-Encoding | web服务器支持的返回内容压缩编码类型。 | Content-Encoding: gzip |
| Content-Language | 响应体的语言 | Content-Language: en,zh |
| Content-Length | 响应体的长度 | Content-Length: 348 |
| Content-Location | 请求资源可替代的备用的另一地址 | Content-Location: /index.htm |
| Content-MD5 | 返回资源的MD5校验值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
| Content-Range | 在整个返回体中本部分的字节位置 | Content-Range: bytes 21010-47021/47022 |
| Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
| ETag | 请求变量的实体标签的当前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
| Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
| Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
看到这里你可能会很奇怪，为什么会没有Cookie，Content-Disposition这种常见的信息头？！
这里我说一下，Content-Disposition不是HTTP标准的一部分，但它在其他RFC文档中定义了（RFC1806）。
而Cookie呢？首先看看Cookie是用来干嘛的：Cookie和Session是为了解决Http协议中无状态的问题
，由于Http的设计者们时就没打算让Http有状态这种特性，故Cookie这种东西是肯定不可能
是Http标准中的一部分。其实，它们都属于上面所说的：extension-header。
The message-body (if any) of an HTTP message is used to carry the entity-body associated
with the request or response. The message-body differs from the entity-body only when a
transfer-coding has been applied, as indicated by the Transfer-Encoding header field.
(message-body = entity-body
| entity-body encoded as per Transfer-Encoding )
消息头和消息体之间是一个空行，这个行非常重要，它表示消息头已经结束，接下来的是消息体。
通常情况下Post方式请求的消息体,内容格式:param1=value1?m2=value2
响应的消息体常见有html和json的消息体,
json格式:{"key1":"value1","key2":"value2"}
html格式:
<!DOCTYPE html>
<html lang="zh-cn">
...
...
</html>
版权声明：本文为博主原创文章，未经博主允许不得转载。
原文地址：http://blog.csdn.net/beadle233/article/details/47128035
