HTTP
HTTP(Hyper Text Transfer Protocol)
,译为超文本传输协议- 是互联网中应用最广泛的应用层协议之一
- 设计
HTTP
最初的目的是:提供一种发布和接收HTML
页面的方法,由URI
来标识具体的资源 - 后面用
HTTP
来传递的数据格式不仅仅是HTML
,应用非常广泛
HTML( Hyper Text Markup Language)
:超文本标记语言- 用以编写网页
版本
- 1991年,
HTTP/0.9
- 只支持
GET
请求方法获取文本数据(比如HTML
文档),且不支持请求头、响应头等,无法向服务器传递太多信息
- 只支持
- 1996年,
HTTP/1.0
- 支持
POST
、HEAD
等请求方法,支持请求头、响应头等,支持更多种数据类型(不再局限于文本数据) - 浏览器的每次请求都需要与服务器建立一个
TCP
连接,请求处理完成后立即断开TCP
连接
- 支持
- 1997年,
HTTP/1.1
(最经典、使用最广泛的版本)- 支持
PUT
、DELETE
等请求方法 - 采用持久连接(
Connection: keep-alive
),多个请求可以共用同一个TCP
连接
- 支持
- 2015年,HTTP/2.0
- 2018年,HTTP/3.0
标准
HTTP
的标准- 由万维网协会(
W3C)
、互联网工程任务组(IETF
)协调制定,最终发布了一系列的RFC
- 由万维网协会(
RFC
(Request For Comments
,可以译为:请求意见稿) *HTTP/1.1
最早是在1997年的RFC 2068
中记录的- 该规范在
1999
年的RFC 2616
中已作废 2014
年又由RFC 7230
系列的RFC
取代HTTP/2
标准于2015年5月
以RFC 7540
正式发表,取代HTTP/1.1
成为HTTP
的实现标准
- 该规范在
- 中国的
RFC
1996年3月
,清华大学提交的适应不同国家和地区中文编码的汉字统一传输标准被IETF
通过为RFC 1922
- 成为中国大陆第一个被认可的
RFC
文件的提交协议
报文格式
请求报文
响应报文
ABNF
ABNF(Augmented BNF)
- 是
BNF
(Backus-Naur Form,译为:巴科斯-瑙尔范式)的修改、增强版 - 在
RFC 5234
中表明:ABNF
用作internet
中通信协议的定义语言 ABNF
是最严谨的HTTP
报文格式描述形式,脱离ABNF
谈论HTTP
报文格式,往往都是片面、不严谨的
- 是
- 关于
HTTP
报文格式的定义RFC 2616 4.HTTP Message
(旧)RFC 7230 3.Message Format
(新)
整体格式
规范
requset-line
status-line
header-filed
message-body
URL的编码
URL
中一旦出现了一些特殊字符(比如中文、空格),需要进行编码- 在浏览器地址栏输入
URL
时,是采用UTF-8
进行编码
- 在浏览器地址栏输入
- 比如
- 编码前:
https://www.baidu.com/s?wd=百度
- 编码后:
https://www.baidu.com/s?wd=%E5%8D%8E%E4%B8%BA
- 编码前:
请求方法
RFC 7231, section 4: Request methods
:描述了8
种请求方法GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE
RFC 5789, section 2:Patch method
:描述了PATCH
方法GET
:常用于读取的操作,请求参数直接拼接在URL的后面(浏览器对URL
是有长度限制的)POST
:常用于添加、修改、删除的操作,请求参数可以放到请求体中(没有大小限制)HEAD
:请求得到与GET
请求相同的响应,但没有响应体- 使用场景举例:在下载一个大文件前,先获取其大小,再决定是否要下载。以此可以节约带宽资源
OPTIONS
:用于获取目的资源所支持的通信选项,比如服务器支持的请求方法OPTIONS * HTTP/1.1
PUT
:用于对已存在的资源进行整体覆盖PATCH
:用于对资源进行部分修改(资源不存在,会创建新的资源)DELETE
:用于删除指定的资源TRACE
:请求服务器回显其收到的请求信息,主要用于HTTP
请求的测试或诊断CONNECT
:可以开启一个客户端与所请求资源之间的双向沟通的通道,它可以用来创建隧道(tunnel
) * 可以用来访问采用了SSL (HTTPS)
协议的站点
头部字段
- 头部字段可以分为
4
种类型- 请求头字段
(Request Header Fields)
- 有关要获取的资源或客户端本身信息的消息头
- 响应头字段
(Response Header Fields)
- 有关响应的补充信息,比如服务器本身(名称和版本等)的消息头
- 实体头字段
(Entity Header Fields)
- 有关实体主体的更多信息,比如主体长度
(Content-Length)
或其MIME
类型
- 有关实体主体的更多信息,比如主体长度
- 通用头字段
(General Header Fields)
- 同时适用于请求和响应消息,但与消息主体无关的消息头
- 请求头字段
请求头字段
响应头字段
状态码
- 在
RFC 2616 10.Status Code Definitions
规范中定义- 状态码指示
HTTP
请求是否已成功完成
- 状态码指示
- 状态码可以分为
5
类- 信息响应:
100~199
- 成功响应:
200~299
- 重定向:
300~399
- 客户端错误:
400~499
- 服务器错误:
500~599
- 信息响应:
常见状态码
100 Continue
- 请求的初始部分已经被服务器收到,并且没有被服务器拒绝。客户端应该继续发送剩余的请求,如果请求已经完成,就忽略这个响应
- 允许客户端发送带请求体的请求前,判断服务器是否愿意接收请求(服务器通过请求头判断)
- 在某些情况下,如果服务器在不看请求体就拒绝请求时,客户端就发送请求体是不恰当的或低效的
200 OK
:请求成功302 Found
:请求的资源被暂时的移动到了由Location
头部指定的URL
上304 Not Modified
:说明无需再次传输请求的内容,也就是说可以使用缓存的内容400 Bad Request
:由于语法无效,服务器无法理解该请求401 Unauthorized
:由于缺乏目标资源要求的身份验证凭证403 Forbidden
:服务器端有能力处理该请求,但是拒绝授权访问404 Not Found
:服务器端无法找到所请求的资源405 Method Not Allowed
:服务器禁止了使用当前HTTP
方法的请求406 Not Acceptable
:服务器端无法提供与Accept-Charset
以及Accept-Language
指定的值相匹配的响应408 Request Timeout
:服务器想要将没有在使用的连接关闭- 一些服务器会在空闲连接上发送此信息,即便是在客户端没有发送任何请求的情况下
500 Internal Server Error
:所请求的服务器遇到意外的情况并阻止其执行请求501 Not Implemented
:请求的方法不被服务器支持,因此无法被处理- 服务器必须支持的方法(即不会返回这个状态码的方法)只有
GET
和HEAD
- 服务器必须支持的方法(即不会返回这个状态码的方法)只有
502 Bad Gateway
:作为网关或代理角色的服务器,从上游服务器(如tomcat
)中接收到的响应是无效的503 Service Unavailable
:服务器尚未处于可以接受请求的状态- 通常造成这种情况的原因是由于服务器停机维护或者已超载
form提交
常用属性
action
:请求的URI
method
:请求方法(GET
、POST
)enctype
:POST
请求时,请求体的编码方式application/x-www-form-urlencoded
(默认值)- 用
&
分隔参数,用=
分隔键和值,字符用URL
编码方式进行编码
- 用
multipart/form-data
- 文件上传时必须使用这种编码方式
multipart/form-data
常见问题FAQ
- 免费下载或者VIP会员专享资源能否直接商用?
- 本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。
- 提示下载完但解压或打开不了?
- 找不到素材资源介绍文章里的示例图片?
- 模板不会安装或需要功能定制以及二次开发?
发表评论
还没有评论,快来抢沙发吧!