URL“方案加权限”的正式名称

Question

假设一个绝对的 http 或 https URL。我正在为路径之前的 URL 部分寻找一个“官方”或普遍接受的名称。

    http://foo:bar@example.com:8042/over/there?name=ferret#nose
    \_____________________________/
                  |
              this part

RFC 3986 定义 URL 语法部分如下：

    http://foo:bar@example.com:8042/over/there?name=ferret#nose
    \__/   \______________________/\_________/ \_________/ \__/
      |               |                |            |        |
   scheme         authority           path        query   fragment

RFC 6454 将 URL 的来源（如“相同来源”）定义为三元组（方案、主机、端口）：

    http://foo:bar@example.com:8042/over/there?name=ferret#nose
    \__/           \______________/
      \________________/
              |
           origin

因此，这两个术语都不合适。我正在查看的部分是否有一个好的术语，或者我是否坚持“方案（加上://）加上权限”？

Answer 1

实际上，路径之前的 URL 部分的名称和 current URL standard 的名称实际上只是 origin。

URL 的 :// 部分只是一个句法（或词法？）工件，在讨论任何使用或处理 URL 的实际行为（当然低级解析器除外）的讨论中从来没有真正需要提及)。

用户名-密码部分是一个不符合标准的错误功能，现在仅作为历史错误进行讨论。 relevant part of the current URL standard 有话要说；

没有一致的方式来表示 URL 的用户名或密码 在 URL 字符串中记录。

因此，在实践中，对于任何符合当前标准如何定义 URL 的 URL 的正常讨论，仅根据其最高级别的部分仅四个部分来谈论 URL 就足够了：它的 origin、它的路径、它的查询（部分）和它的片段（部分）。

当然，这至少是 current URL standard 本身的限制。

Answer 2

它必须只是“计划加权限”。请记住，您不能拥有仅具有方案和权限的有效 URI，因此该组合不会作为一个单元进行讨论，因此最终没有名称。

还要注意，HTTP URI 中从未允许使用 userinfo；特定方案可以禁止或限制特定部分的值。一些浏览器有一个设计缺陷，他们会接受用户信息和基于身份验证的标头，但现在大多数浏览器至少会警告这样做，如果他们允许的话。