Fishelly Idx.

HTTP协议（二）：URL与HTTP报文

2019-10-13 16:36  |  分类：理论知识  |  标签： HTTP浏览器原理

摘要：上一篇文章我们讲了HTTP协议的一些重要概念，其中就有包括URL、资源、HTTP报文相关的内容。这一篇文章将来细讲一下这3个点。

前言

上一篇文章我们讲了HTTP协议的一些重要概念，其中就有包括URL、资源、HTTP报文相关的内容。这一篇文章将来细讲一下这3个点。

URL

URL表示的是一个资源所在的位置，是URI的子集。用户通过URL去查询子集所需要的资源，但是URL不仅仅适用于HTTP协议中，也可以用于其他的协议。只要符合其格式的都可以称为URL。

结构

URL的结构是这样：://:@:/;?#。但是几乎没有URL会完整的包含上述方案的。一般来说，仅仅只包含了3部分分别是：scheme、host、path。

组件 描述 默认值
方案 访问服务器获取资源时所使用的协议，如：http,https,ftp等 无
用户 某些方案访问资源所需的用户名 匿名
密码 一些资源访问时所需要密码，跟着用户民后面，用：隔开
主机 资源所在服务器的主机名或IP地址 无
端口 资源所在服务器正在监听的端口号，有很多协议都有自己默认的端口号，如HTTP协议是80 每个方案特有
路径 资源在服务器的名称，由/分开 无
参数 某些方案会通过其来指定输入参数，参数为名/值对，每个参数由;分隔开 无
查询 用于传递一些参数以激活应用程序，通过?与其他部分分隔开。 无
片段 一小片或一部分资源的名字。引用对象时，不会将frag传递给服务器，仅在客户端内部使用。通过’#’将其与URL其他部分分隔开。 无

URL的快捷方式

相对URL

相对URL是不完整的，要从相对URL中获取访问资源的所有信息，就必须依靠另一个基础的URL进行解析。如在写HTML文档时，可以将一些地址直接写成./的形式，如:<a href="./demo.html">demo</a>。

使用相对URL可以节省URL的方案，主机和其他一些部分。这些部分直接从一个基础的URL中解析出来，如上述的例子，假设基础URL为：http://fishelly.top/index.html，用这个URL为基础推导出，方案为：http，主机名为：fishelly.top，由于使用了./，表示在当前目录下，因此./demo.html被解析成了http://fishelly.top/demo.html

基础URL

处理相对URL的最重要一步就是确定基础URL。

  • 在资源中显示提供，也就是使用html的标签。
  • 封装资源的基础URL，如果没有显示提供，则会使用在发现相对URL的资源的URL当做基础URL。
  • 没有基础URL，意味着你有一个绝对URL，但有时可能只是一个不完整或者损坏的URL

URL编码

URL使用的US-ASCII字符集，对于一些保留及受限的字符需要进行转义，如：%、/、#、?、@等。

HTTP报文

HTTP报文是HTTP应用程序之间发送的数据块。这些数据块以文本的形式表示，描述了报文的诸多内容及含义。这些报文在客户端与服务器之间流动。报文流入服务器后，待服务器处理完成，会流回用户的Agent代理中。报文可以分两类，分别是请求报文（客户端对服务器的资源进行请求）和响应报文（服务器针对客户端的请求进行响应）。

  • 请求报文格式
  1. <method> <request-URL> <version>
  2. <headers>
  4. <entity-body>
  • 响应报文格式
  1. <version> <status> <reason-phrase>
  2. <headers>
  4. <entity-body>
  • 格式描述：
    • 方法 method：客户端希望服务器对资源执行的操作，GET,POST,HEAD等
    • 请求URL request-URL：请求所需资源的URL
    • 版本 version：报文所使用的HTTP版本
    • 状态码 status-code：描述请求执行的状态，如：成功，失败等
    • 原因短语 reason-phrase：数字状态码的刻度版本，包含行终止序列之前的所有文本
    • 首部 header：一些附加信息，用于告诉服务器或客户端，当前请求或响应的属性情况。通常是一个首部名字。后面跟着冒号（:），然后一个可选空格，以及对于的值；首部最后以CRLF结束。
    • 实体的主体部分 entity-body：包含任意数据组成的数据块

报文的起始行

用于表示请求报文要做什么，以及响应报文要发生什么。包含了：请求行（请求方法、请求URL、版本）或响应行（状态码、原因短语、版本号）。其实就是报文格式例子中的第一行<method> <request-URL> <version>、<version> <status> <reason-phrase>

首部分类

  • 通用首部：既可以出现在请求报文又可以出现在响应报文
  • 请求首部：只能出现在请求报文中，提供请求相关信息
  • 响应首部：只能出现在响应报文中，提供响应相关信息
  • 实体首部：描述实体自身内容相关的信息
  • 扩展首部：规范未定义的首部

一些常见的首部

  1. Access-Control-Allow-Origin: *
  2. Age: 2318192
  3. Cache-Control: public, max-age=315360000
  4. Connection: keep-alive
  5. Date: Mon, 18 Jul 2016 16:06:00 GMT
  6. Server: Apache
  7. Vary: Accept-Encoding
  8. Via: 1.1 3dc30c7222755f86e824b93feb8b5b8c.cloudfront.net (CloudFront)

参见：http首部

方法

方法名称 描述
GET 请求服务器发送某个资源
POST 向服务器发送数据
PUT 向服务器写入文档
DELETE 请求服务器删除文档
TRACE 在请求的过程中，会经过网关，代理，防火墙等，这些都可以更改请求。因此使用此方法可以返回请求在最终发送给服务器时，变成什么样子。
HEAD 与GET方法类似，不同在于，这里仅返回首部，不返回实体内容
OPTIONS 告知客户方服务器支持的各种功能

由于HTTP被设计成可扩展的，开发者可以针对性的扩展一些规范上没有的方法。这些就由对应的开发自行去维护与支持。

状态码

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

参见：http状态码

致谢

HTTP权威指南