2. 架构
HTTP 是为万维网 (World Wide Web, WWW) 架构而创造的, 并随时间演进, 以支撑一个全球性超文本系统的可伸缩性需求. 该架构的很大一部分体现在用于定义 HTTP 的术语和语法产生式中.
2.1. 客户端/服务器消息传递
HTTP 是一种无状态的请求/响应协议, 其运作方式是在一条可靠的传输层或会话层 "连接" (第 6 节) 上交换消息 (第 3 节). HTTP "客户端" 是指为发送一个或多个 HTTP 请求而建立到服务器连接的程序. HTTP "服务器" 是指通过发送 HTTP 响应来接受连接、以便受理 HTTP 请求的程序.
"客户端" 和 "服务器" 这两个术语仅指这些程序在某条特定连接上所扮演的角色. 同一个程序在某些连接上可能充当客户端, 在另一些连接上则充当服务器. "用户代理" (user agent) 一词指发起请求的各种客户端程序, 包括 (但不限于) 浏览器、蜘蛛 (基于 Web 的机器人)、命令行工具、定制应用程序和移动应用. "源服务器" (origin server) 一词指能够为给定目标资源生成权威响应的程序. "发送方" (sender) 和 "接收方" (recipient) 分别指发送或接收给定消息的任何实现.
HTTP 依赖统一资源标识符 (Uniform Resource Identifier, URI) 标准 [RFC3986] 来指明目标资源 (第 5.1 节) 以及资源之间的关系. 消息的传递格式与 Internet 邮件 [RFC5322] 以及多用途 Internet 邮件扩展 (Multipurpose Internet Mail Extensions, MIME) [RFC2045] 所用的格式类似 (HTTP 消息与 MIME 消息的差异见 [RFC7231] 附录 A).
多数 HTTP 通信由一次获取请求 (GET) 构成, 用于获取由 URI 标识的某个资源的表示. 在最简单的情况下, 这可以通过用户代理 (UA) 与源服务器 (O) 之间的一条双向连接 (===) 来完成.
request >
UA ======================================= O
< response
客户端以请求消息的形式向服务器发送 HTTP 请求: 该消息以请求行开头, 其中包含方法、URI 和协议版本 (第 3.1.1 节); 随后是若干头部字段, 其中包含请求修饰符、客户端信息和表示元数据 (第 3.2 节); 再接下来是一个表示头部部分结束的空行; 最后是包含载荷主体 (payload body) 的消息主体 (如果有的话, 第 3.3 节).
服务器通过发送一个或多个 HTTP 响应消息来响应客户端的请求: 每个响应消息以状态行开头, 其中包含协议版本、成功或错误码以及文本形式的原因短语 (第 3.1.2 节); 其后可能跟有若干头部字段, 其中包含服务器信息、资源元数据和表示元数据 (第 3.2 节); 再接下来是一个表示头部部分结束的空行; 最后是包含载荷主体的消息主体 (如果有的话, 第 3.3 节).
一条连接可用于多次请求/响应交换, 如第 6.3 节所定义.
下面的示例展示了对 URI "http://www.example.com/hello.txt" 发起 GET 请求 ([RFC7231] 第 4.3.1 节) 时一次典型的消息交换:
客户端请求:
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
服务器响应:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
Hello World! My payload includes a trailing CRLF.
2.2. 实现多样性
在考虑 HTTP 的设计时, 很容易陷入这样一种思维陷阱: 认为所有用户代理都是通用浏览器, 所有源服务器都是大型公共网站. 实际情况并非如此. 常见的 HTTP 用户代理包括家用电器、音响、体重秤、固件更新脚本、命令行程序、移动应用以及形形色色的通信设备. 同样, 常见的 HTTP 源服务器包括家庭自动化单元、可配置的网络组件、办公设备、自主机器人、新闻推送、交通摄像头、广告选择器和视频分发平台.
"用户代理" 一词并不暗示在请求发生时有人类用户正直接与该软件代理交互. 在很多情况下, 用户代理被安装或配置为在后台运行, 并把结果留存下来供稍后检查 (或者只保留其中可能有趣或出错的那一部分结果). 例如, 蜘蛛通常被赋予一个起始 URI, 并被配置为在把 Web 当作超文本图进行爬取时遵循某些行为.
HTTP 的实现多样性意味着并非所有用户代理都能向其用户提出交互式建议, 或者针对安全或隐私方面的顾虑提供充分的警告. 在本规范要求向用户报告错误的少数场合, 这种报告只在错误控制台或日志文件中可见也是可以接受的. 同样, 对于 "自动化动作在继续之前必须经用户确认" 这类要求, 可以通过预先配置选项、运行时选项, 或者直接回避不安全动作来满足; 如果用户已经做出了该选择, 那么 "确认" 并不暗示任何特定的用户界面或对正常处理的中断.
2.3. 中间方
HTTP 允许使用中间方 (intermediary), 通过一条连接链来满足请求. 常见的 HTTP 中间方有三种形式: 代理 (proxy)、网关 (gateway) 和隧道 (tunnel). 在某些情况下, 单个中间方可能依据每个请求的性质来切换行为, 分别充当源服务器、代理、网关或隧道.
> > > >
UA =========== A =========== B =========== C =========== O
< < < <
上图展示了用户代理与源服务器之间的三个中间方 (A、B 和 C). 一个走完整条链的请求或响应消息将经过四条独立的连接. 某些 HTTP 通信选项可能只适用于与最近的、非隧道邻居之间的连接, 只适用于链的两端, 或者适用于链上的所有连接. 尽管该示意图是线性的, 但每个参与者都可能同时参与多路通信. 例如, B 在处理 A 的请求的同时, 可能正在接收来自 A 之外的许多客户端的请求, 并且/或者正在把请求转发给 C 之外的服务器. 同样, 后续请求可能沿另一条连接路径发送, 这通常基于用于负载均衡的动态配置.
"上游" (upstream) 和 "下游" (downstream) 这两个术语用于描述与消息流向相关的方向性要求: 所有消息都从上游流向下游. "入站" (inbound) 和 "出站" (outbound) 这两个术语用于描述与请求路由相关的方向性要求: "入站" 指朝向源服务器, "出站" 指朝向用户代理.
"代理" 是一种消息转发代理 (message-forwarding agent), 它由客户端 (通常通过本地配置规则) 选定, 用于接收针对某类绝对 URI 的请求, 并尝试通过 HTTP 接口进行转换来满足这些请求. 有些转换是极简的, 例如针对 "http" URI 的代理请求; 而另一些请求可能需要与完全不同应用层协议之间进行双向转换. 代理常用于把某个组织的 HTTP 请求汇聚到一个公共中间方, 以实现安全、标注服务或共享缓存等目的. 有些代理被设计为在转发过程中对选定的消息或载荷施加变换, 如第 5.7.2 节所述.
"网关" (gateway, 又称 "反向代理") 是一种中间方, 它在出站连接上充当源服务器, 但会把收到的请求转换后入站转发给另一台或另一些服务器. 网关常用于封装遗留的或不受信任的信息服务, 通过 "加速器" 缓存提升服务器性能, 以及实现 HTTP 服务在多台机器上的分区或负载均衡.
所有适用于源服务器的 HTTP 要求同样适用于网关的出站通信. 网关可以用它想要的任何协议与入站服务器通信, 包括本规范范围之外的 HTTP 私有扩展. 然而, 一个希望与第三方 HTTP 服务器互操作的 HTTP 到 HTTP 网关, 在其入站连接上应当遵循对用户代理的要求.
"隧道" 在两条连接之间充当盲中继, 不改变消息. 一旦激活, 隧道就不再被视为 HTTP 通信的一方, 尽管该隧道可能是由某个 HTTP 请求发起的. 当被中继连接的两端都被关闭时, 隧道即不复存在. 隧道用于让一条虚拟连接穿过某个中间方, 例如当使用传输层安全 (Transport Layer Security, TLS, [RFC5246]) 来建立穿过共享防火墙代理的机密通信时.
上述中间方类别只考虑了那些作为 HTTP 通信参与者行事的中间方. 还有一些中间方可以作用于网络协议栈的较低层, 在消息发送方不知情或未许可的情况下过滤或重定向 HTTP 流量. 在协议层面, 网络中间方与中间人攻击 (man-in-the-middle attack) 无法区分, 它们常常因为误违反 HTTP 语义而引入安全缺陷或互操作性问题.
例如, "拦截代理" (interception proxy) [RFC3040] (通常也称为 "透明代理" (transparent proxy) [RFC1919] 或 "强制门户" (captive portal)) 与 HTTP 代理不同, 因为它不是由客户端选定的. 相反, 拦截代理会过滤或重定向外发的 TCP 80 端口报文 (偶尔也处理其他常见端口流量). 拦截代理常见于公共网络接入点, 作为一种在允许使用非本地 Internet 服务之前强制确认账户订阅的手段, 也存在于企业防火墙内部以执行网络使用策略.
HTTP 被定义为一种无状态协议, 这意味着每个请求消息都可以被孤立地理解. 许多实现依赖 HTTP 的无状态设计来复用被代理的连接, 或者跨多台服务器动态地对请求进行负载均衡. 因此, 除非连接是受保护的且专属于该代理, 服务器 MUST NOT 假定同一条连接上的两个请求来自同一个用户代理. 已知一些非标准的 HTTP 扩展 (例如 [RFC4559]) 违反该要求, 从而造成安全和互操作性问题.
2.4. 缓存
"缓存" (cache) 是先前响应消息的本地存储, 以及控制这些消息的存储、检索和删除的子系统. 缓存存储可缓存的响应, 以减少未来等价请求的响应时间和网络带宽消耗. 任何客户端或服务器 MAY 采用缓存, 不过服务器在充当隧道时不能使用缓存.
缓存的作用是: 如果链上某个参与者持有适用于该请求的缓存响应, 请求/响应链就会被缩短. 下面展示了当 B 持有先前从 O 收到 (经由 C) 的某响应的缓存副本, 而该请求未被 UA 或 A 缓存时, 所形成的链.
> >
UA =========== A =========== B - - - - - - C - - - - - - O
< <
如果允许缓存存储响应消息的副本以用于应答后续请求, 则该响应是 "可缓存的" (cacheable). 即使响应是可缓存的, 客户端或源服务器也可能对何时可以使用该缓存响应施加额外约束. HTTP 对缓存行为和可缓存响应的要求定义在 [RFC7234] 第 2 节中.
在万维网上以及大型组织内部, 部署着形形色色的缓存架构和配置. 其中包括用于节省跨洋带宽的全国性代理缓存层级、广播或多播缓存条目的协作系统、面向离线或高延迟环境的预取缓存条目的存档, 等等.
2.5. 一致性与错误处理
本规范依据参与者在 HTTP 通信中所扮演的角色来确定一致性判定标准. 因此, HTTP 要求被施加于发送方、接收方、客户端、服务器、用户代理、中间方、源服务器、代理、网关或缓存, 具体取决于该要求所约束的行为. 当某些 (社会性) 要求在单次通信的范围之外也适用时, 它们会被施加于实现、资源所有者和协议元素登记.
一个要求在区分 "创建一个协议元素" 与 "仅仅把收到的元素向下游转发" 时, 会使用动词 "generate" 而不是 "send".
如果一个实现遵守了它在 HTTP 中所扮演角色对应的全部要求, 则认为该实现是一致的 (conformant).
一致性既包括协议元素的语法, 也包括其语义. 发送方 MUST NOT 生成它所知含义为假的协议元素. 发送方 MUST NOT 生成不符合相应 ABNF 规则所定义文法的协议元素. 在给定消息内, 发送方 MUST NOT 生成那些只允许由其他角色的参与者生成的协议元素或语法备选项 (即发送方在该消息中并不具有的角色).
当解析收到的协议元素时, 接收方 MUST 能够解析任何长度合理、适用于接收方角色且符合相应 ABNF 规则所定义文法的值. 但请注意, 某些收到的协议元素可能不会被解析. 例如, 转发消息的中间方可能把某个 header-field 解析为通用的 field-name 和 field-value 两部分, 然后在不进一步解析 field-value 内部的情况下转发该头部字段.
HTTP 对许多协议元素没有特定的长度限制, 因为合适的长度会因部署环境和实现目的的不同而差异极大. 因此, 发送方与接收方之间的互操作性取决于对 "每个协议元素的合理长度是什么" 的共识. 此外, 对于某些协议元素, 普遍认为合理的长度在过去二十年的 HTTP 使用过程中已经发生了变化, 并且预计未来还会继续变化.
至少, 接收方 MUST 能够解析和处理这样的协议元素长度: 它不小于该接收方在其他消息中为同样这些协议元素所生成的值. 例如, 一个向其自有资源发布很长 URI 引用的源服务器, 在作为请求目标收到这些同样的引用时, 必须能够解析和处理它们.
接收方 MUST 按照本规范 (包括对本规范的扩展) 为其定义的语义来解释收到的协议元素, 除非接收方 (通过经验或配置) 已确定发送方对所隐含语义的实现不正确. 例如, 如果检查 User-Agent 头部字段后发现某个特定实现版本在收到某些内容编码时会出错, 那么源服务器可以忽略收到的 Accept-Encoding 头部字段的内容.
除非另有说明, 接收方 MAY 尝试从无效构造中恢复出一个可用的协议元素. HTTP 没有定义特定的错误处理机制, 除非这些机制对安全有直接影响, 因为协议的不同应用需要不同的错误处理策略. 例如, Web 浏览器可能希望对某个 Location 头部字段不符合 ABNF 的响应进行透明恢复, 而系统控制类客户端则可能认为任何形式的错误恢复都是危险的.
2.6. 协议版本管理
HTTP 使用 "
HTTP 消息的版本由消息第一行中的 HTTP-version 字段指明. HTTP-version 区分大小写.
HTTP-version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive
HTTP 版本号由两个十进制数字组成, 中间以 "." (句点或小数点) 分隔. 第一位数字 ("主版本号") 表示 HTTP 消息语法, 而第二位数字 ("次版本号") 表示在该主版本内, 发送方所遵从并能在未来通信中理解的最高次版本. 即使发送方只使用协议的向后兼容子集, 次版本号也宣告了发送方的通信能力, 从而使接收方知道可以在响应中 (由服务器) 或在未来请求中 (由客户端) 使用更高级的特性.
当把 HTTP/1.1 消息发送给 HTTP/1.0 接收方 [RFC1945] 或版本未知的接收方时, 该 HTTP/1.1 消息的构造方式应保证: 若忽略所有较新特性, 它可以被解释为一条合法的 HTTP/1.0 消息. 本规范对某些新特性施加了接收方版本要求, 从而使一致的发送方只有在通过配置或收到消息确定接收方支持 HTTP/1.1 之后, 才会使用兼容的特性.
在同一 HTTP 主版本的不同次版本之间, 头部字段的解释不会改变, 不过在缺少该字段时接收方的默认行为可能改变. 除非另有说明, HTTP/1.1 中定义的头部字段适用于 HTTP/1.x 的所有版本. 特别是 Host 和 Connection 头部字段应当由所有 HTTP/1.x 实现来实现, 无论它们是否声明遵从 HTTP/1.1.
如果新定义的语义允许被不识别它们的接收方安全地忽略, 那么引入新的头部字段时无需改变协议版本. 头部字段的可扩展性在第 3.2.1 节讨论.
处理 HTTP 消息的中间方 (即除充当隧道的中间方之外的所有中间方) MUST 在其转发的消息中发送自己的 HTTP-version. 换言之, 不允许在不确认消息中的协议版本与该中间方在收发消息两方面都遵从的版本相符的情况下, 就盲目转发 HTTP 消息的第一行. 如果转发的 HTTP 消息没有重写 HTTP-version, 当下游接收方依据消息发送方的版本来判断后续与该发送方通信时哪些特性可以安全使用时, 就可能出现通信错误.
客户端 SHOULD 发送这样的请求版本: 它是该客户端所遵从的最高版本, 且其主版本号不高于服务器所支持的最高版本 (如果已知的话). 客户端 MUST NOT 发送其并不遵从的版本.
如果已知服务器对 HTTP 规范的实现不正确, 客户端 MAY 发送较低的请求版本, 但只有在客户端至少尝试过一次正常请求, 并从响应状态码或头部字段 (例如 Server) 判断出服务器无法正确处理较高的请求版本之后, 才可以这样做.
服务器 SHOULD 发送这样的响应版本: 它是该服务器所遵从的最高版本, 且其主版本号小于或等于请求中收到的版本. 服务器 MUST NOT 发送其并不遵从的版本. 如果服务器出于任何原因希望拒绝服务客户端的主协议版本, 它可以发送 505 (HTTP Version Not Supported) 响应.
如果已知或怀疑客户端对 HTTP 规范的实现不正确, 并且无法正确处理较新版本的响应, 例如客户端无法正确解析版本号, 或者已知某个中间方即使不遵从给定的协议次版本也会盲目转发 HTTP-version, 那么服务器 MAY 对请求返回 HTTP/1.0 响应. 除非由特定的客户端属性触发 (例如当请求头部字段中的一个或多个, 如 User-Agent, 与已知有错的客户端所发送的值唯一匹配时), 否则 SHOULD NOT 执行此类协议降级.
HTTP 版本管理设计的意图是: 只有当引入不兼容的消息语法时才递增主版本号; 只有当对协议的修改增加了消息语义或暗示发送方具备额外能力时, 才递增次版本号. 然而, 对 [RFC2068] 与 [RFC2616] 之间引入的变更并未递增次版本号, 而本次修订特意避免了对协议做任何此类变更.
当收到的 HTTP 消息其主版本号是接收方所实现的, 但次版本号高于接收方所实现的版本时, 接收方 SHOULD 按照该主版本内接收方所遵从的最高次版本来处理该消息. 接收方可以假定: 当一条次版本号较高的消息被发送给尚未声明支持该较高版本的接收方时, 它已具有足够的向后兼容性, 可以被同一主版本的任何实现安全处理.
2.7. 统一资源标识符
统一资源标识符 (URI) [RFC3986] 在 HTTP 中被普遍用作标识资源的手段 ([RFC7231] 第 2 节). URI 引用用于指定请求目标、表示重定向以及定义关系.
"URI-reference"、"absolute-URI"、"relative-part"、"scheme"、"authority"、"port"、"host"、"path-abempty"、"segment"、"query" 和 "fragment" 的定义采用自 URI 通用语法. 针对可能包含非空路径分量的协议元素, 定义了 "absolute-path" 规则. (该规则与 RFC 3986 的 path-abempty 规则略有不同, 后者允许引用中使用空路径; 也与 path-absolute 规则不同, 后者不允许以 "//" 开头的路径.) 针对可能包含相对 URI 但不包含片段分量的协议元素, 定义了 "partial-URI" 规则.
URI-reference = <URI-reference, see [RFC3986], Section 4.1>
absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
relative-part = <relative-part, see [RFC3986], Section 4.2>
scheme = <scheme, see [RFC3986], Section 3.1>
authority = <authority, see [RFC3986], Section 3.2>
uri-host = <host, see [RFC3986], Section 3.2.2>
port = <port, see [RFC3986], Section 3.2.3>
path-abempty = <path-abempty, see [RFC3986], Section 3.3>
segment = <segment, see [RFC3986], Section 3.3>
query = <query, see [RFC3986], Section 3.4>
fragment = <fragment, see [RFC3986], Section 3.5>
absolute-path = 1*( "/" segment )
partial-URI = relative-part [ "?" query ]
HTTP 中每个允许使用 URI 引用的协议元素都会在其 ABNF 产生式中指明: 该元素允许任意形式的引用 (URI-reference)、只允许绝对形式的 URI (absolute-URI)、只允许路径和可选的查询分量, 还是上述几种的组合. 除非另有说明, URI 引用是相对于有效请求 URI (第 5.5 节) 来解析的.
2.7.1. http URI 方案
"http" URI 方案在此定义, 其用途是: 依据标识符与某个潜在 HTTP 源服务器所管辖的层级命名空间之间的关联来铸造标识符; 该源服务器在给定端口上监听 TCP ([RFC0793]) 连接.
http-URI = "http:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ]
"http" URI 的源服务器由 authority 分量标识, 该分量包含主机标识符和可选的 TCP 端口 ([RFC3986] 第 3.2.2 节). 层级路径分量和可选的查询分量充当该源服务器命名空间内某个潜在目标资源的标识符. 可选的片段分量允许间接标识一个次级资源, 它与 URI 方案无关, 如 [RFC3986] 第 3.5 节所定义.
发送方 MUST NOT 生成主机标识符为空的 "http" URI. 处理此类 URI 引用的接收方 MUST 视其为无效而予以拒绝.
如果主机标识符以 IP 地址形式给出, 那么源服务器就是该 IP 地址上所指明 TCP 端口的监听者 (如果有的话). 如果 host 是注册名, 那么该注册名是一个间接标识符, 需与名称解析服务 (如 DNS) 配合使用, 以找到该源服务器的地址. 如果端口子分量为空或未给出, 则默认使用 TCP 80 端口 (为 WWW 服务保留的端口).
请注意, 存在一个具有给定 authority 分量的 URI, 并不意味着在该主机和端口上总有 HTTP 服务器在监听连接. 任何人都可以铸造 URI. authority 分量所确定的是: 谁有权对以该标识资源为目标的请求作出权威响应. 注册名和 IP 地址的这种委托性质, 基于对所指主机和端口的控制, 形成了一个联邦式命名空间, 无论是否存在 HTTP 服务器. 与确立权威相关的安全考量见第 9.1 节.
当 "http" URI 被用于需要访问所指资源的场景时, 客户端 MAY 尝试按如下方式访问: 把主机解析为 IP 地址, 在该地址的所指端口上建立 TCP 连接, 并把包含该 URI 标识数据 (第 5 节) 的 HTTP 请求消息 (第 3 节) 发送给服务器. 如果服务器用一条非临时 (non-interim) 的 HTTP 响应消息响应该请求 (如 [RFC7231] 第 6 节所述), 那么该响应就被视为对客户端请求的权威应答.
尽管 HTTP 与传输协议无关, 但 "http" 方案是特定于基于 TCP 的服务的, 因为名称委托过程依赖 TCP 来确立权威. 基于其他底层连接协议的 HTTP 服务想必会用不同的 URI 方案来标识, 正如 "https" 方案 (见下文) 被用于需要端到端安全连接的资源一样. 也可能使用其他协议来提供对 "http" 标识资源的访问 —— 只有权威接口才是特定于 TCP 的.
URI 通用语法中针对 authority 的定义还包含一个已废弃的 userinfo 子分量 ([RFC3986] 第 3.2.1 节), 用于在 URI 中携带用户认证信息. 有些实现把 userinfo 分量用于认证信息的内部配置, 例如在命令调用选项、配置文件或书签列表中; 尽管这种用法可能泄露用户标识符或口令. 当在消息内生成 "http" URI 引用作为请求目标或头部字段值时, 发送方 MUST NOT 生成 userinfo 子分量 (及其 "@" 定界符). 在使用来自不受信任来源的 "http" URI 引用之前, 接收方 SHOULD 解析其中是否含有 userinfo, 并把它的出现视为错误; 它很可能被用来为钓鱼攻击掩盖真实权威.
2.7.2. https URI 方案
"https" URI 方案在此定义, 其用途是: 依据标识符与某个潜在 HTTP 源服务器所管辖的层级命名空间之间的关联来铸造标识符; 该源服务器在给定 TCP 端口上监听受 TLS 保护的连接 ([RFC5246]).
上文为 "http" 方案列出的所有要求同样也是 "https" 方案的要求, 不同之处在于: 如果端口子分量为空或未给出, 则默认使用 TCP 443 端口; 并且用户代理 MUST 在发送第一个 HTTP 请求之前, 确保其到源服务器的连接通过强加密得到端到端的保护.
https-URI = "https:" "//" authority path-abempty [ "?" query ]
[ "#" fragment ]
请注意, "https" URI 方案同时依赖 TLS 和 TCP 来确立权威. 通过 "https" 方案提供的资源与 "http" 方案没有共享身份, 即使它们的资源标识符指向同一个 authority (监听同一 TCP 端口的同一主机). 它们是彼此不同的命名空间, 被视为彼此不同的源服务器. 然而, 如果某个 HTTP 扩展被定义为适用于整个主机域, 例如 Cookie 协议 [RFC6265], 那么它可以让由一个服务设置的信息影响到与匹配的主机域组中其他服务的通信.
对 "https" 标识资源进行权威访问的过程定义在 [RFC2818] 中.
2.7.3. http 与 https URI 的归一化与比较
由于 "http" 和 "https" 方案符合 URI 通用语法, 这类 URI 按照 [RFC3986] 第 6 节定义的算法进行归一化和比较, 并采用上文为各方案描述的默认值.
如果端口等于该方案的默认端口, 则其规范形式是省略端口子分量. 当不以绝对形式用作 OPTIONS 请求的请求目标时, 空路径分量等价于绝对路径 "/", 因此规范形式是改为提供路径 "/". 方案和主机不区分大小写, 通常以小写形式提供; 所有其他分量则以区分大小写的方式比较. 除 "reserved" 集合之外的字符与其百分号编码的八位组等价: 规范形式是不对它们进行编码 (见 [RFC3986] 第 2.1 和 2.2 节).
例如, 下面三个 URI 是等价的:
http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html