21

假设一个绝对的 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

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

4

2 回答 2

9

实际上，路径之前的 URL 部分的名称和当前的 URL 标准实际上只是origin。

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

用户名-密码部分是一个不符合要求的错误特征，现在只能作为历史错误进行讨论。当前 URL 标准的相关部分对此有这样的说法；

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

因此，在实践中，对于任何与当前标准如何定义 URL 一致的 URL 的正常讨论，仅根据其最高级别的部分仅四个部分来讨论 URL 就足够了：它的origin，它的path，它的query (部分）及其片段（部分）。

当然，这至少是当前 URL 标准本身所限制的。

于 2015-09-18T18:08:19.037 回答
1

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

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

于 2015-09-21T15:26:03.677 回答