读书笔记2 —— URL 和 HTTP 报文详解

URL 的语法

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

组件	描述	默认值
方案	访问服务器以获取资源时需要使用哪种协议	无
用户	某些方案访问资源时需要的用户名	匿名
密码	用户名后面可能要包含的密码，中间由冒号分隔	<E-mail 地址>
主机	资源宿主服务器的主机名或点分IP地址	无
端口	资源宿主服务器正在监听的端口号。很多方案都有默认端口号。	每个方案特有
路径	服务器上资源的本地名，由一个斜杠/将其与前面的URL组件分隔开来。路径组件的语法是与服务器和方案有关的。	无
参数	某些方案会用这个组件来指定输入参数。参数为名/值对。URL中可以包含多个参数字段，它们相互之间以及与路径的其余部分之间用分号;分隔	无
查询	某些方案会用这个组件传递参数以激活应用程序。查询组件的内容没有通用格式。用字符?将其与URL的其余部分分隔开来。
片段	一小片或一部分资源的名字。引用对象时，不会将frag字段传送给服务器；这个字段是在客户端内部使用的。通过字符#将其与URL的其余部分分隔开来。	无

报文的语法

请求报文

<method> <request-URL> <version>
<headers>

<entity-body>

POST /api/sign/register.json HTTP/1.1
Host: dev.zhiaotech.com:8005
Content-Length: 13
Accept: */*
Origin: http://dev.zhiaotech.com:8004
DNT: 1
Content-Type: application/json
Connection: keep-alive

{"name":"xx"}

响应报文

<version> <status-code> <reason-phrase>
<headers>

<entity-body>

HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Content-Type: application/json
Transfer-Encoding: chunked
Access-Control-Allow-Origin: http://dev.zhiaotech.com:8004
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, Content-Type, Cookie, Accept
Access-Control-Allow-Methods: GET, POST, PATCH, PUT, OPTIONS
Cache-Control: no-cache, private
Date: Wed, 27 Feb 2019 00:20:44 GMT
Set-Cookie: laravel_session=4Q8jPlqCd0Ex9GOa8Nujblgaun8sNs; 
expires=Wed, 27-Feb-2019 02:20:44 GMT; Max-Age=7200; path=/; httponly
Proxy-Connection: keep-alive

{"data":"","code":1001,"msg":"未登录"}

• 方法（method）

  客户端希望服务器对资源执行的动作。是一个单独的词，比如GET、HEAD、或POST等等。

• 请求URL（request-URL）

  命名了所请求资源，或者URL路径组件的完整URL。

• 版本（version）

  报文所使用的 HTTP 版本，其格式看起来是这样的：
  HTTP/<major>.<minor>
  其中major和minor都是整数

• 状态码（status-code）

  为三位数字，这三位数字描述了请求过程中所发生的情况。每个状态码的第一位数字都用于描述状态的一般类别（“成功”、“出错”等）。

• 原因短语（reason-phrase）

  数字状态码的可读版本，包含行终止序列之前的所有文本。原因短语只对人类有意义。

• 首部（header）

  可以有零个或多个首部，每个首部都包含一个名字，后面跟着一个冒号:，然后是一个可选的空格，接着是一个值，最后是一个CRLF。首部是由一个空行CRLF结束的，表示了首部列表的结束和实体主体部分的开始。有些HTTP版本，比如HTTP/1.1，要求有效的请求或相应报文中必须包含特定的首部。

• 实体的主体部分（entity-body）

  实体的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主题部分，有时，报文只是以一个CRLF结束。

起始行

请求行

包含了一个方法和一个请求URL，请求行中还包含HTTP的版本，在HTTP/1.0之前，并不要求请求行中包含HTTP版本号。

响应行

包含HTTP版本，数字状态码，以及描述操作状态的文本形式的原因短语。

方法

常用的HTTP方法有以下7种，注意，有些方法的请求报文中有主体，有的则没有。

方法	描述	是否包含主体
GET	从服务器获取一份文档	否
HEAD	只从服务器获取文档的首部	否
POST	向服务器发送需要处理的数据	是
PUT	将请求的主体部分存储在服务器上	是
TRACE	对可能经过代理服务器传送到服务器上去的报文进行追踪	否
OPTIONS	决定可以在服务器上执行哪些方法	否
DELETE	从服务器上删除一份文档	否

状态码

通过三位数字代码对不同状态码进行分类，200到299之间的状态码表示成功。300到399之间的代码表示资源已经被移走了。400到499之间的代码表示客户端的请求出错了。500到599之间的代码表示服务器出错了。

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

原因短语

原因短语和状态码是成对出现的。原因短语是状态码的可读版本，应用程序开发者将其传送给用户，用以说明在请求期间发生了什么情况。

HTTP规范并没有提供任何硬性规定，要求原因短语以何种形式出现。

首部

首部分类

HTTP规范定义了几种首部字段。应用程序也可以随意发明自己所用的首部。HTTP首部可以分为以下几类。

• 通用首部

  既可以出现在请求报文中，也可以出现在响应报文中。

• 请求首部

  提供更多有关请求的信息。

• 响应首部

  提供更多有关响应的信息。

• 实体首部

  描述主题的长度和内容，或者资源自身。

• 扩展首部

  规范中没有定义的新首部。

常见的首部实例

首部实例	描述
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

首部延续行

将长的首部行分为多行可以提高可读性，多出来的每行前面至少要有一个空格或制表符（tab）
例如：

HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
	Version 1.0

在这个例子中，Server 首部的值 Test Server Version 1.0 被划分成了多个延续行。