Question

假设绝对的http或https网址。我正在寻找路径之前的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

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

URL的://部分只是一个语法（或词汇？）工件，在讨论消费或处理URL的任何实际行为时从未真正需要提及（除了低级解析器之外）当然）。

用户名 - 密码部分是一种不合规的错误，现在只对讨论作为历史错误有用。 relevant part of the current URL standard可以说明这一点;

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

因此，在实践中，对于与当前标准定义URL的方式一致的URL的任何正常讨论，仅仅根据其最高级别部分仅仅四个部分来谈论URL就足够了： origin < / em>，其路径，其查询（部分）及其片段（部分）。

当然这至少是current URL standard本身限制它的内容。

Answer 2

它必须只是＆＃34; scheme plus authority＆＃34;。请记住，您不能拥有一个只有方案和权限的有效URI，因此这个组合不会作为一个单元来讨论，所以没有最终结果一个名字。

另请注意，HTTP URI中从未允许过userinfo;特定方案可以禁止或限制特定部分的值。有些浏览器存在设计缺陷，他们会在其上接受userinfo和基本身份验证标头，但现在大多数人至少会警告这一点，如果他们允许的话。

URL“scheme plus authority”

2 个答案: