HTTP协议详解2--请求头与响应头

一、简介

从web客户端发往web服务器的http报文称为请求报文(request message),从服务器发往客户端的报文称为响应报文(response message),此外没有其它类型的http报文。

http请求和响应报文的格式很类似,都包括以下3个部分:

  • 起始行(start line)
    报文的第一行就是起始行,在请求报文中用来说明要做些什么,在响应报文中说明出现了什么情况。

  • 首部字段(header)
    起始后面有零个或多个首部字段。每个首部字段都包含一个名字和一个值,为了便于解析,两者之间用冒号(:)来分隔。首部以一个空格结束。添加一个首部字段和添加新行一样简单。

  • 主体(body)
    空行之后就是可选的报文主体了,其中包含了所有类型的数据。请求主体中包括了要发送给web服务器的数据;响应主体中装载了要返回给客户端的数据。起始行和首部都是文本形式且都是结构化的,而主体则不同,主体中可以包含任意的二进制数据(比如图片、视频、音轨、软件程序)。当然,主体中也可以包含文本。

GET实例

二、语法

请求报文与响应报文只有起始行的语法有所不同。

1、请求报文:

<method> <request-URL> <version>
<headers>

<entity-body>

如:

GET /test/hi.txt HTTP/1.1
Accept: text/*
Host: www.test.com

2、响应报文:

<version> <status> <reason-phrase>
<headers>

<entity-body>

如:

HTTP/1.1 200 OK
Content-type: text/plain
Content-length: 19

Hi! I'm a message!

三、抓包

我们常用的HTTP抓包工具有如fiddler、firebug等,大家根据自己的喜好选择自己的工具。

如下是我使用firebug抓取到的一个http请求及响应包:

四、首部

HTTP首部字段可以分为如下几类:通用首部、请求首部、响应首部、实体首部、扩展首部。
每个HTTP首部都有一种简单的语法:名字后面跟着冒号(:),然后跟上可选空格,再跟上字段值,最后是一个CRLF。

1、通用首部
有些首部提供了与报文相关的最基本信息,它们被称为通用首部。客户端和服务器都可以使用这些通用首部。

首部 描述 举例
Connection 允许客户端和服务器端指定与请求/响应连接有关的选项 Connection: close
Date 报文创建的日期和时间 Date: Tue, 3 Oct 1974 02:16:00 GMT
MIME-Version 给出了发送端使用的MIME版本 MIME-Version: 1.0
Trailer 说明报文拖挂中提供了哪些首部 Trailer: Content-Length
Trailer-Encoding 告知接收端为了保证报文的可选传输,对报文采用什么编码方式 Trailer-Encoding: chunked
Update 给出了发送端可能想要“升级”使用的新版本或协议
Via 显示了报文经过的中间节点(代理、网关) Via: joes-hardware.com (Joes-Server/1.0)
Cache-Control 给出了与某个对象可缓存性有关的缓存特有指令 Cache-Control: no-cache
Pragma 用于随报文传送一些指令,但并不专用于缓存 Pragma: no-cache

2、请求首部
请求首部是只在请求报文中有意义的首部。用于说明是谁或什么在发送请求、请求源自何处,或者客户端的喜好能力、服务器可以根据请求首部给出的客户端信息,试着为客户端提供更好的响应。

以下将对请求首部进行分类介绍:

  • 请求的信息性首部
首部 描述 举例
Client-IP 提供了运行客户端的机器的IP地址 Client-ip: 209.1.33.49
From 提供了客户端用户的E-mail地址 From: test@inktomi.com
Host 提供了客户端想要访问的那台机器的因特网主机名和端口号 Host: www.test.com:80
Referer 使服务器知道客户端是从哪里获得其请求的URL Referer: http://www.test.com/index.html
UA-Color 客户端显示器的显示颜色有关的信息 UA-Color: color8
UA-CPU 客户端CPU的类型或制造商 UA-CPU: x86
UA-Disp 客户端显示器能力有关的信息 UA-Disp: 640, 480, 8
UA-OS 客户端的操作系统名称及版本 UA-OS: Windows 95
UA-Pixels 显示器的像素信息 UA-Pixels: 640 x 480
User-Agent 发起请求的应用程序名称 User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
  • Accept首部
    Accept首部为客户端提供了一种将其喜好和能力告知服务器的方式,包括它们想要什么,可以使用什么,以及最重要的,它们不想要什么。这样,服务器就可以根据这些额外信息,对要发送的内容做出更明智的决定。Accept首部会使连接的两端都受益。客户端会得到它们想要的内容,服务器则不会浪费其时间和带宽来发送客户端无法使用的东西。
首部 描述 举例
Accept 告诉服务器能够发送哪些媒体类型 Accept: text/*, image/*
Accept-Charset 告诉服务器能够发送哪些字符集 Accept-Charset: iso-latin-1
Accept-Encoding 告诉服务器能够发送哪些编码方式 Accept-Encoding: compress;q=0.5,
Accept-Language 告诉服务器能够发送哪些语言 Accept-Language: en; q=0.7, en-gb;q=0.5
TE 告诉服务器可以使用哪些扩展传输编码 TE: chunked
  • 条件请求首部
    有时客户端希望为请求加上某些限制。比如,如果客户端已经有了一份文档副本,就希望只有服务器上的文档与客户端拥有的副本有所区别时,才请求服务器传输文档。通过条件请求首部,客户端就可以为请求加上这种限制,要求服务器在对请求进行响应之前,确保某个条件为真。
首部 描述 举例
Expect 允许客户端列出某请求所要求的服务器行为 Expect: 100-continue
If-Match 如果实体标记与文档当前的实体标记相匹配,就获取这份文档 If-Match: "11e92a-457b-31345aa"
If-Modified-Since 除非在某个指定的日期之后资源被修改过,否则就限制这个请求 If-Modified-Since: Thu, 03 Oct 1997 17:15:00 GMT
If-None-Match 如果提供的实体标记与当前文档的实体标记不相符,就获取文档 If-None-Match: "11e92a-457b-31345aa"
If-Range 允许对文档的某个范围进行条件请求 If-Range: "11e92a-457b-31345aa"
If-Unmodified-Since 除非在某个指定日期之后资源没有被修改过,否则就限制这个请求 If-Unmodified-Since: Thu, 03 Oct 1997 17:15:00 GMT
Range 如果服务器支持范围请求,就请求资源的指定范围 Range: 500-1500
  • 安全请求首部
    HTTP本身就支持一种简单的机制,可以对请求进行质询/响应认证。这种机制要求客户端在获取特定的资源之前,先对自身进行认证,这样就可以使事务稍微安全一些。
首部 描述 举例
Authorization 包含了客户端提供给服务器,以便对其自身进行认证的数据(否则会收到401错误) Authorization: Basic gfujhver9854fcjyf54wfku6
Cookie 客户端用它向服务器传送一个令牌(它并不是一个真正的安全首部,但确实隐含了安全功能) Cookie: ink=ghfdytfuyt76dyc76ru5rju7ft76
Cookie2 用来说明请求端支持的cookie版本 Cookie2: $version="1"
  • 代理请求首部
    随着因特网上代理的普遍应用,人们定义了几个首部来协助其更好地工作。
首部 描述 举例
Max-Forward 这个首部只能和TRACE方法一起使用,以指定请求所经过的代理或其它中间节点的最大数目 Max-Forward: 5
Proxy-Authorization 与Authorization首部相同,但这个首部是在与代理进行认证时使用的 Proxy-Authorization: Basic gfujhver9854fcjyf54wfku6
Proxy-Connection 与Connection首部相同,但这个首部是在与代理建立连接时使用的 Proxy-Connection: close

3、响应首部
响应首部为客户端提供了一些额外信息,比如谁在发送响应、响应者的功能,甚至与响应相差的一些特殊指令。这些首部有助于客户端处理响应,并在将来发起更好的请求。

  • 响应的信息首部
首部 描述 举例
Age (从最初创建开始)响应持续时间,以秒为单位 Age: 60
Public 服务器为其资源支持的请求方法列表 Public: OPTIONS, GET, HEAD, TRACE, POST
Retry-After 如果资源不可用的话,在此日期或时间重试(可以与503状态码配合使用) Retry-After: Thu, 3 Oct 1997 17:15:00 GMT
Server 服务器应用程序的名称和版本 Server: Websitepro/1.1s (s/n wpo-07d0)
Title 对HTML文档来说,就是HTML文档的源端给出的标题 Title: decument-title
Warning 比原因短语中更详细的一些警告报文 Warning: 113
  • 协商首部
    如果资源有多种表示方法——比如,如果服务器上有某文档的法语和德语稿,HTTP/1.1可以为服务器和客户端提供对资源进行协商的能力。
首部 描述 举例
Accept-Ranges 服务器可以接受对资源的哪个范围类型进行访问 Accept-Ranges: bytes
Vary 服务器通过Vary首部来通知客户端,有服务器端的协商中会使用哪些来自客户端请求的首部。它的值是一个首部列表,服务器去查看这些首部,以确定将什么内容作为响应发回给客户端 Vary: User-Agent
  • 安全响应首部
    我们已经看到过安全请求首部了,本质上这里说的就是HTTP的质询/响应认证机制的响应侧。
首部 描述 举例
Proxy-Authenticate 来自代理的对客户端的质询列表 Proxy-Authenticate: Basic realm="Super Secret Corporate FinancialDocuments"
Set-Cookie Set-Cookie首部是Cookie首部的搭档。(不是真正的安全首部,但隐含有安全功能;可以在客户端设置一个令牌,以便服务器对客户端进行标识) Set-Cookie: private_id=519; secure
Set-Cookie2 与Set-Cookie类似,是对Set-Cookie首部的扩展,RFC 2965 Cookie定义 Set-Cookie2: ID="23453"; Domain=".test.com"
WWW-Authenticate 来自服务器的对客户端的质询列表(用于401响应) WWW-Authenticate: Basic realm="Your Private Travel Profile"

4、实体首部
有很多首部可以用来描述HTTP报文的负荷。由于请求和响应报文中都可能包含实体部分,所以在这两种类型的报文中都有可能出现这些首部。
实体首部提供了有关实体及其内容的大量信息。

  • 实体的信息首部
首部 描述 举例
Allows 列出了可以对此实体执行的请求方法 Allows: GET, HEAD
Location 告知客户端实体实际上位于何处;用于将接收端定向到资源的(可能是新的)位置(URL)上去 Location: http://www.test.com
  • 内容首部
    内容首部提供了与实体内容有关的特定信息,说明了其类型、尺寸以及处理它所需的其它有用信息。
首部 描述 举例
Connect-Base 解析主体中的相对URL时使用的基础URL Connect-Base: http://www.test.com/
Connect-Encoding 对主体执行的任意编码方式(告知客户端,服务器对对象执行过哪种或哪些类型的编码) Connect-Encoding: gzip
Connect-Language 理解主体时最适宜使用的自然语言 Connect-Language: en
Connect-Length 主体的长度或尺寸 Connect-Length: 2434
Connect-Location 资源实际所在的位置 Connect-Location: http://www.test.com/index.html
Connect-MD5 主体的MD5校验和 Connect-MD5: jygi2uy3pi1guy64uyfg==
Connect-Range 在整个资源中此实体列示的范围 Connect-Range: bytes 500-999 / 5400
Connect-Type 这个主体的对象类型 Connect-Type: text/html; charset=iso-latin-1
  • 实体缓存首部
    通用的缓存首部说明了如何或什么时候进行缓存。实体的缓存首部提供了与被缓存实体有关的信息——比如,验证已缓存的资源副本是否仍然有效所需的信息,以及更好地估计已缓存资源何时失效所需的线索。
首部 描述 举例
ETag 与此实体相差的实体标记 ETag: W/"11e92a-457b-3134b6aa"
Expires 实体不再有效,要从原始的源端再次获取此实体的日期和时间 Expires: Thu, 03 Oct 1997 17:15:00 GMT
Last-Modified 这个实体最后一次被修改的日期和时间 Last-Modified: Thu, 03 Oct 1997 17:15:00 GMT

参考

《HTTP权威指南》 David Gourley, Brian Totty, Marjorie Sayer, Sailu Reddy, Ansbu Aggarwal 著 陈涓 赵振平 译
RFC:https://tools.ietf.org/html/rfc2616(查看第14章)
W3C:https://www.w3.org/Protocols/rfc2616/rfc2616.html(查看第14章)

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,393评论 5 467
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,790评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,391评论 0 330
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,703评论 1 270
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,613评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,003评论 1 275
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,507评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,158评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,300评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,256评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,274评论 1 328
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,984评论 3 316
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,569评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,662评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,899评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,268评论 2 345
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,840评论 2 339

推荐阅读更多精彩内容