Http协议具体解释

一、HTTP协议的URL

HTTP URL (URL是一种特殊类型的URI。包括了用于查找某个资源的足够的信息)的格式例如以下:

http://host[":"port][abs_path]

http表示要通过HTTP协议来定位网络资源;

host表示合法的Internet主机域名或者IP地址;

port指定一个port号。为空则使用缺省port80;

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

二、 Http协议的内容

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(回车和换行)隔开,表示报头域的结束.

2.1 行(start-line)

(2.1.1) 请求行(Request-Line)

请求行以一个方法符号开头。以空格分开。后面跟着请求的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 请求server存储一个资源,并用Request-URI作为其标识

DELETE 请求server删除Request-URI所标识的资源

TRACE 请求server回送收到的请求信息。主要用于測试或诊断

CONNECT 保留将来使用

OPTIONS 请求查询server的性能,或者查询与资源相关的选项和需求

应用举例:

GET方法:在浏览器的地址栏中输入网址的方式訪问网页时。浏览器採用GET方法向server获取资源,

eg:GET /form.html HTTP/1.1 (CRLF)

POST方法要求被请求server接受附在请求后面的数据。经常使用于提交表单。

eg:POST /reg.jsp HTTP/ (CRLF)

(2.1.2) 状态行(Status-Line)

响应的行称为状态行,格式例如以下:HTTP-Version Status-Code Reason-Phrase CRLF

当中。HTTP-Version表示serverHTTP协议的版本号。

Status-Code表示server发回的响应状态代码;

Reason-Phrase表示状态代码的文本描写叙述。

状态代码有三位数字组成。第一个数字定义了响应的类别,且有五种可能取值:

1xx:指示信息--表示请求已接收,继续处理

2xx:成功--表示请求已被成功接收、理解、接受

3xx:重定向--要完毕请求必须进行更进一步的操作

4xx:client错误--请求有语法错误或请求无法实现

5xx:server端错误--server未能实现合法的请求

eg:HTTP/1.1 200 OK (CRLF)

2.2 报头(Message Header)

HTTP头字段包含4类: general-header ; request-header ; response-header ; entity-header .

