Http之报文

1 概述

HTTP报文是在HTTP程序之间发送的数据块,这些数据块以一些文本形式的元信息(meta-information)开头,描述了报文内容和含义。

2 报文流

HTTP使用流入(inbound)和流出(outbound)来描述事务处理(transaction)的方向。

  1. 流入是指报文从客户端或Agent流向源端服务器
  2. 流出是指报文源端服务器流向客户端或Agent代理

3 报文组成

HTTP报文由三部分组成:对报文进行描述的起始行(start line);包含属性的首部块(header);可选的,包含数据的,主体(Body)部分.起始行和首部就是由行分隔的ASCII文本,每行由回车换行(CRLF)序列作为结束。header和body之间以空行(仅有CRLF)分隔。

4 报文语法

HTTP报文可以分两类:请求(request)报文和响应(response)报文。

  1. 请求报文的格式

    <method> <request-URL> <verison>
    <headers>
    
    <entity-body>
  2. 响应报文的格式
    <verison> <status> <reason-phrase>
    <headers>
    
    <entity-body>
  3. 格式说明

    方法,客户端希望服务器对资源执行的动作。

    请求的URL

    HTTP协议的版本,格式为HTTP/<major>.<minor>

    状态码,请求响应情况,成功,超时,失败等。

    原因短语

    首部,可以有零个或多个首部,每个首部都包含一个名字,后跟一个冒号(:),然后是一个可选的空格,接着是一个值,最后是一个回车换行(CRLF).若是一个首部需要分多行,则第二行开始每行需要在开头的地方增加一个空格或者制表符(tab)。

    实体的主体部分,包含一个由任意数据组成的数据块。可以不包含实体。

5 <method>

方法 是否包含主体 描述
GET 获取指定的资源
HEAD 只从服务器获取文档的头部
POST 向服务器发送需要处理的数据(Html表单)
PUT 将请求的主体部分存储到服务器上
TRACE 对可能经过代理的报文进行跟踪
OPTIONS 请求服务器告知其支持的各种功能
DELETE 删除指定的资源
LOCK 锁定服务器资源
MKCOL 在服务器上创建资源
COPY 在服务器上复制资源
MOVE 在服务器上移动资源

6 状态码

范围 已定义范围 分类
100-199 100-101 信息提示
200-299 200-206 成功
300-399 300-305 重定向
400-499 400-415 客户端错误
500-599 500-505 服务器错误

