HTTP 报文是在 HTTP 应用程序之间发送的数据块。 报文在客户端、 服务器和代理之间流动。 术语“流入”、“流出”、“上游” 及“下游” 都是用来描述报文方向的。
我的专栏: HTTP学习笔记
报文
所有的 HTTP 报文都可以分为两类: 请求报文(request message) 和响应报文(response message)。
请求报文 | <method> <request-URL> <version> <headers> <entity-body> |
响应报文 | <version> <status> <reason-phrase> <headers> <entity-body> |
、
HTTP方法
常用的HTTP方法
GET
通常用于请求服务器发送某个资源
HEAD
服务器在响应中只返回首部
• 在不获取资源的情况下了解资源的情况(比如, 判断其类型) ;
• 通过查看响应中的状态码, 看看某个对象是否存在;
• 通过查看首部, 测试资源是否被修改了。
PUT
与 GET 从服务器读取文档相反, PUT 方法会向服务器写入文档。
PUT 允许用户对内容进行修改,一般需要密码登陆
POST
表单中填好的数据通常会被送给服务器, 然后由服务器将其发送到它要去的地方
TRACE
客户端发起一个请求时, 这个请求可能要穿过防火墙、 代理、 网关或其他一些应用程序
TRACE 方法主要用于诊断; 也就是说, 用于验证请求是否如愿穿过了请求 / 响应链。
OPTIONS
OPTIONS 方法请求 Web 服务器告知其支持的各种功能。 可以询问服务器通常支持哪些方法, 或者对某些特殊资源支持哪些方法。
DELETE
DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源
状态码
状态码分类
100~199——信息性状态码
100 | 说明收到了请求的初始部分,请客户端继续。发送了这个状态码之后,服务器在收到请求之后必须进行响应。 |
101 | 说明服务器正在根据客户端的指定,将协议切换成 Update 首部所列的协议 |
200~299——成功状态码
200 | 请求没问题,实体的主体部分包含了所请求的资源 |
201 | 用于创建服务器对象的请求(比如,PUT)。响应的实体主体部分中应该包含各种引用了已创建的资源的 URL |
202 | 请求已被接受,但服务器还未对其执行任何动作。不能保证服务器会完成这个请求;这只是意味着接受请求时,它看起来是有效的。 |
203 | 实体首部包含的信息不是来自于源端服务器,而是来自资源的一份副本。 |
204 | 响应报文中包含若干首部和一个状态行,但没有实体的主体部分。 |
205 | 另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有 HTML 表单元素 |
206 | 成功执行了一个部分或 Range(范围)请求。 |
300~399——重定向状态码
300 | 客户端请求一个实际指向多个资源的 URL 时会返回这个状态码,比如服务器上有某个 HTML 文档的英语和法语版本。 |
301 | 在请求的 URL 已被移除时使用。 |
302 | 与 301 状态码类似; |
303 | 告知客户端应该用另一个 URL 来获取资源。 |
304 | 客户端可以通过所包含的请求首部,使其请求变成有条件的。 |
305 | 用来说明必须通过一个代理来访问资源 |
306 | 当前未使用 |
307 | 与 301 状态码类似; |
400~499——客户端错误状态码
400 | 用于告知客户端它发送了一个错误的请求 |
401 | 与适当的首部一同返回,在这些首部中请求客户端在获取对资源的访问权之前,对自己进行认证。 |
402 | 现在这个状态码还未使用 |
403 | 用于说明请求被服务器拒绝了 |
404 | 用于说明服务器无法找到所请求的 URL |
405 | 发起的请求中带有所请求的 URL 不支持的方法时 |
406 | 客户端可以指定参数来说明它们愿意接收什么类型的实体。服务器没有与客户端可接受的 URL 相匹配的资源时 |
407 | 与 401 状态码类似,但用于要求对资源进行认证的代理服务器 |
408 | 客户端完成请求所花的时间太长 |
409 | 说明请求可能在资源上引发的一些冲突 |
410 | 与 404 类似,只是服务器曾经拥有过此资源。主要用于 Web 站点的维护,这样服务器的管理者就可以在资源被移除的情况下通知客户端了 |
411 | 服务器要求在请求报文中包含 Content-Length 首部时使用 |
412 | 客户端发起了条件请求,且其中一个条件失败了的时候使用 |
413 | 客户端发送的实体主体部分比服务器能够或者希望处理的要大时 |
414 | 客户端所发请求中的请求 URL 比服务器能够或者希望处理的要长时 |
415 | 服务器无法理解或无法支持客户端所发实体的内容类型时 |
416 | 请求报文所请求的是指定资源的某个范围,而此范围无效或无法满足时 |
417 | 请求的 Expect 请求首部包含了一个期望,但服务器无法满足此期望时 |
500~599——服务器错误状态码
500 | 服务器遇到一个妨碍它为请求提供服务的错误时 |
501 | 客户端发起的请求超出服务器的能力范围 |
502 | 作为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条伪响应 |
503 | 来说明服务器现在无法为请求提供服务 |
504 | 与状态码 408 类似,只是这里的响应来自一个网关或代理,它们在等待另一服务器对其请求进行响应时超时了 |
505 | 服务器收到的请求使用了它无法或不愿支持的协议版本时,使用此状态码。有些服务器应用程序会选择不支持协议的早期版本 |
首部
个人对这部分不太理解,书上定义如下:
• 通用首部
这些是客户端和服务器都可以使用的通用首部。可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能。比如,Date 首部就是一个通用首部,每一端都可以用它来说明构建报文的时间和日期:
Date: Tue 3 Oct 1974 02:16:00 GMT,
• 请求首部
从名字中就可以看出,请求首部是请求报文特有的。它们为服务器提供了一些额外信息,比如客户端希望接收什么类型的数据。例如,下面的 Accept 首部就用来告知服务器客户端会接受与其请求相符的任意媒体类型:
Accept: */*
• 响应首部
响应报文有自己的首部集,以便为客户端提供信息(比如,客户端在与哪种类型的服务器进行交互)。例如,下列 Server 首部就用来告知客户端它在与一个版本 1.0 的 Tiki-Hut 服务器进行交互:
Server: Tiki-Hut/1.0
• 实体首部
实体首部指的是用于应对实体主体部分的首部。比如,可以用实体首部来说明实体主体部分的数据类型。例如,可以通过下列 Content-Type 首部告知应用程序,数据是以 iso-latin-1 字符集表示的 HTML 文档:
Content-Type: text/html; charset=iso-latin-1
• 扩展首部
扩展首部是非标准的首部,由应用程序开发者创建,但还未添加到已批准的HTTP 规范中去。即使不知道这些扩展首部的含义,HTTP 程序也要接受它们并对其进行转发。