(2.2.1) 常规头(General 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同样。

(2.2.2) 请求头(Request Header)

请求头域可能包括下列字段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 指定client可以接收的内容类型 Accept: text/plain, text/html
Accept-Charset 浏览器能够接受的字符编码集。

Accept-Charset: iso-8859-5
Accept-Encoding 指定浏览器能够支持的webserver返回内容压缩编码类型。

Accept-Encoding: compress, gzip
Accept-Language 浏览器可接受的语言 Accept-Language: en,zh
Host 指定请求的server的域名和port号 Host: www.zcmhi.com
From 发出请求的用户的Email From: [email protected]
Referer 先前网页的地址。当前请求网页紧随其后,即来路 Referer: http://www.zcmhi.com/archives/71.html
User-Agent User-Agent的内容包括发出请求的用户信息 User-Agent: Mozilla/5.0 (Linux; X11)

(2.2.3) 响应头(Response Header)

响应头域同意server传递不能放在状态行的附加信息,

这些域主要描写叙述server的信息和 Request-URI进一步的信息。

响应头域包括Age、Location、Proxy-Authenticate、Public、

Retry-After、Server、Vary、Warning、WWW-Authenticate。

Header 解释 演示样例
Age 从原始server到代理缓存形成的估算时间(以秒计,非负) Age: 12
Location 用来重定向接收方到非请求URL的位置来完毕请求或标识新的资源 Location: http://www.zcmhi.com/archives/94.html
Proxy-Authenticate 它指出认证方案和可应用到代理的该URL上的參数 Proxy-Authenticate: Basic
Server webserver软件名称 Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Retry-After 假设实体临时不可取。通知client在指定时间之后再次尝试 Retry-After: 120
Vary 告诉下游代理是使用缓存响应还是从原始server请求 Vary: *
Warning 警告实体可能存在的问题 Warning: 199 Miscellaneous warning
WWW-Authenticate 表明client请求实体应该使用的授权方案 WWW-Authenticate: Basic

(2.2.4) 实体头(Entity Header)

实体头域包括关于实体的原信息,实体头包括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 webserver支持的返回内容压缩编码类型。 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。

2.3 消息体(Message Body)

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>

三、 參考资料

(1)

type=5" style="color:rgb(51,122,183); text-decoration:none">状态码具体信息

(2)很多其它消息头的信息

(3)Http/1.1 Document

(4)RFC Archives

原创转自:http://beadlechen.github.io/

时间: 2025-01-06 00:19:59

Http协议具体解释的相关文章

VRRP协议具体解释

转帖:http://blog.chinaunix.net/space.php?uid=11654074&do=blog&id=2857384 Contents                                                                                                                                   Page 文件夹 入木三分学网络第一篇--VRRP协议具体解释... 1

SSL协议具体解释

背景介绍    近期在看<password学与网络安全>相关的书籍,这篇文章主要具体介绍一下著名的网络安全协议SSL. 在開始SSl介绍之前,先给大家介绍几个password学的概念和相关的知识.     1.password学的相关概念 password学(cryptography):目的是通过将信息编码使其不可读,从而达到安全性. 明文(plain text):发送人.接受人和不论什么訪问消息的人都能理解的消息.密文(cipher text):明文消息经过某种编码后,得到密文消息.加密(e

android蓝牙协议名词解释 OPP HFP HDP A2DP PAN

各种蓝牙协议的全称: OPP:对象存储规范(Object Push Profile),最为常见的,文件的传输都是使用此协议. HFP:(Hands-free Profile),让蓝牙设备可以控制电话,如接听.挂断.拒接.语音拨号等,拒接.语音拨号要视蓝牙耳机及电话是否支持. HDP: HDP (Health Device Profile) 蓝牙医疗设备模式   可以创建支持蓝牙的医疗设备,使用蓝牙通信的应用程序,例如心率监视器,血液,温度计和秤. A2DP: Advanced Audio Dis

ARP协议具体解释之ARP动态与静态条目的生命周期

ARP协议详细解释之ARP动态与静态条目的生命周期 ARP动态条目的生命周期 动态条目随时间推移自己主动加入和删除. q??每一个动态ARP缓存条目默认的生命周期是两分钟.当超过两分钟,该条目会被删掉.所以,生命周期也被称为超时值. q??延长规则:当ARP条目已存在.使用该条目后,将会重设超时值为两分钟. [实例1-12]以下将验证动态条目的生命周期是两分钟.详细操作过程例如以下所看到的: (1)查看本机的ARP缓存表.运行命令例如以下所看到的: C:\Documents and Settin

SNMP协议具体解释

简单网络管理协议(SNMP)是TCP/IP协议簇的一个应用层协议.在1988年被制定,并被Internet体系结构委员会(IAB)採纳作为一个短期的网络管理解决方式:因为SNMP的简单性,在Internet时代得到了蓬勃的发展,1992年公布了SNMPv2版本号,以增强SNMPv1的安全性和功能.如今,已经有了SNMPv3版本号. 一套完整的SNMP系统主要包含管理信息库(MIB).管理信息结构(SMI)及SNMP报文协议. (1)管理信息库MIB:不论什么一个被管理的资源都表示成一个对象,称为

Fastcgi协议定义解释与说明

1 响应格式如(十六进制方式显示) 序列 0 1 2 3 4 5 6 7 ... 数值 01 06 00 01 01 1D 03 00... 序列0(值01)为version,固定取1即可序列1(值06)为type,代表FCGI_STDOUT,表示应用的输出序列2 3(00 01)代表2字节的请求id,默认取1即可(准确说应该是和请求应用时发送的id一致,这里假设请求和响应的id都是1)序列4 5(01 1D)代表2字节的输出长度,最大为65535,例如当前内容长度为(0x01 << 8) +

Robots协议具体解释

禁止搜索引擎收录的方法(robots.txt) 一.什么是robots.txt文件? 搜索引擎通过一种程序robot(又称spider),自己主动訪问互联网上的网页并获取网页信息.您能够在您的站点中创建一个纯文本文件robots.txt,在这个文件里声明该站点中不想被robot訪问的部分,这样,该站点的部分或所有内容就能够不被搜索引擎收录了,或者指定搜索引擎仅仅收录指定的内容. 二.robots.txt文件放在哪里? robots.txt文件应该放在站点根文件夹下.举例来说,当robots訪问一

网络七层协议形象解释

第一层,物理层  OSI模型最低层的"劳苦大众".它透明地传输比特流,就是传输的信号.该层上的设备包括集线器.发送器.接收器.电缆.连接器和中继器. 第二层,数据链路层 这一层是和包结构和字段打交道的和事佬.一方面接收来自网络层(第三层)的数据帧并为物理层封装这些帧:另一方面数据链路层把来自物理层的原始数据比特封装到网络层的帧中.起着重要的中介作用. 数据链路层由IEEE802规划改进为包含两个子层:介质访问控制(MAC)和逻辑链路控制(LLC). 智能集线器.网桥和网络接口卡(NIC

网络通信-在浏览器输入url,基于TCP/IP协议的解释

知识点1: 网络模型 TCP/IP四层 和ISO七层模型 (统一省略后面层字.比如传输代表传输层) 知识点2: 在应用层中TCP建立连接,经历的三次握手协议 首先:,TCP协议是什么? 为什么要三次握手? 答:TCP协议是面向连接的,而且是点对点的可靠(无差错.不丢失.不重复.按顺序)数据传输服务,他的一些特点,字节流.连接建立后随时传输数据, 其次,握手的目的是在通知对方自己的初始化序号(Initial Sequence Number),简称ISN,保证数据不混乱. 然后: 三次握手的过程是什