其中具体的状态码详细说明如下:

  1. 100 Continue 说明服务器收到了请求的初始部分,请客户端继续。
  2. 101 Switching Protocols 服务器正在根据客户端的指定,将协议切换成Update首部所列的协议。

  1. 200 OK 正常返回
  2. 201 Created 用户创建服务器对象的请求(比如PUT),响应的实体主体部分应该包括各种引用了已创建的资源的URL
  3. 202 Accept 请求已被接收,但服务器还未执行任何动作。
  4. 203 Non-Authoritative Information 实体首部包含的信息不是来自于源端服务器,而是来自资源的一份副本。
  5. 204 No Content 响应报文中包含若干首部和一个状态行,但是木有实体的主体部分,用于浏览器刷新
  6. 205 Reset Content 告知浏览器清空当前页面所有html表单内容。
  7. 206 Partial Content 成功的执行了一个部分或范围(Range)请求。这个响应中必须包含Content-Range、Date以及ETag或Content-Location首部。

  1. 300 Multiple Choices 客户端请求一个实际指向多个资源的URL时会返回
  2. 301 Moved Permanently 请求的资源被移除时使用,响应的Location首部中应包含资源现在所处的URL
  3. 302 Found 类似301,区别是客户端应该使用Location首部给出的URL来临时定位资源。将来的请求仍使用老的URL。(HTTP1.0会将POST转GET请求)
  4. 303 See Other 告诉客户端应该使用另一个URL来获取资源。新的URL位于响应报文的Location首部(HTTP1.1 实现功能类似Http1.0下的302)
  5. 304 Not Modified 客户端可以通过所包含的请求首部,使其请求变成有条件的。此状态码的响应不应该包含实体的主体部分。
  6. 305 Use Proxy 用来说明必须通过代理来访问此资源。
  7. 306 未使用
  8. 307 Temporary Redirect 类似301,区别是客户端应该使用Location首部给出的URL来临时定位资源。将来的请求仍使用老的URL,这里不会主动POST转GET,而是询问客户端。

  1. 400 Bad Request 告知客户端它发生了一个错误的请求
  2. 401 Unauthorized 在返回的首部中申请客户端对服务器的访问权限,对自己进行认证。
  3. 402 Payment Required 保留
  4. 403 Forbidden 请求被服务器拒绝
  5. 404 Not Found 服务器无法找到请求的URL
  6. 405 Method Not Allowed 发起的请求带有服务器不支持的方法
  7. 406 Not Acceptable 服务器没有客户端指定参数说明的请求类型实体时,使用此代码
  8. 407 Proxy Authorized Required 与401类似,但这里用于要求对资源进行认证的代理服务器
  9. 408 Request Timeout 超时
  10. 409 Conflict 请求可能在资源上引起一些冲突。
  11. 410 Gone 类似404,只是服务器曾经有过此资源。
  12. 411 Length Required 服务器要求请求报文中包含Content-Length首部
  13. 412 Precondition Failed 客户端发起条件请求(例如包含Expect首部的请求),且有一个条件失败的时候使用
  14. 413 Request Entity Too Large 客户端请求的实体主体部分超过服务器允许范围。
  15. 414 Request URL Too Long 请求的URL长度超过服务器允许范围
  16. 415 UNsupport Media Type 不支持的实体的内容类型
  17. 416 Request Range Not Satisfiable 请求资源的范围无效
  18. 417 Expectation Failed 请求的Expect首部包含的期望服务器无法满足

  1. 500 Internal Server Error 服务器遇到一个妨碍它为请求提供服务的错误
  2. 501 Not Implement 请求超出服务器的能力范围
  3. 502 Bad Gateway 作为代理或网关使用的服务器从请求响应链的下一条链路上收到一条伪响应。
  4. 503 Service Unavailable 服务器现在无法为请求提供服务
  5. 504 Gateway Timeout 与408类似,这里的响应来自一个网关或代理
  6. 505 HTTP Version Not Support 服务器不支持的Http版本

7 <headers> 首部

首部分为5类:

7.1 通用首部

客户端和服务器端都可以使用的首部,提供了与报文相关的最基本的信息。

通用的信息性首部如下:

  1. Connection 允许客户端和服务器端指定与请求/响应连接有关的属性。
  2. Date 提供日期和时间标志,说明报文是什么时间创建的
  3. MIME-Version 给出了发送端使用的MIME版本
  4. Trailer 分块编码传输时,列出报文trailer部分的首部集合
  5. Transfer-Encoding 告诉接收端为了保证报文的可靠传输,对报文采用了什么编码
  6. Update 给出了发送端可能想要升级使用的新版本或协议
  7. Via 显示了报文经过的中间节点(网关、代理)

通用缓存性首部如下:

  1. Cache-Control 用于随报文传送缓存指令
  2. Pragma 另一种随报文传送指示的方式

7.2 请求首部

请求报文特有的,用于说明客户端发送出来的请求相关信息

  1. 请求信息性首部如下:

    首部 描述
    Client-IP 客户端的IP
    From 客户端用户的email地址
    Host 接收请求的服务器ip和port
    Referer 提供了包含当前请求URI的文档的URL
    UA-Color 客户端显示器显示颜色有关信息
    UA-CPU 客户端CPU类型或制造商
    UA-Disp 与客户端屏幕显示能力相关信息
    UA-OS 客户端操作系统名称以及版本
    UA-Pixels 客户端显示器像素信息
    User-Agent 发起请求的应用程序名称
  2. Accept首部

    Accept首部为客户端提供了一种将其喜好和能力告知服务器的能力。服务器可以根据这些信息,发送相应的信息给客户端。

    首部 描述
    Accept 告诉服务器能够发送哪些媒体类型
    Accept-Charset 告诉服务器能够发送哪些字符集
    Accept-Encoding 告诉服务器能发哪些编码方式
    Accept-Language 告诉服务器能发送哪些语言
    TE 告诉服务器可以使用哪些扩展传输编码
  3. 条件请求首部

    客户端在请求时若希望为请求加上限制,则使用以下:

    首部 描述
    Expext 允许客户端列出某请求所要求的服务器行为
    If-Match 获取与此处实体标记相匹配的资源
    If-Modified-Since 获取此处指定日期之后被修改的资源
    If-None-Match 和If-Match相反,获取与此处标记不匹配的资源
    If-Range 允许对资源的指定范围进行条件请求
    If-Unmodified-Since 与If-Modified-Since相反,获取此处指定日期之后未被修改的资源
    Range 请求资源的指定范围
  4. 安全请求首部

    HTTP本身支持简单的安全请求,可以读请求进行质询/响应认证。要求客户端在获取特定资源前,首先对自身进行认证,包括以下部分:

    首部 描述
    Authorization 客户端提供给服务器,以便其对自身进行认证的数据
    Cookie 客户端向服务器传送一个令牌
    Cookie2 用来说明请求端支持的cookie版本
  5. 代理请求首部
    首部 描述
    Max-Forward 在通往源端服务器的路径上,将请求转发给代理或网关的最大次数,与TRACE一起使用
    Proxy-Authorization 与Authotrization类似,在代理认证时使用
    Proxy-Connection 与Connection类似,用于与代理建立连接时。

