1.3 HTTP报文
1.3.3 起始行
所有的http报文都以一个起始行作为开始。
请求报文的起始行说明了要做些什么,响应报文的起始行说明发生了什么
起始行 :
请求行<method><request-URL><version>
方法+URL+HTTP版本
响应行<version><status><reason-phrase>
HTTP版本+状态码+状态说明
其中起始行的字段由空格符分隔。
1.3.3.1 方法(method):
method:请求行以方法作为开始。方法告诉服务器要做些什么。
常用的HTTP方法:
方法 | 描述 |
---|---|
GET | 从服务器获取一份文档 |
HEAD | 只从服务器获取文档首部 |
POST | 向服务器发送需要处理的数据 |
PUT | 将请求的主体部分存储在服务器上 |
TRACE | 对可能经过代理服务器传送到服务器上去的报文进行追踪 |
OPTIONS | 决定可以在服务器上执行哪些方法 |
DELETE | 从服务器上删除一份文档 |
安全方法:GET HEAD
这意味着使用GET和HEAD请求不会在服务器产生什么结果,不会改变服务器的某些状态或者信息。
下面依次详细介绍各个方法:
-
GET
:
GET 是最常用的方法。通常用于请求服务器发送某个资源。 -
HEAD
:
HEAD方法与GET方法的行为和相似,但服务器在响应中只返回起始行和首部,不会返回实体的主体部分。这就允许客户端:- 在不获取资源的情况下(无主体)了解资源的情况(如 判断其类型)
- 通过查看响应中的状态码,看看某个对象是否存在
- 通过查看首部,测试资源是否被修改了
-
PUT
:
PUT方法向服务器写入文档。
有些发布系统允许用户创建web页面,并用PUT方法直接将其安装到web服务器上去。
PUT方法的语义就是让服务器用请求的主体部分来创建一个由所请求的URL命名的新文档,或者如果那个URL存在,就让这个主体代替它。
一般在PUT执行之前需要执行密码认证。 -
POST
:
POST方法起初用来向服务器输入数据。通常会用它来支持HTML的表单。
表单中填好的数据通常会被送给服务器,然后由服务器将其发送到它要去的地方(如某个应用程序,程序根据上传的数据在数据库中进行操作) -
TRACE
:
客户端发送的请求可能会穿过防火墙,代理,网关或者其他应用程序。每个中间节点都可能会修改原始的HTTP请求。TRACE方法允许客户端在最终将请求发送给服务器时,看看它变成了什么样子。
TRACE方法会在目的服务器发起一个环回诊断。
TRACR的请求报文不应该有主体部分,经过代理时会在Via首部增加代理的相关信息。
TRACE的响应报文的主体部分包含了响应服务器收到的请求的精确副本。 -
OPTIONS
:
OPTIONS方法请求web服务器告知其支持的各种功能。询问服务器支持哪些方法,或者对某些资源提供哪些方法。
这使得不用时访问那些资源就能判定访问各种资源的最优方式
(如: Allow: GET, POST, PUT, OPTIONS) -
DELETE
:
DELETE方法做的事情就是请服务器删除请求URL所指定的资源。
可能用于和PUT方法一样的个人web页面的删改
但是客户端应用无法保证删除操作一定会被执行,因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。(报文显示200 ok,但是服务器撤销了此次删除行为)
关于扩展方法:
HTTP被设计成字段可扩展的,这样新的特性就不会使老的软件失效了。
扩展方法是指没有在HTTP/1.1中规范定义的,开发者开发的方法。下面是一些常见的扩展:
- LOCK:允许用户锁定资源(如在编辑某个资源时将其锁定,以防别人同时对其进行修改
- MKCOL:允许用户创建资源
- COPY:便于在服务器上复制资源
- MOVE:在服务器上移动资源
在不破坏端到端行为的情况下,代理会尝试将带有未知方法的报文传递给下游服务器。否则会以501(Not Implemented)状态吗进行响应。
对于服务器来说,做好按照惯例“对所发送的内容要求严一点,对所接收的资源宽容一点”。
1.3.3.2 状态码(status):
status:服务器告诉客户端:发生了什么事情
状态码分类:
整体范围 | 已定义范围 | 分类 |
---|---|---|
100~199 | 100-101 | 信息提示 |
200~299 | 200~206 | 成功 |
300~399 | 300~305 | 重定向 |
400~499 | 400~415 | 客户端错误 |
500~599 | 500~505 | 服务端错误 |
详细描述:
100-199
——信息性状态码
状态码 | 原因短语 | 含义 |
---|---|---|
100 | Continue | 已收到请求的初始部分,请客户端继续。发送了这个状态吗之后,服务器在收到请求之后必须进行响应。 |
101 | Switching Protocols | 说明服务器正在根据客户端的指定,将协议切换成Update首部所列的协议 |
100Continue:
目的是对这样的情况进行优化:HTTP客户端有一个实体的主体部分(服务器无法处理的或者很大的主体)发给服务器,但是希望在发送之前看一下服务器是否接受这个主体。
一般的情况:客户端发送一个 Expect:100Continue
的首部,说明这样一种情况:我客户端要向服务器你发送一个(大的)实体并且愿意在发送实体之前等待100Continue响应。服务器响应一个100Continue说明愿意接受。
实际上,客户端在发送了一个Expect:100Continue首部的报文之后,超过一定时间也没收到响应,客户端会直接将实体发送出去。
在收到Expect:100Continue首部的请求报文之后服务器可以响应100或者一条错误码
200-299
——成功状态码
状态码 | 原因短语 | 含义 |
---|---|---|
200 | OK | 请求没问题,实体的主体部分包含了所请求的资源 |
201 | Created | 用于创建服务器对象的请求(如PUT),响应主体应该包括已创建资源的URL,Location首部包含的则是更具体的引用。服务器必须在发送这个状态码之前创建好对象 |
202 | Accepted | 请求已接受但服务器还没执行任何动作。不能保证服务器会完成,只是看起来是有效的。返回的主体要包含对状态的描述,或者请求完成的时间估计,或者一个指向可以获取此信息位置的指针 |
203 | Non-Authoritative Information | 响应的实体首部包含的信息不是源自源服务器,而是来自资源的一个副本。(中间节点的资源副本无法或者没有对它所发送的资源有关的元信息进行验证,就会出此案这种状况) |
204 | No Content | 包含首部和状态行,但是没有实体的主体部分(主要用于在浏览器不转为显示新文档的情况下,对其进行刷新,如刷新一个表单页面) |
205 | Reset Content | 告知浏览器清除当前页面的所有HTML表单元素 |
206 | Partial Content | 成功执行了一个部分或者Range请求(206响应中必须包含Content-Range,Date,以及Etag或者Location首部) |
300-399
——重定向状态码
重定向状态码要么告知客户端使用代替位置访问它们他们感兴趣的资源,要么就提供一个代替的响应而不是资源的内容。如果资源已经被移走,可以发送一个重定向状态码和一个可选的Location首部告诉客户端被移走,现在在哪里可以找到它。这样浏览器就可以在不打扰使用者的情况下,透明地转入新的位置了。
可以通过一些首部如If-Modified-Since,将资源与本地副本作比较,查看本地副本还是否可用。
在对重定向状态码非HEAD请求进行响应时,最好在实体中包含描述信息和指向重定向的URL链接
状态码 | 原因短语 | 含义 |
---|---|---|
300 | Multiple Choice | 客户端请求一个实际上指向多个资源的URL(如英文和中文版)。返回这个代码时会有一个选项列表。有多个版本可用时客户端需要沟通。详见内容协商部分 |
301 | Moved Permanently | 请求的URL已被移除。响应的Location首部应该包含资源现在所处URL |
302 | Found | 与301类似,不同:现在是使用给定的Location首部地址,将来的请求还是用老的URL(临时重定向) |
303 | See Other | 告知客户端应该用另一个URL来获取资源。用于POST请求提交后定位扫到GET请求的地址 |
304 | Not Modified | 客户端发起请求的资源在上次存在本地之后还没有修改过(可以直接用本地的)。带有这个状态吗的响应不应该有主体部分 |
305 | Use Proxy | 必须通过一个代理来访问资源。代理的位置由Location首部指出 |
306 | (未使用) | |
307 | Temporary Redirect | 与301类似,不同:现在是使用给定的Location首部地址,将来的请求还是用老的URL(临时重定向) |
可以看到302,303,307状态吗之间存在一些交叉。这源于HTTP/1.0和HTTP/1.1应用程序对这些状态码处理方式的不同。
1.0:
302
:临时重定向POST-GET
1.1:
302
: 临时重定向, 为1.0服务,功能和1.0的302相同,负责兼容 POST转GET需要询问用户( 但实际情况是,很多浏览器都不问问用户,直接变为get发送get请求 )(用得最多)
303
:临时重定向 POST-GET 不需要询问用户
307
:临时重定向 客户端发送POST请求返回307时,浏览器询问用户是否再次POST
浏览器对303的处理则跟原来浏览器对302的处理一样(原来浏览器并没有按照302的要求那样处理),浏览器对307的处理则跟原来302所要求的的一样。
*400-499
——客户端错误状态码
有时客户端回发送格式错误的报文,或者请求一个不存在的URL。这写都是客户端的请求错误。
下面是各种客户端的错误状态码
状态码 | 原因短语 | 含义 |
---|---|---|
400 | Bad Request | 发送了一个错误的请求 |
401 | Unauthorized | 请求客户端获取资源的访问权之前,对自己认证(权限,证明给我看) |
402 | Payment Required | 现在还未使用,但已经被保留,以备未来之用 |
403 | Forbidden | 说明请求被服务器拒绝了。可以在主体部分对原因进行描述。但这个状态是在服务器不想说明拒绝原因的时候使用的 |
404 | Not Found | 说明服务器无法找到所请求的URL |
405 | Method Not Allowed | 发起的请求中带有URL不支持的方法。应该在响应中包含Allow头部,告诉客户端所请求的资源可以使用哪些方法 |
406 | Not Acceptable | 客户端可以指定参数来说明它们愿意接受什么类型的实体。服务器没有与客户端可接受的URL相匹配的资源时,使用该代码 |
407 | Proxy Authentication | 与401类似,但用于要求对资源进行认证的代理服务器 |
408 | Request Timeout | 如果客户端完成请求所花的事件太长,服务器可以返回此代码,并关闭连接 |
409 | Conflict | 说请求可能在资源上引发一些冲突。常见于PUT,如提交的版本与一只的相冲突 |
410 | Gone | 与404类似,只是服务器曾经拥有过该资源(用于web站点的维护) |
411 | Length Required | 服务器要求请求报文包含Content-Length首部时使用 |
412 | Precondition Failed | 客户端发起条件请求(Expect首部),且切中一个条件失败的时候使用 |
413 | Request Entity Too Large | 客户端发送的实体主体部分比服务器能够或希望处理的要大时使用 |
414 | Request URL Too Long | 客户端请求的URL比服务器能够或希望处理的要长时,使用 |
415 | Unsupported Media Type | 服务器无法理解或无法支持客户端实体的内容类型 |
416 | Requested Range Not Satisfiable | 请求报文请求的是指定资源的某个部分,而此范围无效或无法满足 |
417 | Expectation Failed | 服务器无法满足客户端请求的Expect首部的期望(代理或者中间应用程序有确切证据说明源服务器会为某个请求产生一个失败的期望,就可以发送这个响应状态码) |
500-599
——服务器错误状态码
状态码 | 原因短语 | 含义 |
---|---|---|
500 | Internal Server Error | 服务器遇到了一个妨碍它为请求提供服务的错误 |
501 | Not Implemented | 客户端发起的请求超出服务器能力(比如使用了服务器不支持的方法) |
502 | Bad Gateway | 代理或者网关从上游接收到的响应无效 |
503 | Service Unavailable | 用来说明服务器现在无法为请求提供服务,但是将来可以。如果服务器知道将来资源可用的事件,可以在响应中包含一个Retry-After首部 |
504 | Gateway Timeout | 与408类似。网管或者代理在等待另一服务器对其请求进行响应时超时了 |
505 | HTTP Version Not Supported | 服务器收到了请求但是它使用了不愿或者无法支持的协议版本时,使用此状态码 |
1.3.3.3原因短语(reason-phrase):
服务器告诉客户端:发生了什么事情
原因短语与状态码成对出现,是状态码的可读版本
如HTTP/1.0 200 OK ,ok用来说明200状态码
1.3.3.4版本号(version):
服务器告诉客户端:发生了什么事情
形式:HTTP/x.y
用于告知对方自己所支持的最高HTTP协议版本