Skip to content

HTTP(S)

MIME

  • Web服务器是Web资源（Web resource）的宿主。Web资源是Web内容的源头。
  • HTTP仔细地给每种要通过Web传输的对象都打上了名为MIME类型（MIME type）的数据格式标签。最初设计MIME（Multipurpose Internet MailExtension，多用途因特网邮件扩展）是为了解决在不同的电子邮件系统之间搬移报文时存在的问题。MIME在电子邮件系统中工作得非常好，因此HTTP也采纳了它，用它来描述并标记多媒体内容
  • Web服务器会为所有HTTP对象数据附加一个MIME类型
  • MIME类型是一种文本标记，表示一种主要的对象类型和一个特定的子类型，中间由一条斜杠来分隔。

URI

服务器资源名被称为统一资源标识符（Uniform Resource Identifier, URI）

  • URI是一个通用的概念，由两个主要的子集URL和URN构成
  • URL是通过描述资源的位置来标识资源的
  • URN则是通过名字来识别资源的，与它们当前所处位置无关
  • HTTP规范将更通用的概念URI作为其资源标识符，但实际上，HTTP应用程序处理的只是URI的URL子集
  • 绝对URL中包含有访问资源所需的全部信息
  • 相对URL是不完整的。要从相对URL中获取访问资源所需的全部信息，就必须相对于另一个，被称为其基础（base）的URL进行解析

语法

<schema>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
  • 方案:
  • 规定如何访问指定资源的主要标识符，它会告诉负责解析URL的应用程序应该使用什么协议
  • 方案组件必须以一个字母符号开始，由第一个“:”符号将其与URL的其余部分分隔开来
  • 方案名是大小写无关的
  • 主机与端口:
  • 主机组件标识了因特网上能够访问资源的宿主机器,可以使用主机名或者IP地址
  • 端口组件标识了服务器正在监听的网络端口
  • 对下层使用了TCP协议的HTTP来说，默认端口号为80
  • 用户名与密码
  • 路径:
  • 路径是服务器定位资源时所需的信息
  • 每个路径段都有自己的参数（param）组件
  • 参数:
  • HTTP URL的路径组件可以分成若干路径段。每段都可以有自己的参数。
  • 查询字符串:
  • 按照常规，很多网关都希望查询字符串以一系列“名/值”对的形式出现，名值对之间用字符“&”分隔
  • 片段:
  • 服务器处理的是整个对象，因此URL片段仅由客户端使用

编码

  • 机制:通过一种“转义”表示法来表示不安全字符的，这种转义表示法包含一个百分号（%），后面跟着两个表示字符ASCII码的十六进制数
  • 保留和受限:
  • %,/,.,..,#,?,;,:
  • $,+
  • @,&,=:在某些方案的上下文中有特殊含义
  • {,},|,\,^,~,[,],':用于各种传输Agent代理
  • <,>,"
  • 0x00-0x1F,0x7F:不可打印
  • >0x7F:需要转义

报文

从Web客户端发往Web服务器的HTTP报文称为请求报文（request message）。从服务器发往客户端的报文称为响应报文（response message），此外没有其他类型的HTTP报文。

报文流

  • HTTP使用术语流入（inbound）和流出（outbound）来描述事务处理（transaction）的方向
  • HTTP报文会像河水一样流动。不管是请求报文还是响应报文，所有报文都会向下游（downstream）流动

报文的组成部分

  • 起始行(start line): 对报文进行描述
  • 首部(header):包含属性
  • 主体(body):可选,包含数据

起始行和首部就是由行分隔的ASCII文本,每行都以CRLF结束

与起始行和首部不同的是，主体中可以包含文本或二进制数据，也可以为空

报文的语法

请求报文的格式:

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

<entity-body>

响应报文的格式:

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

<entity-body>

起始行

请求报文的起始行说明了要做些什么。响应报文的起始行说明发生了什么。

首部

  • HTTP首部字段向请求和响应报文中添加了一些附加信息。本质上来说，它们只是一些名/值对的列表

  • keep-Alive首部只是请求将连接保持在活跃状态。发出keep-alive请求之后，客户端和服务器并不一定会同意进行keep-alive会话。它们可以在任意时刻关闭空闲的keep-alive连接，并可随意限制keep-alive连接所处理事务的数量。

  • 除非特别指明，否则HTTP/1.1假定所有连接都是持久的。要在事务处理结束之后将连接关闭，HTTP/1.1应用程序必须向报文中显式地添加一个Connection:close首部。

方法

  • HEAD方法与GET方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。
  • PUT方法的语义就是让服务器用请求的主体部分来创建一个由所请求的URL命名的新文档，或者，如果那个URL已经存在的话，就用这个主体来替代它
  • POST方法起初是用来向服务器输入数据的[插图]。实际上，通常会用它来支持HTML的表单
  • TRACE方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子,主要用于诊断
  • OPTIONS方法请求Web服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法
  • DELETE方法所做的事情就是请服务器删除请求URL所指定的资源。但是，客户端应用程序无法保证删除操作一定会被执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求
  • HTTP被设计成字段可扩展的，这样新的特性就不会使老的软件失效了。扩展方法指的就是没有在HTTP/1.1规范中定义的方法。服务器会为它所管理的资源实现一些HTTP服务，这些方法为开发者提供了一种扩展这些HTTP服务能力的手段

状态码

  • 100~199 -> 信息性状态码
  • 200~288 -> 成功状态码
  • 300~399 -> 重定向状态码
  • 400~499 -> 客户端错误状态码
  • 500~599 -> 服务器错误状态码

HTTP 3

参考链接：