HTTP权威指南笔记
文章目录
HTTP权威指南
HTTP概述
资源
媒体类型
互联网上有数千种不同的数据类型,HTTP仔细地给各种要通过Web传输的对象都打上了名为MIME类型的数据格式标签。最初设计MIME是为了解决在不同的电子邮件系统之间搬移报文时存在的问题。MIME在电子邮件系统中工作得非常好,因此HTTP也采纳了它,用它来描述并标记多媒体内容。
Web服务器会为所有HTTP对象数据附加一个MIME类型。当WEB浏览器从服务器中取回一个对象时,会去查看相关的MIME类型,看看它是否知道应该如何处理这个对象。
MIME类型是一种文本标记,表示一种主要的对象类型和一个特定的子类型,中间由一条斜杠来分隔。
- HTML格式的文本文档由text/html类型来标记
- 普通的ASCII文本文档由text/plain类型来标记
- JPEG版本的图片为image/jpeg类型
- GIF格式的图片为image/gif类型
- Apple的QuickTime电影为video/quicktime类型
- 微软的PowerPoint文件为application/vnd.ms-powerpoint类型
常见的MIME类型有数百个,实验性或用途有限的MIME类型则更多。
URI
每个WEB服务器资源都有一个名字,这样客户端就可以说明它们感兴趣的资源是什么了。服务器资源名被称为统一资源标识符(Uniform Resource Identifier,URI)。URI就像因特网上的邮政地址一样,在世界范围内唯一标识并定位信息资源。
通常意义上的网址就是URI:
|
|
URI有两种形式(资源标识符类型),分别称为URL和URN。
URL
统一资源定位符(URL)是资源标识符(URI)最常见的形式。URL描述了一台特定服务器上某资源的特定位置。它们可以明确说明如何从一个精确、固定的位置获取资源。
大部分URL都遵循一种标准格式,这种格式包含三个部分。
- URL的第一部分被称为方案(scheme),说明了访问资源所使用的协议类型。这部分协议通常就是HTTP协议。
- 第二部分给出了服务器的因特网地址(比如,www.joes-hardware.com)。
- 其余部分指定了Web服务器上的某个资源(比如,/specials/saw-blade.gif)。
现在,几乎所有的URI都是URL。
URN
URI的第二种形式就是统一资源名(URN)。URN是作为特定内容的唯一名称使用的,与目前的资源所在地无关。使用这些与位置无关的URN,就可以将资源四处搬移。通过URN,还可以用同一个名字通过多种网络访问协议来访问资源。
比如,不论因特网标准文档RFC 2141位于何处(甚至可以将其复制到多个地方),都可以用下列URN来命名它:
|
|
URN仍然处于试验阶段,还未大范围使用。为了更有效地工作,URN需要一个支撑架构来解析资源的位置。而此类架构的缺乏也延缓了其被采用的进度。但URN确实为未来发展做出了一些令人兴奋的承诺。
事务
一个HTTP事务由一条(从客户端发往服务器的)请求命令和一个(从服务器发回客户端的)响应结果组成。这种通信是通过名为HTTP报文的格式化数据块进行的。
方法
HTTP支持几种不同的请求命令,这些命令被称为HTTP方法(HTTP method)。每条HTTP请求报文都包含一个方法。这个方法会告诉服务器要执行什么动作。
HTTP方法 | 描述 |
---|---|
GET | 从服务器向客户端发送命名资源 |
PUT | 将来自客户端的数据存储到一个命名的服务器资源中去 |
DELETE | 从服务器中删除命名资源 |
POST | 将客户端数据发送到一个服务器网关应用程序 |
HEAD | 仅发送命名资源响应中的HTTP首部 |
状态码
每条HTTP响应报文返回时都会携带一个状态码。状态码是一个三位数字的代码,告知客户端请求是否成功,或者是否需要采取其他动作。
HTTP状态码 | 描述 |
---|---|
200 | OK。文档正确返回 |
302 | Redirect(重定向)。到其他地方去获取资源 |
404 | Not Found(没找到)。无法找到这个资源 |
伴随着每个数字状态码,HTTP还会发送一条解释性的“原因短语”文本。包含文本短语主要是为了进行描述,所有的处理过程使用的都是数字码。
例子:
|
|
Web页面中可以包含多个对象
应用程序完成一项任务时通常会发布多个HTTP事务。比如,Web浏览器会发布一系列HTTP事务来获取并显示一个包含了丰富图片的Web页面。浏览器会执行一个事务来获取描述页面布局的HTML“框架”,然后发布另外的HTTP事务来获取每个嵌入式图片、图像面板、Java小程序等。
报文
HTTP报文是由一行一行的简单字符串组成的。HTTP报文都是纯文本,不是二进制代码,所以人们可以很方便地对其进行读写。
从Web客户端发往Web服务器的HTTP报文称为请求报文。从服务器发往客户端的报文称为响应报文,此外没有其他类型的HTTP报文。HTTP请求和响应报文的格式很类似。
HTTP报文包括以下三个部分。
-
起始行
报文的第一行就是起始行,在请求报文中用来说明要做些什么,在响应报文中说明出现了什么情况。
-
首部字段
起始行后面有零个或多个首部字段。每个首部字段都包含一个名字和一个值,为了便于解析,两者之间用冒号(:)来分隔。首部以一个空行结束。添加一个首部字段和添加新行一样简单。
-
主体
空行之后就是可选的报文主体了,其中包含了所有类型的数据。请求主体中包括了要发送给Web服务器的数据;响应主体中装载了要返回给客户端的数据。起始行和首部都是文本形式且都是结构化的,而主体则不同,主体中可以包含任意的二进制数据(比如图片、视频、软件等)。当然,主体中也可以包含文本。
响应首部中的Content-Length说明了响应主体的长度,Content-Type说明了文档的MIME类型。
连接
TCP/IP
HTTP是个应用层协议。HTTP无需操心网络通信的具体细节;它把联网的细节都交给了通用、可靠的因特网传输协议TCP/IP。
TCP提供了:
- 无差错的数据传输
- 按序传输(数据总是按照发送的顺序到达)
- 未分段的数据流(可以在任意时刻以任意尺寸将数据发送出去)
用网络术语来说,HTTP协议位于TCP的上层。HTTP使用TCP来传输其报文数据。与之类似,TCP则位于IP的上层。
HTTP | 应用层 |
---|---|
TCP | 传输层 |
IP | 网络层 |
网络特有的链路接口 | 数据链路层 |
物理网络硬件 | 物理层 |
连接、IP地址及端口号
在HTTP客户端向服务器发送报文之前,需要用网际协议(Internet Protocol,IP)地址和端口号在客户端和服务器之间建立一条TCP/IP连接。
在TCP中,需要知道服务器的IP地址,以及与服务器上运行的特定软件相关的TCP端口号。
HTTP的URL中没有端口号时,可以假设默认端口号是80。URL可以使用数字形式的IP地址,也可以使用文本形式的域名。域名是IP地址比较人性化的别称。可以通过一种称为域名服务(Domain Name Service,DNS)的机制方便地将主机名转换为IP地址。
使用TELNET实例
Telnet程序可以将键盘连接到某个目标TCP端口,并将此TCP端口的输出回送到显示屏上。Telnet常用于远程终端会话,但它几乎可以连接所有的TCP服务器,包括HTTP服务器。
可以通过Telnet程序直接与Web服务器进行对话。通过Telnet可以打开一条到某台机器上某个端口的TCP连接,然后直接向那个端口输入一些字符。Web服务器会将Telnet程序作为一个Web客户端来处理,所有回送给TCP连接的数据都会显示在屏幕上。
一个使用Telnet的HTTP事务:
|
|
随后,服务器会以一个响应行、几个响应首部、一个空行和最后面的HTML文档主体来应答。
对Telnet做脚本自动化是很繁琐的。如果想要更灵活的工具,可以使用netcat。通过netcat可以很方便地操纵基于UDP和TCP的流量(包括HTTP)。还可以为其编写脚本。
协议版本
现在使用的HTTP协议有几个版本。HTTP应用程序要尽量强健地处理各种不同的HTTP协议变体。目前仍在使用的版本如下:
-
HTTP/0.9
这个协议有很多严重的设计缺陷,只应该用于与老客户端的交互。只支持GET方法,不支持多媒体内容的MIME类型、各种HTTP首部,或者版本号。
-
HTTP/1.0
第一个得到广泛使用的HTTP版本。添加了版本号、各种HTTP首部、一些额外的方法,以及对多媒体对象的处理。HTTP/1.0使得包含生动图片的Web页面和交互式表格成为可能。
-
HTTP/1.0+
持久的keep-alive连接、虚拟主机支持,以及代理连接支持都被加入到HTTP之中,并成为非官方的事实标准。这种非正式的HTTP扩展版本通常称为HTTP/1.0+
-
HTTP/1.1
重点关注的是校正HTTP设计中的结构性缺陷,明确语义,引入重要的性能优化措施,并删除一些不好的特性。HTTP/1.1是当前使用的HTTP版本
-
HTTP-NG(又名HTTP/2.0)
HTTP/1.1后续结构的原型建议,重点关注性能的大幅优化,以及更强大的服务逻辑远程执行框架。
Web的结构组件
之前介绍了两个Web应用程序(Web浏览器和Web服务器)。还有其他一些比较重要的应用程序,如下所示:
-
代理
位于客户端和服务器之间的HTTP中间实体
-
缓存
HTTP的仓库,使常用页面的副本可以保存在离客户端更近的地方
-
网关
连接其他应用程序特殊Web服务器
-
隧道
对HTTP通信报文进行盲转发的特殊代理
-
Agent代理
发起自动HTTP请求的半智能Web客户端
代理
HTTP代理服务器是Web安全、应用集成以及性能优化的重要组成模块。
代理位于客户端和服务器之间,接收所有客户端的HTTP请求,并将这些请求转发给服务器(可能会对请求进行修改之后转发)。
出于安全考虑,通常会将代理作为转发所有web流量的可信任中间节点使用。代理还可以对请求和响应进行过滤。
缓存
Web缓存或代理缓存是一种特殊的HTTP代理服务器,可以将经过代理传送的常用文档复制保存起来。下一个请求同一文档的客户端就可以享受缓存的私有副本所提供的服务了。
HTTP定义了很多功能,使得缓存更加高效,并规范了文档的新鲜度和缓存内容的隐私性。
网关
网关是一种特殊的服务器,作为其他服务器的中间实体使用。通常用于将HTTP流量转换成其他的协议。网关接受请求时就好像自己是资源的源端服务器一样。客户端可能并不知道自己正在与一个网关进行通信。
例如,一个HTTP/FTP网关会通过HTTP请求接收对FTP URI的请求,但通过FTP协议来获取文档。得到的文档会被封装成一条HTTP报文,发送给客户端。
隧道
隧道是建立起来之后,就会在两条连接之间对原始数据进行盲转发的HTTP应用程序。HTTP隧道通常用在一条或多条HTTP连接上转发非HTTP数据,转发时不会窥探数据。
HTTP隧道的一种常见用途是通过HTTP连接承载加密的安全套接字层(SSL)流量,这样SSL流量就可以穿过只允许Web流量通过的防火墙了。HTTP/SSL隧道受到一条HTTP请求,要求建立一条到目的地址和端口的输出连接,然后在HTTP信道上通过隧道传输加密的SSL流量,这样就可以将其盲转发到目的服务器上去了。
Agent代理
用户Agent代理是代表用户发起HTTP请求的客户端程序。所有发布Web请求的应用程序都是HTTP Agent代理。到目前为止,只提到过一种HTTP Agent代理:Web浏览器,但用户Agent代理还有很多其他类型。
URL与资源
浏览互联网资源
URL是浏览器寻找信息时所需的资源位置。通过URL,才能找到、使用并共享因特网上大量的数据资源。URL是人们对HTTP和其他协议的常用访问点:一个人将浏览器指向一个URL,浏览器就会在幕后发送适当的协议报文来获取人们所需要的资源。
URI是一类更通用的资源标识符,URL实际上是它的一个子集。URI是一个通用的概念,由两个主要的子集URL和URN构成,URL是通过描述资源的位置来标识资源的,而URN则是通过名字来识别资源的,与它们当前所处位置无关。
URL提供一种统一的资源命名方式。大多数URL都有同样的:“方案://服务器位置/路径”结构。
URL的语法
URL提供了一种定位互联网上任意资源的手段,但这些资源是可以通过各种不同的方案(比如HTTP、FTP、SMTP)来访问的,因此URL语法会随方案的不同而有所不同。
大部分URL都遵循通用的URL语法,而且不同URL方案的风格和语法都有不少重叠。大多数URL方案的URL语法都建立在这个由9部分构成的通用格式上:
|
|
几乎没有哪个URL中包含了所有这些组件。URL最重要的3个部分是方案(scheme)、主机(host)和路径(path)。
组件 | 描述 | 默认值 |
---|---|---|
方案 | 访问服务器以获取 | 无 |
用户 | 某些方案访问资源时需要的用户名 | 匿名 |
密码 | 用户名后面可能要包含的密码,中间由冒号(:)分隔 | <E-mail地址> |
主机 | 资源宿主服务器的主机名或点分IP地址 | 无 |
端口 | 资源宿主服务器正在监听的端口号。很多方案都有默认端口号 | 每个方案特有 |
路径 | 服务器上资源的本地名,由一个斜杠(/)将其与后面的URL组件分隔开来,路径组件的语法和方案有关 | 无 |
参数 | 某些方案会用这个组件来指定输入参数,参数为key/value对。可以包含多个参数字段,相互之间以及与路径的其余部分之间用分号分隔 | 无 |
查询 | 某些方案会用这个组件传递参数以激活应用程序。查询组件的内容没有通用格式。用字符"?“将其与URL的其余部分分隔开来 | 无 |
片段 | 一小片或一部分资源的名字。引用对象时,不会将frag字段传送到服务器,只在客户端内部使用 | 无 |
方案——使用什么协议
方案实际上是规定如何访问指定资源的主要标识符,它会告诉负责解析URL的应用程序应该使用什么协议。简单的HTTP URL中所使用的方案就是HTTP。
主机与端口
主机组件标识了因特网上能够访问资源的宿主机器。可以用主机名或者IP地址来表示主机名。
端口组件标识了服务器正在监听的网络端口。对下层使用了TCP协议的HTTP来说,默认端口号是80。
用户名和密码
很多服务器都要求输入用户名和密码才会允许用户访问数据。FTP服务器就是这样一个常见的实例。例如:
|
|
指定了用户名(anonymous)和密码(my_passwd),两者之间由字符“:”分隔。
路径
URL的路径组件说明了资源位于服务器的什么地方。路径通常很像一个分级的文件系统路径。比如:
|
|
这个URL中的路径为/seasonal/index-fall.html。
参数
为了向应用程序提供它们所需的输入参数,以便正确地与服务器进行交互,URL中有一个参数组件。这个组件就是URL中的key-value对列表,***由字符“;”将其与URL的其余部分(以及各key-value对)分隔开来。***它们为应用程序提供了访问资源所需的所有附加信息。比如:
|
|
在这个例子中,有一个参数type=d,参数名为type,值为4。
查询字符串
很多资源,比如数据库服务,都是可以通过提问题或进行查询来缩小所请求资源类型范围的。
例如:
|
|
这个URL的大部分与之前的其他URL类似。***只有问号(?)右边的内容是新出现的。***这部分被称为查询组件。查询组件的多个key-value对之间以”&“分隔。
片段
有些资源类型,比如HTML,除了资源级之外,还可以做进一步的划分。比如,对一个带有章节的大型文本文档来说,资源的URL会指向整个文本文档,但理想的情况是,能够指向资源中的那些章节。
为了引用部分资源或资源的一个片段,URL支持使用片段(frag)组件来表示一个资源内部的片段。比如,URL可以指向HTML文档中一个特定的图片或小节。
片段挂在URL的右手边,最前边有一个字符“#”。比如:
|
|
片段drills引用了/tools.html中的一个部分。这部分的名字叫作drills。
服务器处理的是整个对象,而不是对象的片段。浏览器从服务器获得了整个资源以后,会根据片段来显式感兴趣的那部分资源。
URL快捷方式
相对URL
URL有两种方式:绝对URL和相对URL。
绝对URL:指出URL所需要的所有信息。
相对URL:指出URL所需要的资源信息,包括方案、域名、端口等路径组件由自动补全获得。
各种令人头疼的字符
URL是可移植的。它要统一地命名因特网上所有的资源,这也就意味着要通过各种不同的协议来传送这些资源。这些协议在传输数据时都会使用不同的机制,所以,设计URL,使其可通过任意因特网协议安全地传输是很重要的。
安全传输意味着URL的传输不能丢失信息。有些协议,比如传输电子邮件的简单邮件传输协议,所使用的传输方法就会剥去一些特定的字符。为了避开这些问题,URL只能使用一些相对较小的、通用的安全字母表中的字符。
除此之外,设计者们还希望URL是可读的。因此,即使不可见、不可打印的字符能穿过邮件程序,从而成为可移植的,也不能在URL中使用。
URL还得是完整的,有时人们可能会希望URL中包含除通用的安全字母表之外的二进制数据或字符。因此,需要有一种转义机制,将不安全的字符编码为安全字符,再进行传输。
各种方案
方案 | 描述 |
---|---|
http | 超文本传输协议方案,除了没有用户名、密码之外,与通用的URL格式相符。默认端口80 |
https | https和http是一对。唯一的区别在于https使用了SSL,SSL为HTTP连接提供了端到端的加密机制。默认端口443 |
mailto | Mailto URL指向的是Email地址。 |
ftp | 文件传输协议URL可以用来从FTP服务器上下载或向其上传文件。 |
rtsp、rtspu | RTSP URL是可以通过实时流传输协议解析的音/视频媒体资源的标识符,rtspu中的u表示它是使用UDP来获取资源的 |
file | 表示一台指定主机上可直接访问的文件 |
news | 访问一些特定的文章或新闻组 |
telnet | 用于访问交互式业务。表示的不是对象本身,而是可通过telnet协议访问的交互式应用程序 |
URL报文
如果说HTTP是互联网的信使,那么HTTP报文就是它用来搬东西的包裹了。
报文流
HTTP报文是在HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的元信息(meta-information)开头,这些信息描述了报文的内容及含义。后面跟着可选的数据部分。这些报文在客户端、服务器和代理之间流动。术语“流入”、“流出”、“上游”及“下游”都是用来描述报文方向的。
报文的组成部分
HTTP报文是简单的格式化数据块。每条报文都包含一条来自客户端的请求,或者一条来自服务器的响应。它们由三个部分组成:对报文进行描述的起始行(start line)、包含属性的首部(header)块,以及可选的、包含数据的主体(body)部分。
起始行 | HTTP/1.0 200 OK |
---|---|
首部 | Content-type: text/plain |
Content-length: 19 | |
主体 | Hi! I am a message! |
报文的主体是一个可选的数据块。与起始行和首部不同的是,主体中可以包含文本或二进制数据,也可以为空。
首部中的Content-type说明了主体类型, Content-length则说明了主体有多少字节。
报文的语法
所有的HTTP报文都可以分为两类:请求报文和响应报文。请求报文会向Web服务器请求一个动作。响应报文会将请求的结果返回给客户端。请求和响应报文的基本报文结构相同。
请求报文的格式:
|
|
响应报文的格式:
|
|
各部分简要描述:
-
方法(method)
客户端希望服务器对资源执行的动作。是一个单独的词,比如GET、HEAD或POST。
-
请求URL(request-URL)
命名了所请求资源,或者URL路径组件的完整URL。
-
版本(version)
报文所使用的HTTP版本,格式:
1
HTTP/<major>.<minor>
主要版本号major和次要版本号minor都是整数。
-
状态码(status-code)
这三位数字描述了请求过程中所发生的情况。每个状态码的第一位数字都用于描述状态的一般类别(“成功”、“出错”等)。
-
原因短语(reason-phrase)
数字状态码的可读版本。比如HTTP/1.0 200 OK
-
首部(header)
可以有零个或多个首部。,每个首部都包含一个名字,后面跟着一个冒号(:),然后是一个可选的空格,接着是一个值,最后是一个CRLF。首部是由一个空行(CRLF)结束的,表示了首部列表的结束和实体主体部分的开始。
-
实体的主体部分(entity-body)
实体的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主体部分,有时,报文只是以一个CRLF结束。
起始行
所有的HTTP报文都以一个起始行作为开始。请求报文的起始行说明了要做些什么,响应报文的起始行说明发生了什么。
请求行
请求报文请求服务器对资源进行一些操作。请求报文的起始行,或称为请求行,包含了一个方法和一个请求URL,这个方法描述了服务器应该执行的操作,请求URL描述了要对哪个资源执行这个方法。请求行中还包含HTTP的版本,用来告知服务器,客户端使用的是哪种HTTP。
所有这些字段都由空格符分隔。在HTTP/1.0之前,并不要求请求行中包含HTTP版本号。
响应行
响应报文承载了状态信息和操作产生的结果数据,将其返回给客户端。响应报文的起始行,或称为响应行,包含了响应报文使用的HTTP版本、数字状态码,以及描述操作状态的文本形式的原因短语。
所有这些字段都由空格符分隔。在HTTP/1.0之前,并不要求响应行中包含HTTP版本号。
方法
请求的起始行以方法作为开始,方法用来告知服务器要做些什么。
方法 | 描述 | 是否包含主体 |
---|---|---|
GET | 从服务器获取一份文档 | 否 |
HEAD | 只从服务器获取文档的首部 | 否 |
POST | 向服务器发送需要处理的数据 | 是 |
PUT | 将请求的主体部分存储在服务器上 | 是 |
TRACE | 对可能经过代理服务器传送到服务器上去的报文进行追踪 | 否 |
OPTIONS | 决定可以在服务器上执行哪些方法 | 否 |
DELETE | 从服务器上删除一份文档 | 否 |
状态码
状态码用来告诉客户端,发生了什么事情。状态码位于响应的起始行中。
整体范围 | 已定义范围 | 分类 |
---|---|---|
100-199 | 100-101 | 信息提示 |
200-299 | 200-206 | 成功 |
300-399 | 300-305 | 重定向 |
400-499 | 400-415 | 客户端错误 |
500-599 | 500-505 | 服务器错误 |
当前的HTTP版本只为每类定义了几个代码。随着协议的发展,HTTP规范中会正式的定义更多的状态码。如果收到了不认识的状态码,可以根据其所处范围,将它作为那个类别中一个普通的成员来处理。
状态码 | 原因短语 | 含义 |
---|---|---|
200 | OK | 成功。请求的所有数据都在响应主体中 |
401 | Unauthorized(未授权) | 需要输入用户名和密码 |
404 | Not Found(未找到) | 服务器无法找到所请求URL对应的资源 |
原因短语
原因短语是响应起始行中的最后一个组件。为状态码提供了文本形式的解释。原因短语和状态码成对出现。
版本号
使用版本号的目的是为了互相了解对方的能力和报文格式。
首部
HTTP首部字段向请求和响应报文中添加了一些附加信息。本质上说,它们只是一些key-value对的列表。比如,下面的首部行会向Content-Length首部字段赋值19:
|
|
首部分类
HTTP规范定义了几种首部字段。应用程序也可以随意发明自己所用的首部。HTTP首部可以分为以下几类。
-
通用首部
既可以出现在请求报文中,也可以出现在响应报文中。
-
请求首部
提供更多有关请求的信息。
-
响应首部
提供更多有关响应的信息。
-
实体首部
描述主体的长度和内容,或者资源自身。
-
扩展首部
规范中没有定义的新首部。
每个HTTP首部都有一种简单的语法:名字后面跟着冒号(:),然后跟上可选的空格,再跟上字段值,最后是一个CRLF。
首部实例 | 描述 |
---|---|
Date: Tue,3Oct 1997 02:16:03 GMT | 服务器产生响应的日期 |
Content-length:15040 | 实体的主体部分包含了15040字节的数据 |
Content-type: image/gif | 实体的主体部分是一个GIF图片 |
Accept: image/gif, image/jpeg,text/html | 客户端可以接收GIF图片和JPEG图片以及HTML |
首部延续行
将长的首部行分为多行可以提高可读性,多出来的每行前面至少要有一个空格或制表符。
实体的主体部分
HTTP报文的第三部分是可选的实体主体部分。实体的主体是HTTP报文的负荷。就是HTTP要传输的内容。
方法
安全方法
HTTP定义了一组被称为安全方法的方法。GET方法和HEAD方法都被认为是安全的,这就意味着使用GET方法或HEAD方法的HTTP请求都不会产生什么动作。
安全方法不一定什么动作都不执行。使用安全方法的目的就是允许HTTP应用程序开发者通知用户,什么时候会使用某个可能引发某些动作的不安全方法。
GET
GET是最常用的方法。通常用于请求服务器发送某个资源。HTTP/1.1要求服务器实现此方法。
请求报文
|
|
响应报文
|
|
HEAD
HEAD方法与GET方法的行为很类似,但服务器在响应中只返回首部。不返回实体的主体部分。这就允许客户端在未获取实际资源的情况下,对资源的首部进行检查。使用HEAD,可以:
- 在不获取资源的情况下了解资源的情况(比如,判断其类型);
- 通过查看响应中的状态码,看看某个对象是否存在;
- 通过查看首部,测试资源是否被修改了;
服务器开发者必须确保返回的首部与GET请求所返回的首部完全相同。遵循HTTP/1.1规范,就必须实现HEAD方法。
请求报文
|
|
响应报文:
|
|
PUT
文章作者 punklu
上次更新 2020-11-09