7.3 响应首部

  1. 信息性首部

    首部 描述
    Age (从最初创建开始)响应持续时间
    Public 服务器为其资源支持的请求方法列表
    Retry-After 若资源不可用,在此时间重试
    Server 服务器应用程序软件版本和名称
    Title HTML文档源端给出的标题
    Warning 比原因短语中更详细的一些警告报文
  2. 协议首部
    首部 描述
    Accept-Ranges 服务器可接受的资源范围类型
    Vary 首部列表
  3. 安全响应首部
    首部 描述
    Proxy-Authenticate 来自代理的对客户端的质询列表
    Set-Cookie 客户端设置一个令牌,以便服务器对客户端进行标识
    Set-Cookie2
    WWW-Authenticate 来自服务器对客户端的咨询列表

7.4 实体首部

用于应对实体主体部分的首部

  1. 实体信息性首部

    首部 描述
    Allow 列出了对此实体执行的请求方法
    Location 告知客户端实体实际位于何处
  2. 内容首部
    首部 描述
    Content-Base 解析主体中的相对URL时使用的基础URL
    Content-Encoding 对主体执行的编码方式
    Content-Language 主体的自然语言
    Content-Length 主体的长度
    Content-Location 资源实际位置
    Content-MD5 主体的MD5校验和
    Content-Range 整个资源中此实体
    Content-Type 主体的对象类型
  3. 实体缓存首部
    首部 描述
    ETag 与此实体相关的实体标记
    Expires 实体不在有效
    Last-Modified 实体最后修改时间

7.5 扩展首部

时间: 2024-10-31 20:58:38

Http之报文的相关文章

重温Http协议--请求报文和响应报文

http协议是位于应用层的协议,我们在日常浏览网页比如在导航网站请求百度首页的时候,会先通过http协议把请求做一个类似于编码的工作,发送给百度的服务器,然后在百度服务器响应请求时把相应的内容再通过http协议做一个类似于解码的工作,这样浏览器才能理解这个数据,然后为我们展示出来百度首页. 这相当于是一种规范,网络中数据的传输在位于应用之下的各层(传输层,应用层)来完成的,在tcp/ip协议接收到数据时,我们是不能直接使用和浏览的,需要先通过一种规范来进行梳理,也就是解码,得到浏览器支持的一种格

Linux下用C实现Ping监测与HTTP报文上传

有一个数据中心监测项目,命名为CPing,它的主要原理通过WEB进行前台统一配置管理,后台定期对数据中心相关设备执行Ping操作,并将结果及时写入到数据库. 该项目基于Linux平台部署,前端开发语言采用PHP,后台开发语言采用C,由于考量到项目的部署简洁性,后台开发的守护进程尽量不直接操作数据库,而是将需要写入的数据以HTTP的形式发送给PHP的WEB页面,由PHP完成写入操作.这样的好处是后台守护进程部署时不需要配置相关数据库接入环境. 下面给出一段后台代码,作用是执行Ping操作,并将结果

使用WireShark简单分析ICMP报文

ICMP协议介绍 1.ICMP是"Internet Control Message Protocol"(Internet控制消息协议)的缩写.它是TCP/IP协议族的一个子协议,用于在IP主机.路由器之间传递控制消息.控制消息是指网络通不通.主机是否可达.路由是否可用等网络本身的消息.这些控制消息虽然并不传输用户数据,但是对于用户数据的传递起着重要的作用. 2.ICMP报文作为IP层数据报的数据,加上数据报的首部,组成数据报发送出去. 3.ICMP报文的种类有两种,即ICMP差错报告报

HTTP请求响应报文&amp;&amp;相关状态码&amp;&amp;GET_POST请求方法 总结

HTTP请求报文: 一个HTTP请求报文由四个部分组成:请求行.请求头部.空行.请求数据 1.请求行   请求行由请求方法字段.URL字段和HTTP协议版本字段3个字段组成,它们用空格分隔.比如 GET /data/info.html HTTP/1.1 方法字段就是HTTP使用的请求方法,比如常见的GET/POST 其中HTTP协议版本有两种:HTTP1.0/HTTP1.1 可以这样区别: HTTP1.0对于每个连接都的建立一次连接一次只能传送一个请求和响应,请求就会关闭,HTTP1.0没有Ho

【报文】理解HTTP协议的Request/Response(请求响应)模型

[报文]理解HTTP协议的Request/Response(请求响应)模型 系列目录 [简介]"请求/响应"模型 http://www.cnblogs.com/engraver-lxw/p/7550514.html [原理]理解HTTP协议的Request/Response(请求响应)模型 http://www.cnblogs.com/engraver-lxw/p/7550691.html [报文]理解HTTP协议的Request/Response(请求响应)模型--当前 http:/

IP包、TCP报文、UDP数据段格式的汇总

一.IP包格式 IP数据包是一种可变长分组,它由首部和数据负载两部分组成.首部长度一般为20-60字节(Byte),其中后40字节是可选的,长度不固定,前20字节格式为固定.数据负载部分的长度一般可变,整个IP数据包的最大长度为65535B. 1.版本号(Version) 长度为4位(bit),IP v4的值为0100,IP v6的值为0110. 2.首部长度 指的是IP包头长度,用4位(bit)表示,十进制值就是[0,15],一个IP包前20个字节是必有的,后40个字节根据情况可能有可能没有.

C++传智笔记(6):socket客户端发送报文接受报文的api接口

#define _CRT_SECURE_NO_WARNINGS #include "stdio.h" #include "stdlib.h" #include "string.h" #include "itcast_comm.h" #include "memwatch.h" #include "itcastlog.h" /* 下面定义了一套socket客户端发送报文接受报文的api接口

前端学HTTP之报文首部

前面的话 首部和方法配合工作,共同决定了客户端和服务器能做什么事情.在请求和响应报文中都可以用首部来提供信息,有些首部是某种报文专用的,有些首部则更通用一些.本文将详细介绍HTTP报文中的首部 结构 HTTP首部字段是构成HTTP报文的要素之一.在客户端与服务器之间以HTTP协议进行通信的过程中,无论是请求还是响应都会使用首部字段,它能起到传递额外重要信息的作用.使用首部字段是为了给浏览器和服务器提供报文主体大小.所使用的语言.认证信息等内容 HTTP首部字段是由首部字段名和字段值构成的,中间用

通用报文解析服务的演进之路(基于磁盘目录的分布式消息消费者服务)之一

通用报文解析服务,用C#开发,经历了三版更新,支撑起了关区内的绝大多数数据交换业务,截止至今,每日收发报文约20万,数据量约5G,平均延迟在1分钟内. 回想起那些半夜处理积压报文的场景,不胜唏嘘,决定把这个演进过程向大家讲述一下.回顾历史,展望未来,如果能给大家一些启发,是再好不过的了. 由于某些历史和非历史原因,我们的数据交换在已经有IBMMQ等中间件做支撑的情况下,还需要将报文落地到磁盘目录下再做下一步解析.入库.因此就有了这么一个需求,基于磁盘目录的报文解析服务. 初步计划,按照演进过程中

http协议进阶(三)补充:报文首部

一直纠结要不要把关于首部的内容放到上一篇随笔中,毕竟报文中首部内容还是很重要的,之前也介绍过,犹豫良久,觉得写一个补充吧,原谅我有点强迫症...... 之前写的关于报文首部的传送门: 报文首部:http://www.cnblogs.com/imyalost/p/5708445.html 通用首部字段:http://www.cnblogs.com/imyalost/p/5717430.html 请求首部字段:http://www.cnblogs.com/imyalost/p/5726556.htm