archive-org.com » ORG » J » JABBERCN.ORG

Total: 303

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • RFC3986 - Jabber/XMPP中文翻译计划
    3 所述 当一个URI发生了违反一个或多个格式特有的约束的情况 该格式特有的解析过程应该把该参数标记为一个错误而不是忽略未使用的部分 这样做减少了相当的URIs的数量并有助于检测对通用语法的滥用 它可以预示构建的URI把用户带入歧途 7 6 机构 一些URI schemes包含一个层次元素来描述一个命名的机构 这样由该URI的其他部分定义的命名空间的管理方式就被授予那个机构 它可以相应地进一步授予 通用语法提供了一个常见方法来基于已注册的名称或服务器地址来区分一个机构 以及可选的端口和用户信息 机构部件的前面是一个双斜杠 并结束于下一个斜杠 问号 或井号 字符 或随着该URI结束 authority userinfo host port 如果端口部件是空的 URI制作者和正规化者应该省略把端口和主机分隔开的 分隔符 一些schemes不允许用户信息 和 或 端口子部件 如果一个URI包含一个机构部件 那么路径部件必须要么是空的要么以一个斜杠 字符开始 不检查的解析器 那些很少分隔一个URI参数到它的主要部件的解析器 将经常忽略机构的子部件结构 把从双斜杠到第一个终止分隔符之间的东西当成一个不透明的字符串 直到该URI被解析的时间 用户信息 用户信息子部件可以包含一个用户名和 可选的 关于如何获得授权访问资源的格式特有的信息 用户信息 如果出现 后面会跟随一个商标 以和主机分开 userinfo unreserved pct encoded sub delims 在用户信息字段对格式 user password 的使用已经被废弃了 应用不应该在一个用户信息子部件中找到的第一个冒号 字符后面提出任何明码文本数据 除非在该冒号后面的数据是空字符串 表示没有密码 当收到作为一个参数的一部分的这样的数据的时候 应用可以选择忽略或拒绝这类数据并且应该拒绝这类数据以未加密方式存储 以明码方式通过验证信息已经被证明在绝大多数情况使用它是一个安全风险 为了用户反馈的目的而提供一个URI的应用 类似图形化的超文本浏览 应该以某种从一个URI的其他部分区分出来的方式提供用户信息 在可能的时候 当发生用户信息已经被手工误导看起来像一个被信任的域名的情况 这类表达可以帮助到用户 7 6 主机 机构的主机子部件是由一个封装在方括号内的IP文字 一个点分十进制格式的IPv4地址 或一个注册名称来标识的 主机子部件是大小写敏感的 在一个URI中出现了主机子部件不意味着该格式要求访问互联网上的给定主机 在一些情况下 主机语法只被用于重用现有的用于DNS的创建和部署的注册流程 从而获得一个全局唯一的名称而不用费劲部署另一个注册表 无论如何 这种用法有它自己的代价 域名所有者可能因为URI制作者无法预计的原因而随时变更 在另外一些情况下 子部件内的数据标识一个注册名称但没有任何事情要在一个互联网主机上去做 我们使用ABNF规则的名称 host 是因为那是它最常用的目的 不是它仅有的目的 host IP literal IPv4address reg name 主机的语法规则是含糊的 因为不能完全区分一个IPv4地址和一个注册名称 为了澄清语法 我们应用 先匹配者赢 算法 如果主机匹配IPv4地址规则 那么它应该被认为是一个IPv4地址文字而不是一个注册名称 尽管主机是大小写敏感的 为了统一的目的制作者和正规化者应该对注册名和十六进制地址使用小写 只在百分号编码使用大写字母 由版本6 RFC3513 或更晚版本的互联网协议文字地址标识的主机 是通过方括号 和 围起IP文字来区分的 这是唯一一个被允许在URI语法中出现方括号字符的地方 在可预见的将来 还未定义的IP文字地址格式 实现可以使用一个可选的版本标记来显式地指示这样一个格式而不是依靠启发式的决定 IP literal IPv6address IPvFuture IPvFuture v 1 HEXDIG 1 unreserved sub delims 版本标记不指示IP版本 而是指示该文字格式的未来版本 同样的 实现不能为下面描述的现有的IPv4和IPv6文字地址格式提供该版本标记 如果一个URI包含一个以 v 大小写不敏感 开始的IP 文字 标识那个版本标记是当前的 当它由一个不理解该版本标记的含义的应用解参考的时候 那么该应用返回一个适当的错误 地址机制不支持 一个由IPv6文字地址标识的主机被展现在不带前述的版本标记的方括号内 这里的ABNF是对一个 RFC3513 提供的IPv6文字地址的文本定义的翻译 这个语法不支持IPv6范围地址区域标识 一个128位的IPv6地址被分为8个16位的片段 每一片展现为大小写敏感的16进制数字 使用一到四个十六进制数字 允许以零开头 这8个编码的片首先是给定的最大有效数 由冒号分开 可选的 最小有效的两个片段可以被替换来展现IPv4地址的文本格式 地址中的一系列一个或多个连续的零值的16位片段可以被忽略 省略它们的所有数字并确切地在它们的位置留下两个连续的冒号以标记该省略 IPv6address 6 h16 ls32 5 h16 ls32 h16 4 h16 ls32 1 h16 h16 3 h16 ls32 2 h16 h16 2 h16 ls32 3 h16 h16 h16 ls32 4 h16 h16 ls32 5 h16 h16 h16 6 h16 h16 ls32 h16 h16 IPv4address least significant 32 bits of address h16 1 4HEXDIG 16 bits of address represented in hexadecimal 一个由IPv4文字地址标识的主机被展现为点分十进制表示法 一系列四个范围为0到255的十进制数字 以 分隔 如 RFC1123 所述 参考 RFC0952 注意点符号的其他格式可以在一些平台上被解释执行 如 7 4 所述 但本语法只允许四个八位字节的点分十进制格式 IPv4address dec octet dec octet dec octet dec octet dec octet DIGIT 0 9 x31 39 DIGIT 10 99 1 2DIGIT 100 199 2 x30 34 DIGIT 200 249 25 x30 35 250 255 一个被注册名标识的主机是一系列字符 常常要用它在一个本地定义的主机或服务名称注册表中来查找 尽管该URI的格式特有的语义可以要求替换成一个特有的注册表 或固定的名称表 大部分常用名称注册表机制是域名系统 DNS 在DNS中查询到一个注册名要使用 RFC1034的3 5节 和 RFC1123的2 1节 中定义的语法 这样一个名称包含了一系列以 分隔的域标签 每个域标签以一个文字数字字符开始和结束 也可能包含 字符 一个在DNS中完全合格的域名的最右边的域标签可以在后面带一个单独的 并且如果有必要把完整域名和一些本地域名去分开的话则必须带它 reg name unreserved pct encoded sub delims 如果URI格式为主机定义了一个缺省值 那么当该主机子部件未定义或当注册名称为空 零长度 的时候那个缺省值适用 例如 file URI格式被定义成没有机构 空主机 且 localhost 全都代表最终用户的机器 反之一个缺少机构或空主机的 http 格式被认为是非法的 本协议不强制一个特定的注册名称查询技术并且因而如果不在互操作性的必要情况之上约束reg name语法 反之 它把注册名称语法一致性问题委托给每个执行URI解析的应用的操作系统 并且那个and操作系统来决定允许使用哪种技术来确定主机身份 一个URI解析实现可能使用DNS 主机表 黄页 NetInfo WINS 或任何其他系统来查询注册名称 然而 一个全局范围的命名系统 类似DNS完全合格的域名 对打算全局范围使用的URIs是必要的 URI制作者应该按照DNS语法使用名称 即使当DNS的使用不会立刻被看到的时候 并且应该限制这些名称的长度不超过255个字符 reg name语法允许百分号编码字节 这是为了以一个独立于基本的名称解析技术的统一的方法来展现非ASCII注册名称 非ASCII字符必须首先被根据UTF 8 STD63 编码 并且接着每个UTF 8序列相应的八位字节必须被百分号编码以展现成URI字符 URI制作应用不能对主机使用百分号编码 除非它被用于展示一个UTF 8字符序列 当一个非ASCII注册名称展现了一个打算通过DNS解析的国际化域名 该名称必须在名称查询之前被转换成IDNA编码 RFC3490 URI制作者应该以IDNA编码提供这些注册名称 而不是一个百分号编码 如果他们希望最大化和外部URI解析者的互操作能力 端口 机构的端口子部件由一个可选的跟随在主机后面并且从单个的冒号 字符之后开始的十进制端口号来指定 port DIGIT 一个格式可以定义一个缺省端口 例如 http 格式定义了一个缺省端口 80 和它的保留TCP端口号码一致 由端口号指定的端口的类型 例如 TCP UDP SCTP 是由该URI格式定义的 URI制作者和正规化者应该省略端口部件和它的 边界 如果端口是空的或它的值和该格式的缺省值相同的话 路径 路径部件包含数据 常常组织成层次格式 它连同非层次化的查询部件 3 4 的数据 服务于识别在该URI的格式和命名机构 如果有 范围内的一个资源 路径由第一个问号 或数字符号 字符或该URI的结尾来终止 如果一个URI包含一个机构部件 那么该路径部件必须要么是空的要么以一个斜杠 字符开始 如果一个URI不包含一个机构部件 那么路径不能以双斜杠字符 开始 此外 一个URI引用 4 1 可以是一个和路径相关的引用 在那种情况下第一个路径片段不能包含一个冒号 字符 ABNF要求五个独立的规则来消除这些情况的歧义 只有其中一种情况将会在一个给定的URI引用中和该路径子字符串匹配 我们使用通用术语 路径部件 来描述由这些规则的解析器匹配的该URI子字符串 path path abempty begins with or is empty path absolute begins with but not path noscheme begins with a non colon segment path rootless begins with a segment path empty zero characters path abempty segment path absolute segment nz segment path noscheme segment nz nc segment path rootless segment nz segment path empty 0 pchar segment pchar segment nz 1 pchar segment nz nc 1 unreserved pct encoded sub delims non zero length segment without any colon pchar unreserved pct encoded sub delims 一个路径包含一系列由斜杠 字符分隔的路径片段 对于一个URI来说总是会定义一个路径 尽管定义的路径可能是空 零长度 指示层次用的斜杠字符之在一个URI用作指示相对引用的时候是必需的 例如 URI mailto fred example com 有一个路径 fred example com 反之 URI foo info example com fred 有一个空路径 路径片段 和 也就是点片段 被定义用于路径名称层次的相对引用 它们被用于相对路径引用的开始 RFCSection 4 2 以指示名称的层次树中的相对位置 这和某些操作系统的文件目录结构分别指示当前目录和父目录的它们的角色类似 无论如何 和在一个文件系统中不一样 这些点片段只在URI层次中被这样理解并且被从解析过程的一部分中移除 5 2 除了层次路径中的点片段之外 一个路径片段被通用语法当成不透明的 URI制作应用经常在一个片段中使用保留字符以界定格式特有的或解参考处理者特有的子部件 例如 分号 和等号 保留字符经常被用于界定适用于那个片段的参数和参数值 逗号 保留字符经常被用于类似的目的 例如 一个URI制作者可以使用一个类似 name v 1 1 的片段来指示一个对 name 的1 1版的引用 反之另一个可能使用类似 name 1 1 的片段来指示相同的东西 参数类型可以由格式特有的语义来定义 但是在大多数情况下一个参数的语法对该URI的解参考算法的实现来说是特有的 查询 查询部件包含非层次化的数据 以及路径部件中的数据 3 3 用来从该URI的格式和命名机构 如果有 中识别一个资源 查询部件由第一个问号 字符指示并由一个数字符号 字符或该URI的结尾终止 query pchar 字符斜杠 和问号 可以展现该查询部件内的数据 注意当它被用于相对引用的基础URI的时候 5 1 一些旧的 错误的实现可能没有正确处理这类数据 显然是因为它们在查找层次分隔符的时候未能把查询部件从路径数据中区分开来 无论如何 因为查询部件经常被用于以 键 值 对的格式携带识别信息并且一个常被使用的值是对另一个URI的引用 它经常比百分号编码那些字符有更好的可用性 片段 一个URI的片段标识符部件允许对一个主要资源引用的次要资源的非直接身份认证以及额外的识别信息 被识别的次要资源可以是该主要资源的一部分或子集 或一些由那些陈述所定义或描述的资源 一个片段标识符部件是通过一个数字符号 字符的出现来指示的并由该URI的结尾来终止 fragment pchar 一个片段标识符的语义可以是由一组从主要资源的获取动作导致的表现来定义的 所以片段的格式和解析依赖于一个潜在的获取展现的媒体类型 RFC2046 即使这样一个获取只在URI被解参考的时候执行 如果没有这类体现存在 那么该片段的语义被认为是未知的并且是有效的无限制 片段标识符语义独立于URI格式并且因而不能被格式协议重新定义 单独的媒体类型可以在片段标识符语法内定义它们自己的约束或结构用于指定不同类型的子集 视图或对那个媒体类型可识别的次要资源的外部引用 如果主要资源有多个展现 这中情况常常是资源的展现是该获取请求的属性的可选的基础 又名 内容协商 那么无论该片段识别的什么都应该和那些展现一致 每个展现应该要么定义片段这样它对应相同的次要资源 无论它是如何展现的 要么应该让该片段未定义 即 未找到 对任何URI 片段标识符部件的使用不代表将执行一个获取动作 一个带了片段标识符的URI可被用于指向次要资源而不代表任何主要资源是可访问的或永远无法访问 片段标识符在信息获取系统中有一个特别的作用是作为客户端间接引用的主要格式 允许一个作者特别地识别一个现有的只由该资源所有者间接提供的资源的样子 同样 片段标识符不被用于一个URI的格式特有的处理 反之 在解参考之前片段标识符被从URI的其他部分分离出来 因而该片段本身的识别信息的解参考由用户代理执行 和该URI格式无关 尽管这个独立的处理经常被认为缺少信息 特别是当引用随时间移动的时候引用的准确重定向 它也用于防止信息提供者禁止引用作者在一个可选的资源中引用信息 间接引用也为系统使用URIs提供额外的可伸缩性和可扩展性 因为定义和部署新媒体类型比新身份格式更容易 斜杠 和问号 被允许在片段标识符内展示数据 注意一些旧的 错误的实现可能未正确处理这个数据 当它被用作相对引用的基础URI的时候 5 1 用法 当应用引用一个URI的时候 它们不总是使用该 URI 语法规则定义的引用的完整格式 为了节省空间和方便层次化区域 一些互联网协议元素和媒体类型格式允许一个URI的缩写 反之其他则把语法限制到URI的某个特定格式 我们在本文定义引用语法的最常见格式 因为它们影响和以来通用语法的设计 为了解释的一致性而要求一个通用解析算法 URI引用 URI引用常常代表一个资源标识符的最常见的用法 URI reference URI relative ref 一个URI引用要么是一个URI要么是一个相对引用 如果该URI引用的前缀和跟随在它的冒号后面的格式的语法不匹配 那么该URI引用是一个相对引用 一个URI引用典型地首先被解析成5个URI部件 以确定什么组件是当前的以及该引用是否是相对的 接着 每个部件被解析为子部件和它们的校验 URI引用的ABNF 遵循 先匹配者赢 的消除歧义规则 足够为通用语法定义一个校验解析器 对正则表达式熟悉的读者们应该去看 附录B 的一个非校验的URI引用解析器的例子 它将使用任何给定的字符串并提取该URI部件 相对引用 一个相对引用可以方便地用层次化语法 1 2 3 表达和另一个层次化URI的命名空间相关的一个URI引用 relative ref relative part query fragment relative part authority path abempty path absolute path noscheme path empty 由一个相对引用所指向的URI 也被认为是目标URI 通过应用 第5章 的引用解析算法来获得 一个开始于两个斜杠字符的相对引用被称为一个网络路径引用 这类引用很少被使用 一个开始于单个斜杠字符的相对引用被称为一个绝对路径引用 一个不以斜杠字符开始的相对引用被称为一个相对路径引用 一个包含一个冒号字符的路径段落 例如 this that 不能被用作一个相对路径引用的第一个段落 因为它会被误认为一个格式名称 这样一个段落必须在它前面放一个点段落 例如 this that 以制作一个相对路径引用 绝对URI 一些协议元素仅被一个不带片段标识符的URI的绝对格式允许 例如 定义一个符合不允许片段的绝对URI语法规则的基础URI用于晚些时候供相对引用调用 absolute URI scheme hier part query URI格式协议必须定义它们自己的语法 这样所有和它们的格式特有的语法匹配的字符也将和 绝对URI 语法匹配 格式协议将不定义片段标识符语法或用法 不管它对来自那个格式的资源标识符的适用性如何 因为片段标识符直交于格式定义 无论如何 鼓励格式协议包含大范围的示例 包括展示携带了片段标识符的格式的URI如何使用 当这类用法是恰当的时候 同文引用 当一个URI引用指向这样一个URI 除了它的片段部件以外 如果有的话 和基础URI 5 1 完全一样 那个引用被称为一个 同文 引用 同文引用的最常用的例子是空的或只包含一个后面跟随着片段标识符的数字标记 分隔符的相对引用 当一个同文引用为了一个获取动作而被解参考 那个引用的目标被定义成在该引用的同一个实体 展示 文档 或消息 中 所以 一个解参考不应改导致一个新的获取动作 在基础的和目标的URIs的比较之前进行正规化 如 6 2 2 和 6 2 3 所述 是被允许的 但是实践中很少被执行 正规化可以增加同文引用集合 这有利于某些缓存引用 同样 引用作者不应该假定那是轻微的不同 甚至等价 引用URI将 或将不 被任何给定应用理解为一个同文引用 后缀引用 URI语法是为通过URI格式明确地引用资源和可扩展性而定义的 然而 因为URI识别和用法以及普及了 传统媒体 电视 广播 报纸 公告牌 等等 已经越来越多地使用一个URI的后缀来作为一个引用 只包含URI的机构和路径部分 类似 www w3 org Addressing 或简单的一个它自己的DNS注册名称 这类引用主要是为了自然人而不是机器理解 同时假定基于上下文的启发对完成该URI是足够的 例如 大部分以 www 开始的注册名似乎有一个URI前缀 http 尽管没有对一个URI后缀消除歧义的启发的标准集合 一些客户端实现云讯它们由用户输入并且启发式地理解 尽管使用后缀引用在实践中很常见 应该避免任何的可能并且应该永远不在被期望长期使用的引用的情况下使用 上面提到的启发将随事件改变 特别是当一个新的URI格式流行的时候 并且当超出上下文使用的时候经常是不正确的 进一步的 按照 RFC1535 的那些描述 它们能导致安全性问题 因为一个URI后缀和一个相对路径引用有相同的语法 一个后缀引用不能被用于被期望使用相对引用的上下文中 结果是 后缀引用被限制于没有定义基础URI的地方 类似对话框和离线广告 引用解析 本章定义解析一个允许相对引用的上下文中的URI引用的过程 结果是一个和 第3章 的 URI 语法规则匹配的字符串 建立基础URI 术语 相对 暗示存在一个应用于相对引用的 基础URI 除了仅片段引用 4 4 相对引用只在已知一个基础URI的时候有用 一个基础URI必须在解析可能被引用的URI之前由解析器建立 一个基础URI必须遵循 absolute URI 语法规则 4 3 如果该基础是从一个URI引用URI获得的 那么该引用必须在它被用作一个基础URI之前被转化成绝对格式并剥离任何片段部件 一个引用的基础URI可以以四种方法之一来建立 在下面按优先级逐一讨论 优先级的顺序以术语的层级来考虑 被定义得最靠近基础URI的就是最高优先级 图形化显示如下 relative reference 5 1 1 Base URI embedded in content 5 1 2 Base URI of the encapsulating entity message representation or none 5 1 3 URI used to retrieve the entity 5 1 4 Default Base URI application dependent 嵌入在内容里的基础URI 在特定的媒体类型中 一个用于相对引用的基础URI可能被封装在内容本身之中 这它能很容易地被一个解析器获得 这对于描述性文档是很有用的 类似内容表格等 它可以通过协议被转换成其他东西而不是它们常常被获取的时候的上下文 例如 email 或 USENET 新闻 指定一个基础URI如何被每个媒体类型嵌入超出了本协议的范围 当有适当的语法可用的时候 它由和每个媒体类型相关的数据格式协议来描述 来自封装实体的基础URI 如果没有基础URI被封装 则该基础URI由展示的获取上下文来定义 对一个封闭在另一个实体中的文档来说 这样一个消息或存档 获取上下文就是那个实体 所以 一个展示的缺省基础URI就是把展现封装在其中的那个实体的基础URI 在一个MIME容器类型 例如 消息和多部件类型 中封装一个基础URI的机制由MHTML RFC2557 定义 协议不使用MIME消息头语法 但是的确允许某些标记元数据的格式被包含在消息中 可能为了定义一个基础URI成为一个消息的一部分来定义它们自己的语法 来自检索URI的基础URI 如果没有内嵌的基础URI并且表现未封装到一些其他实体中 那么 如果一个URI被用来获取表现 那个URI将被认为是基础URI 注意如果获取动作是一个重定向请求导致的 最后被使用URI 即 导致实际的获取表现的动作的URI 是基础URI 缺省基础URI 如果没有适用以上描述的条件 那么基础URI由应用的上下文定义 因为这个定义需要依赖应用 如果使用其他方法之一未能定义基础URI可能导致同样的内容在不同类型的应用中有不同的解释 一个包含相对引用的表现的发送者要负责确保那些应用的一个基础URI能被建立 除了仅片段的引用 相对引用只能被用于基础URI被良好定义的可靠情形之下 相对解析 本章描述了把一个和给定基础URI相关的URI引用转换成引用目标的已解析部件的算法 然后该部件被重写成目标URI的格式 如 5 3 所述 这个算法提供最后的结果 能被用于测试其他实现的输出 应用可以使用某些其他算法来实现相对引用解析 提供的结果将和本算法的结果吻合 预解析基础URI 基础URI Base 是根据 5 1 的步骤建立的并被解析成 3 描述的五个主要的部件 注意在一个基础URI中只有格式部件是必需的 其他部件可以是空的或未定义的 如果一个部件的相关分割符未出现在该URI引用之中那么该部件是未定义的 路径部件永远不会是未定义的 虽然它可以是空的 基础URI的正规化 如 6 2 2 和 6 2 3 所述 是可选的 一个URI引用必须在它能被正规化之前被转换成它的目标URI 转换引用 对每个URI引用 R 来说 以下伪码描述了一个把R转换成它的目标URI T 的算法 URI引用被解析成 5 个URI部件 R scheme R authority R path R query R fragment parse R 一个非约束的解析器可以忽略引用中的格式 如果该引用和基础URI的格式是相同的 if not strict and R scheme Base scheme then undefine R scheme endif if defined R scheme then T scheme R scheme T authority R authority T path remove dot segments R path T query R query else if defined R authority then T authority R authority T path remove dot segments R path T query R query else if R path then T path Base path if defined R query then T query R query else T query Base query endif else if R path starts with then T path remove dot segments R path else T path merge Base path R path T path remove dot segments T path endif T query R query endif T authority Base authority endif T scheme Base scheme endif T fragment R fragment 合并路径 上面的伪码适用于一个 合并 程序 用于合并相对路径引用和基础URI路径 它是如下完成的 如果基础URI有一个已定义的机构部件和一个空路径 则返回一个包含和引用路径一起的 的字符串 否则 返回一个字符串 包含该引用的路径部件加上除了该基础URI的路径的最后一个片段的所有其他片段 即 除基础URI路径最右边的 后面的任何符号 或除了完整的基础URI路径 如果该基础URI不包含任何 符号 移除点片段 该伪码也适用于一个 移除点片段 程序 用于从一个被引用路径解释和移除特定的 and 完整路径片段 这要在该路径被从一个引用提取出来之后来做 无论该路径是否相对的 目的是在格式化目标URI之前移除任何非法或无关的点片段 尽管有很多方法可以完成这个移除过程 我们描述一个使用两个字符串缓冲的简单方法 1 输入缓冲以刚加上的路径部件初始化 而输出缓冲被初始化成空字符串 2 当输入缓冲是空的时候 按以下回路 A 如果输入缓冲以前缀 或 开始 那么从输入缓冲移除该前缀 否则 B 如果输入缓冲以前缀 或 开始 这里 是一个完整的路径片段 那么在输入缓冲中把那个前缀替换成 否则 C 如果输入缓冲以前缀 或 开始 这里 是一个完整路径片段 那么在输入缓冲中把该前缀替换成 并从输出缓冲中移除最后的片段以及它前面的 如果有的话 否则 D 如果输入缓冲仅包含 或 那么从输入缓冲移除它 否则 E 在输入缓冲中把第一个路径片段移动到输出缓冲的尾部 包括初始的 符号 如果有的话 和任何随后的符号 但不包括下一个 符号或输入缓冲的结尾 3 最后 输出缓冲被返回一个 移除了点片段 的结果 注意点片段的目的是在URI引用中用于在基础URI中表达一个和名称的层次相对的标识符 移除点片段 算法通过移除额外的点片段来尊重层次而不是把它们当成一个错误或留着它们去被解参考实现误解 接下来演示上述步骤如何应用于合并路径的两个例子 展示每个步骤之后两个缓冲的状态 STEP OUTPUT BUFFER INPUT BUFFER 1 a b c g 2E a b c g 2E a b c g 2E a b c g 2B a b c g 2C a b g 2C a g 2E a g STEP OUTPUT BUFFER INPUT BUFFER 1 mid content 5 6 2E mid content 5 6 2E mid content 5 6 2C mid 6 2E mid 6 一些应用可能发现通过使用两个片段栈而不是字符串来实现移除点片段算法更加高效 注意 当心一些旧的 错误的实现将无法在合并基础和引用路径之前从它的路径部件分离出引用的查询部件 如果该查询部件包含字符串 或 会导致互操作性失败 部件重写 已解析的URI部件可以被重写以获得相应的URI引用字符串 使用伪码 如下 result if defined scheme then append scheme to result append to result endif if defined authority then append to result append authority to result endif append path to result if defined query then append to result append query to result endif if defined fragment then append to result append fragment to result endif return result 注意我们要小心地保持一个未定义的部件和一个空部件之间的区别 未定义的部件 意味着在当前的引用中它的分隔符不是当前的 空部件 意味着该分隔符是当前的但是被下一个部件分隔符紧接跟在它后面或者在该引用的尾部 引用解析示例 对于有良好定义的基础URI的以下URI的陈述中 http a b c d p q 一个相对引用被转换成它的目标URI如下 常规示例 g h g h g http a b c g g http a b c g g http a b c g g http a g g http g y http a b c d p y g y http a b c g y s http a b c d p q s g s http a b c g s g y s http a b c g y s x http a b c x g x http a b c g x g x y s http a b c g x y s http a b c d p q http a b c http a b c http a b http a b g http a b g http a http a g http a g 反常示例 尽管以下反常示例未必发生在常规的实践中 所有URI解析器应该有能力一致性地解析它们 每个例子使用和上述相同的基础 比起在基础URI的路径中有多个层次 解析器必须更加小心地处理在一个相对路径引用中有多个 分段的情况 注意 语法不能被用于改变一个URI的机构部件 g http a g g http a g 类似的 解析器必须移除点片段 和 当它们是一个路径的完整部件的时候 但不是当它们是一个片段的仅有的部分的时候 g http a g g http a g g http a b c g g http a b c g g http a b c g g http a b c g 更罕见的情况是相对引用使用 和 的不必要或无意义的格式完成路径片段 g http a b g g http a b c g g h http a b c g h g h http a b c h g x 1 y http a b c g x 1 y g x 1 y http a b c y 一些应用在合并路径部件和基础路径并移除点片段之前未能从该路径部件分离出该引用的查询 和 或 片段部件 这个错误很少被注意到 因为一个片段的典型用法永远不会包含层次 符号并且查询部件通常不被用在相对引用中 g y x http a b c g y x g y x http a b c g y x g s x http a b c g s x g s x http a b c g s x 一些解析器允许格式名在相对引用中使用 如果它和基础URI格式相同 在之前的部分URI协议 RFC1630 http tools ietf org html rfc1630 中它被认为是一个漏洞 应该避免它的使用但是允许向后兼容 http g http g for strict parsers http a b c g for backward compatibility 正规化和比较 在URIs上最常见的操作之一是简单比较 在不使用URIs访问它们各自的资源的情况下确定两个URIs是否等价 每次一个应答缓存被访问的时候就执行比较动作 一个浏览器检查它的历史来给一个链接着色 或一个XML解析器处理一个命名空间中的标签 在比较URIs之前进行广泛的正规化经常被用于蜘蛛和索引引擎以精简搜索空间或减少重复的请求动作和应答存储 URI比较被执行用于一些特别的目的 为不同目的而比较URIs的协议或实现将经常受限于不同的设计去权衡应该花多少努力去减少别名标识符 这一章描述可以用于比较URIs的各种方法 它们之间的权衡 以及可以使用它们的应用的类型 等价 因为URIs存在识别资源 当它们标识到相同的资源想必它们应该认为它们是等价的 无论如何 等价的这一定义实际上没有用得那么多 因为对一个实现来说除非有它们的全部只是或控制没办法比较两个资源 基于这个原因 URIs的等价或不同的确定是基于字符串比较的 可能被URI格式定义提供的额外规则的引用所增强 我们使用术语 不同 和 等价 来描述这以比较的可能的结果 但是有很多依赖于应用的版本的等价 即使有可能确定两个URIs是等价的 URI比较不足以确定两个URIs是否标识不同的资源 例如 两个不同的域名的同一个所有者可能决定两者同时服务于相同的资源 导致两个不同的URIs 所以 比较方法被定义用来最小化错误的否定从而严格地避免错误的肯定 对于等价的测试 应用应该不直接比较相对引用 引用应该在比较之前被转换成它们各自的目标URIs 当URIs被比较以选择 或避免 一个网络动作 类似展示的获取 片段部件 如果有 应该从比较中排除 比较阶梯 实践中用来测试URI等价的方法有很多变种 这些方法落在一个范围里 需要多少过程来区分和哪种方法更能减少错误的否定 如上所述 错误的否定无法避免 实践中 它们的可能性能被减少 但是这个减少要求更多的处理并且不是对所有应用都合算的 如果比较实践的范围被看作一个阶梯 接下来的讨论将攀登这个阶梯 开始的实践是廉价但是有相对高的机会产生错误的否定 然后去到那些有更高计算成本和更低的错误否定风险的实践 简单字符串比较 如果两个URIs 当被认为是字符串 并且相同 那么断定它们等价是安全的 这类等价的测试的计算成本非常低并且广泛用于各种应用 特别是在解析域名中 测试字符串的等价性需要一些基本的注意事项 这个过程经常被称为 每比特 或 每字节 比较 它是潜在的误导 测试字符串的等价性通常是基于构成该字符串的字符对 从第一个开始一直到两个字符串结束且发现所有字符都等价 或直到一对字符比较不等价 或字符串之一在另一个之前结束 这一字符比较需要每一对字符是以可比较的格式存放的 例如 一个URI应该被存储成一个以EBCDIC编码的字节数组而第二个URI被存储成一个Java字符串对象 UTF 16 天真地应用每比特比较将产生错误 等价比较的更好的说法是基于每字符而不是每字节或每比特 实际上 每字符比较应该是在转换成通用字符编码之后的每码点比较 错误的否定是由URI别名的生产和使用造成的 无关比较方法 通过在一个已常规化的格式中一致性地提供URI引用 即 和应用常规化之后被生产的格式相同的一个格式 如下所述 可以减少不必要的别名 协议和数据格式经常限制了一些URI比较去简化字符串比较 基于这个理论人们和应用将出于他们自己的最佳利益 一致性地提供URI引用 或至少一致到足够否决任何从更多常规化中获得的效率 基于语法的常规化 实现可以使用基于本协议提供的定义的逻辑来降低错误否定的可能性 这个过程的开销适度地高于每字符的字符串比较 例如 一个使用这个方法的应用可能合理地认为以下两个URIs是等价的 example a b c 7Bfoo 7D eXAMPLE a b b 63 7bfoo 7d Web用户代理 类似浏览器 当决定是否一个缓存的应答可用的时候典型地应用这类URI常规化 基于语法的常规化包括这类技术 如案例常规化 百分号常规化 以及移除点片段 大写常规化 对于所有URIs来说 一个百分号编码的三连符中的十六进制数字 例如 3a 和 3A 是大小写不敏感的并且因此应该使用大写字母来常规化数字 A F 当一个URI使用通用语法部件 该部件语法语法等价规则总是适用 亦即 格式和主机是大小写不敏感的并且因此应该被常规化成小写 例如 URI HTTP www EXAMPLE com 等价于 http www example com 其他通用语法部件被假定是大小写敏感的 除非由格式特别定义 见 6 2 3 百分号编码常规化 百分号编码机制 2 1 在其他相同的URIs中是一个频繁出现的来源 除了上面注意到的大写常规化问题 一些百分号编码八位字节的URI生产者不必需百分号编码 结果是那些URIs等价于它们的未编码部分 这些URIs应该被解码任何百分号编码来常规化以对应一个非保留的字符 如 2 3 所述 路径片段常规化 完整的路径片段 和 只打算用在相对引用中 4 1 并且会作为引用解析过程的一部分被移除 5 2 无论如何 一些已部署的实现不正确地假定当引用已经是一个URI的时候引用解析是不必要的 使得当它们遇到非相对路径时未能移除点片段 URI常规化者应该通过应用 移除点片段 算法来从该路径移除点片段 如 5 2 4 所述 基于格式的常规化 各个格式的URIs的语法和语义是不同的 如每个格式的定义协议所述 实现可以使用格式特有的规则 以更高的处理成本 来减少错误否定的可能性 例如 因为一个用于授权部件的 http 格式 有一个缺省端口 80 并且定义了一个空路径等价于 以下四个URIs是等价的 http example com http example com http example com http example com 80 通常 一个使用通用语法来授权一个空路径的URI应该被常规化成一个路径 同样 一个显式的 port 这里这个端口号是空的或对该格式是缺省的 等价于该端口和它的 分隔符被省略了 从而应该被基于格式的常规化移除 例如 上述第二个URI对于 http 格式来说是常规格式 另一种由格式导致常规化的不同的情形是空的机构部件或空主机子部件的处理中 对于某些格式协议 一个空机构或主机被认为是一个错误 对于另一些格式协议 它被认为等价于 localhost 或最终用户的主机 当一个格式为机构定义了一个缺省值并且需要一个URI引用那个缺省值 为了保证一致性 简洁和国际化 那个引用应被常规化成一个空的机构 如果 无论如何 如果用户信息或端口子部件是非空的 那么主机应该被明确给出 即使它和缺省值是一样的 常规化应该不移除分割符 当它们的相关部件是空的时候 除非该格式协议允许这么做 例如 URI http example com 不能被假定等价于上述的任何例子 同样的 在一个用户信息子部件中分割符的出现与否常常是和它的解释有明显的关系 片段部件不受任何基于格式的常规化 于是 两个只是后缀 不同的URIs被认为是不同的 这和该格式无关 一些格式定义的额外的子部件包含了大小写不敏感的数据 把一个隐含的授权给了常规化者来把这个数据转换成一个常用大小写 例如 全部小写 例如 定义了一个路径子部件以包含一个互联网主机名的URI格式 类似 mailto URI格式 因为那个子部件是大小写不敏感的并且从而遵循大小写格式化 例如 mailto Joe Example COM 等价于 mailto Joe example com 即使通用语法认为路径部件是大小写敏感的 其他格式特有的常规化也是可能的 基于协议的常规化 降低错误否定的发生率的主要工夫常常对web蜘蛛是很合算的 所以 它们在URI比较上甚至实现了更具侵略性的技术 例如 如果它们观察到一个如下的URI http example com data 重定向到了一个只是多了一个尾随的斜杠的URI http example com data 它们或许将在未来把这两者视为等价 这种技术只是在等价同时清楚地被访问该资源的结果和它们的格式的解参考算法的通用惯例表示出来的时候才适合 在这个例子中 由HTPP源服务器使用的重定向避免了相对引用的问题 安全事项 URI本身不会产生安全性的威胁 然而 因为URIs经常被用于提供一系列指示用于访问网络资源 必须小心地适当解释一个URI中的数据 以防止那个数据被意外地访问 并且避免包含不应该在纯文本中出现的数据 可靠性和一致性 一个URI被用于取回信息 不保证将来同样的信息可以被那个URI取回 也不保证未来通过那个URI可取回的数据会和过去取回的数据明显类似 URI语法不约束一个给定的格式或机构如何分配它的命名空间或维护它的超时 这类保证只能来自控制那个问题中的命名空间和资源的人 们 一个特定的URI格式可以定义额外的语义 类似名字持久化 如果那些语义对于那个格式的所有命名机构都是必需的话 恶意构造 有时可能会有人构造一个URI来尝试执行一个貌似有害的幂等操作 例如取回一个表示 将实际导致一个可能有害的远程操作 不安全的URI典型地是通过指定一个和网络协议的保留端口不同的端口号来构造的 客户端不知不觉地联系了一个运行了不同协议服务的网站 以及该URI包含的数据的指示 当根据另一个协议解释的时候 导致意外的操作 一个常见的此类例子是对基于协议的格式因而带有的端口号 25 的滥用 从而欺骗用户代理软件通过一个SMTP服务器发送一个意想不到的或假冒的消息 应用应该防止一个URI的解参考指定一个 广为人知的端口范围 0 1023 中的TCP端口 除非用来解参考那个URI的协议和那个端口上预期的协议是兼容的 尽管IANA维护了一个已知端口号的注册表 应用应该让这些约束成为用户可配置的以避免妨碍新服务的部署 当一个URI包含的百分号八位字节和用于给定的解释或解参考协议的分隔符匹配 例如 用于TELNET协议的 CR 和 LF 符号 在传输穿过那个协议之前这些百分号编码不能被解码 百分号编码的传输 它可能违反协议 的伤害可能低于允许被解码的八位字节被解释成额外的操作或参数 可能触发一个意外和可能有害的远程操作 后端转码 当一个URI被解参考 它里面的数据经常同时被用户代理和一个或多个服务器解析 在HTTP中 例如 一个典型的用户代理把一个URI解析成它的五个主要的部件 访问机构的服务器 并向它发送机构 路径和查询部件中的数据 一个典型的服务器将获得那些信息 把路径解析成片段并查询 键 值 对 然后调用实现特有的处理程序以应答该请求 结果是 对于处理一个作为整体或分离成独立部件的URI的服务器实现来说 一个常见的安全问题是 它是对那个URI中的字符串和百分号编码展示的八位字节数据的适当的解释 百分号字节在解参考过程中必须在某些点被解码 应用必须在解码这些字节之前把URI分离成它的部件和子部件 否则被解码的字节可能被误解为分隔符 在一个URI中的数据的安全性检查应该在字节被解码之后应用 记住 无论如何 00 百分号 空 可能要求特殊的处理并且如果应用不期望在一个部件里接收原数据则应该被拒绝 当URI路径解释过程包含了对后端文件系统或相关的系统功能的使用的时候应特别小心 文件系统典型地把一个可操作的含义赋予给特定的字符 例如 和 字符 以及特别的设备名类似 aux lpt 等等 在某些情况下 对这类名称的存在很少测试将导致操作系统暂停或请求和系统无关的调用 导致明显的拒绝服务和意外的数据传输的安全问题 有可能的话本协议将列出所有这类重要字符和设备名称 实现应该研究为可能被挂载到它们的应用的存储类型保留名称和字符并从而限制从URI部件获得的数据中使用它们 罕见的IP地址格式 尽管用于IPv4address的URI语法只允许常见的IPv4地址文字的 点 十进制 格式 很多处理URIs的实现使用了独立于平台的系统函数 例如 gethostbyname 和 inet aton 来把字符文字翻译成一个确切的IP地址 不幸的是 这类系统函数经常允许和处理比 3 2 2 中描述的格式更大的集合 例如 很多实现允许三个数字的点格式 其最后部分被解释为一个16比特的数量并被放到网络地址的最右边的两个字节 例如 一个B类网络 同样的 两个数字的点格式意味着最后部分被解释为一个24比特的数量并被放到地址的最右边的三个字节 A类 而一个单独的数字 没有点 被解释为一个32比特的数量并被直接存到网络地址 更多的混乱是 一些实现允许每个点部分被解释为十进制 八进制 或十六进制 特别是在C语言中 即 一个打头的 0x 或 0X 暗示一个十六进制 一个打头的 0 暗示八进制 否则 该数字被解释为十进制 在URi语法中不允许额外的IP地址格式是因为平台实现之间的不同 无论如何 如果一个应用尝试基于字符文本格式的IP地址过滤到资源的访问 它们可能成为一个安全问题 如果这个过滤被执行了 文字应该被转换成数字格式并基于数字值过滤 不要基于一个字符格式的前缀或后缀 敏感信息 URI制作者应该不提供包含了了通常保密的用户名和密码的URI URIs经常由浏览器显示 被存储成纯文本书签 并且被用户代理历史和中介应用 代理 记录了日志 在用户信息部件中包含密码是被反对的并且应该被视为一个错误 或简单地忽略 除非在那些罕见的情况下 password 参数才会公开出现 语义攻击 因为在机构部件中用户信息子部件在主机之前很少被使用和出现 它可能被用于构造一个URI来误导一个自然人用户 看似标识一个 可信的 命名机构 实际上标识一个隐藏在噪音后面的不同的机构 例如 ftp cnn example com story breaking news 10 0 0 1 top story htm 可能引导一个自然人用户假定该主机为 cnn example com 而它实际上是 10 0 0 1 注意一个误导的用户信息子部件可能比上述的例子更长 一个误导的URI 类似上面那个 是对用户对于一个URI的含义的先入为主的概念的攻击而不是对对该软件本身的攻击 用户代理可能可以通过在呈现该URI的多个部件的时候区别开它们来减少这类攻击的影响 例如通过使用不同的颜色或声音来呈现用户信息 如果有的话 尽管没有灵丹妙药 更多关于基于URI的语义的攻击可以在 Siedzik 找到 IANA事项 URI格式名称 在 Scheme 3 1 中的 scheme 定义 格式化一个根据 BCP35 定义的流程由IANA管理的已注册的命名空间 本文不需要任何IANA操作 致谢 本协议来源于 RFC 2396 RFC 1808 和 RFC 1738 那些文档中的致谢在本文仍然适用 本协议也合并了主机语法中的IPv6文字的更新 及修正 如 Robert M Hinden Brian E Carpenter 和 Larry Masinter 在 RFC2732 中定义的那样 另外 非常感谢下列人员的贡献 Gisle Aas Reese Anschultz Daniel Barclay Tim Bray Mike Brown Rob Cameron Jeremy Carroll Dan Connolly Adam M Costello John Cowan Jason Diamond Martin Duerst Stefan Eissing Clive D W Feather Al Gilman Tony Hammond Elliotte Harold Pat Hayes Henry Holtzman Ian B Jacobs Michael Kay John C Klensin Graham Klyne Dan Kohn Bruce Lilly Andrew Main Dave McAlpin Ira McDonald Michael Mealling Ray Merkert Stephen Pollei Julian Reschke Tomas Rokicki Miles Sabin Kai Schaetzl Mark Thomson Ronald Tschalaer Norm Walsh Marc Warne Stuart Williams 和 Henry Zongaro 参考 规范引用 ASCII American National Standards Institute Coded Character Set 7 bit American Standard Code for Information Interchange ANSI X3 4 1986 RFC2234 Crocker D and P Overell Augmented BNF for Syntax Specifications ABNF RFC 2234 November 1997 STD63 Yergeau F UTF 8 a transformation format of ISO 10646 STD 63 RFC 3629 November 2003 UCS International Organization for Standardization Information Technology Universal Multiple Octet Coded Character Set UCS ISO IEC 10646 2003 December 2003 参考文献 BCP19 Freed N and J Postel IANA Charset Registration Procedures BCP 19 RFC 2978 October 2000 BCP35 Petke R and I King Registration Procedures for URL Scheme Names BCP 35 RFC 2717 November 1999 RFC0952 Harrenstien K Stahl M and E Feinler DoD Internet host table specification RFC 952 October 1985 RFC1034 Mockapetris P Domain names concepts and facilities STD 13 RFC 1034 November 1987 RFC1123 Braden R Requirements for Internet Hosts Application and Support STD 3 RFC 1123 October 1989 RFC1535 Gavron E A Security Problem and Proposed Correction With Widely Deployed DNS Software RFC 1535 October 1993 RFC1630 Berners Lee T Universal Resource Identifiers in WWW A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World Wide Web RFC 1630 June 1994 RFC1736 Kunze J Functional Recommendations for Internet Resource Locators RFC 1736 February 1995 RFC1737 Sollins K and L Masinter Functional Requirements for Uniform Resource Names RFC 1737 December 1994 RFC1738 Berners Lee T Masinter L and M McCahill Uniform Resource Locators URL RFC 1738 December 1994 RFC1808 Fielding R Relative Uniform Resource Locators RFC 1808 June 1995 RFC2046 Freed N and N Borenstein Multipurpose Internet Mail Extensions MIME Part Two Media Types RFC 2046 November 1996 RFC2141 Moats R URN Syntax RFC 2141 May 1997 RFC2396 Berners Lee T Fielding R and L Masinter Uniform Resource Identifiers URI Generic Syntax RFC 2396 August 1998 RFC2518 Goland Y Whitehead E Faizi A Carter S and D Jensen HTTP Extensions for Distributed Authoring WEBDAV RFC 2518 February 1999 RFC2557 Palme J Hopmann A and N Shelness MIME Encapsulation of Aggregate Documents such as HTML MHTML RFC 2557 March 1999 RFC2718 Masinter L Alvestrand H Zigmond D and R Petke Guidelines for new URL Schemes RFC 2718 November 1999 RFC2732 Hinden R Carpenter B and L Masinter Format for Literal IPv6 Addresses in URL s RFC 2732 December 1999 RFC3305 Mealling M and R Denenberg Report from the Joint W3C IETF URI Planning Interest Group Uniform Resource Identifiers URIs URLs and Uniform Resource Names URNs Clarifications and Recommendations RFC 3305 August 2002 RFC3490 Faltstrom P Hoffman P and A Costello Internationalizing Domain Names in Applications IDNA RFC 3490 March 2003 RFC3513 Hinden R and S Deering Internet Protocol Version 6 IPv6 Addressing Architecture RFC 3513 April 2003 Siedzik Siedzik R Semantic Attacks What s in a URL April 2001 http www giac org practical gsec Richard Siedzik GSEC pdf 附录A 为URI收集的ABNF URI scheme hier part query fragment hier part authority path abempty path absolute path rootless path empty URI reference URI relative ref absolute URI scheme hier part query relative ref relative part query fragment relative part authority path abempty path absolute path noscheme path empty scheme ALPHA ALPHA DIGIT authority userinfo host port userinfo unreserved pct encoded sub delims host IP literal IPv4address reg name port DIGIT IP literal IPv6address IPvFuture IPvFuture v 1 HEXDIG 1 unreserved sub delims IPv6address 6 h16 ls32 5 h16 ls32 h16 4 h16 ls32 1 h16 h16 3 h16 ls32 2 h16 h16 2 h16 ls32 3 h16 h16 h16 ls32 4 h16 h16 ls32 5 h16 h16 h16 6 h16 h16 h16 1 4HEXDIG ls32 h16 h16 IPv4address IPv4address dec octet dec octet dec octet dec octet dec octet DIGIT 0 9 x31 39 DIGIT 10 99 1 2DIGIT 100 199 2 x30 34 DIGIT 200 249 25 x30 35 250 255 reg name unreserved pct encoded sub delims path path abempty begins with or is empty path absolute begins with but not path noscheme begins with a non colon segment path rootless begins with a segment path empty zero characters path abempty segment path absolute segment nz segment path noscheme segment nz nc segment path rootless segment nz segment path empty 0 pchar segment pchar segment nz 1 pchar segment nz nc 1 unreserved pct

    Original URL path: http://wiki.jabbercn.org/index.php?title=RFC3986&oldid=3568 (2016-04-25)
    Open archived version from archive


  • 查看源代码 - Jabber/XMPP中文翻译计划
    h16 ls32 h16 h16 IPv4address least significant 32 bits of address h16 1 4HEXDIG 16 bits of address represented in hexadecimal source 一个由IPv4文字地址标识的主机被展现为点分十进制表示法 一系列四个范围为0到255的十进制数字 以 分隔 如 http tools ietf org html rfc1123 RFC1123 所述 参考 http tools ietf org html rfc0952 RFC0952 注意点符号的其他格式可以在一些平台上被解释执行 如 RFC3986 罕见IP地址格式 7 4 所述 但本语法只允许四个八位字节的点分十进制格式 source lang text IPv4address dec octet dec octet dec octet dec octet dec octet DIGIT 0 9 x31 39 DIGIT 10 99 1 2DIGIT 100 199 2 x30 34 DIGIT 200 249 25 x30 35 250 255 source 一个被注册名标识的主机是一系列字符 常常要用它在一个本地定义的主机或服务名称注册表中来查找 尽管该URI的格式特有的语义可以要求替换成一个特有的注册表 或固定的名称表 大部分常用名称注册表机制是域名系统 DNS 在DNS中查询到一个注册名要使用 http tools ietf org html rfc1034 section 3 5 RFC1034的3 5节 和 http tools ietf org html rfc1123 section 2 1 RFC1123的2 1节 中定义的语法 这样一个名称包含了一系列以 分隔的域标签 每个域标签以一个文字数字字符开始和结束 也可能包含 字符 一个在DNS中完全合格的域名的最右边的域标签可以在后面带一个单独的 并且如果有必要把完整域名和一些本地域名去分开的话则必须带它 source lang text reg name unreserved pct encoded sub delims source 如果URI格式为主机定义了一个缺省值 那么当该主机子部件未定义或当注册名称为空 零长度 的时候那个缺省值适用 例如 file URI格式被定义成没有机构 空主机 且 localhost 全都代表最终用户的机器 反之一个缺少机构或空主机的 http 格式被认为是非法的 本协议不强制一个特定的注册名称查询技术并且因而如果不在互操作性的必要情况之上约束reg name语法 反之 它把注册名称语法一致性问题委托给每个执行URI解析的应用的操作系统 并且那个and操作系统来决定允许使用哪种技术来确定主机身份 一个URI解析实现可能使用DNS 主机表 黄页 NetInfo WINS 或任何其他系统来查询注册名称 然而 一个全局范围的命名系统 类似DNS完全合格的域名 对打算全局范围使用的URIs是必要的 URI制作者应该按照DNS语法使用名称 即使当DNS的使用不会立刻被看到的时候 并且应该限制这些名称的长度不超过255个字符 reg name语法允许百分号编码字节 这是为了以一个独立于基本的名称解析技术的统一的方法来展现非ASCII注册名称 非ASCII字符必须首先被根据UTF 8 http tools ietf org html rfc3986 ref STD63 STD63 编码 并且接着每个UTF 8序列相应的八位字节必须被百分号编码以展现成URI字符 URI制作应用不能对主机使用百分号编码 除非它被用于展示一个UTF 8字符序列 当一个非ASCII注册名称展现了一个打算通过DNS解析的国际化域名 该名称必须在名称查询之前被转换成IDNA编码 http tools ietf org html rfc3490 RFC3490 URI制作者应该以IDNA编码提供这些注册名称 而不是一个百分号编码 如果他们希望最大化和外部URI解析者的互操作能力 端口 机构的端口子部件由一个可选的跟随在主机后面并且从单个的冒号 字符之后开始的十进制端口号来指定 source lang text port DIGIT source 一个格式可以定义一个缺省端口 例如 http 格式定义了一个缺省端口 80 和它的保留TCP端口号码一致 由端口号指定的端口的类型 例如 TCP UDP SCTP 是由该URI格式定义的 URI制作者和正规化者应该省略端口部件和它的 边界 如果端口是空的或它的值和该格式的缺省值相同的话 路径 路径部件包含数据 常常组织成层次格式 它连同非层次化的查询部件 RFC3986 查询 3 4 的数据 服务于识别在该URI的格式和命名机构 如果有 范围内的一个资源 路径由第一个问号 或数字符号 字符或该URI的结尾来终止 如果一个URI包含一个机构部件 那么该路径部件必须要么是空的要么以一个斜杠 字符开始 如果一个URI不包含一个机构部件 那么路径不能以双斜杠字符 开始 此外 一个URI引用 RFC3986 URI引用 4 1 可以是一个和路径相关的引用 在那种情况下第一个路径片段不能包含一个冒号 字符 ABNF要求五个独立的规则来消除这些情况的歧义 只有其中一种情况将会在一个给定的URI引用中和该路径子字符串匹配 我们使用通用术语 路径部件 来描述由这些规则的解析器匹配的该URI子字符串 source lang text path path abempty begins with or is empty path absolute begins with but not path noscheme begins with a non colon segment path rootless begins with a segment path empty zero characters path abempty segment path absolute segment nz segment path noscheme segment nz nc segment path rootless segment nz segment path empty 0 pchar segment pchar segment nz 1 pchar segment nz nc 1 unreserved pct encoded sub delims non zero length segment without any colon pchar unreserved pct encoded sub delims source 一个路径包含一系列由斜杠 字符分隔的路径片段 对于一个URI来说总是会定义一个路径 尽管定义的路径可能是空 零长度 指示层次用的斜杠字符之在一个URI用作指示相对引用的时候是必需的 例如 URI mailto fred example com 有一个路径 fred example com 反之 URI foo info example com fred 有一个空路径 路径片段 和 也就是点片段 被定义用于路径名称层次的相对引用 它们被用于相对路径引用的开始 http tools ietf org html rfc3986 section 4 2 RFCSection 4 2 以指示名称的层次树中的相对位置 这和某些操作系统的文件目录结构分别指示当前目录和父目录的它们的角色类似 无论如何 和在一个文件系统中不一样 这些点片段只在URI层次中被这样理解并且被从解析过程的一部分中移除 RFC3986 相对解析 5 2 除了层次路径中的点片段之外 一个路径片段被通用语法当成不透明的 URI制作应用经常在一个片段中使用保留字符以界定格式特有的或解参考处理者特有的子部件 例如 分号 和等号 保留字符经常被用于界定适用于那个片段的参数和参数值 逗号 保留字符经常被用于类似的目的 例如 一个URI制作者可以使用一个类似 name v 1 1 的片段来指示一个对 name 的1 1版的引用 反之另一个可能使用类似 name 1 1 的片段来指示相同的东西 参数类型可以由格式特有的语义来定义 但是在大多数情况下一个参数的语法对该URI的解参考算法的实现来说是特有的 查询 查询部件包含非层次化的数据 以及路径部件中的数据 RFC3986 路径 3 3 用来从该URI的格式和命名机构 如果有 中识别一个资源 查询部件由第一个问号 字符指示并由一个数字符号 字符或该URI的结尾终止 source lang text query pchar source 字符斜杠 和问号 可以展现该查询部件内的数据 注意当它被用于相对引用的基础URI的时候 RFC3986 建立基础URI 5 1 一些旧的 错误的实现可能没有正确处理这类数据 显然是因为它们在查找层次分隔符的时候未能把查询部件从路径数据中区分开来 无论如何 因为查询部件经常被用于以 键 值 对的格式携带识别信息并且一个常被使用的值是对另一个URI的引用 它经常比百分号编码那些字符有更好的可用性 片段 一个URI的片段标识符部件允许对一个主要资源引用的次要资源的非直接身份认证以及额外的识别信息 被识别的次要资源可以是该主要资源的一部分或子集 或一些由那些陈述所定义或描述的资源 一个片段标识符部件是通过一个数字符号 字符的出现来指示的并由该URI的结尾来终止 source lang text fragment pchar source 一个片段标识符的语义可以是由一组从主要资源的获取动作导致的表现来定义的 所以片段的格式和解析依赖于一个潜在的获取展现的媒体类型 http tools ietf org html rfc2046 RFC2046 即使这样一个获取只在URI被解参考的时候执行 如果没有这类体现存在 那么该片段的语义被认为是未知的并且是有效的无限制 片段标识符语义独立于URI格式并且因而不能被格式协议重新定义 单独的媒体类型可以在片段标识符语法内定义它们自己的约束或结构用于指定不同类型的子集 视图或对那个媒体类型可识别的次要资源的外部引用 如果主要资源有多个展现 这中情况常常是资源的展现是该获取请求的属性的可选的基础 又名 内容协商 那么无论该片段识别的什么都应该和那些展现一致 每个展现应该要么定义片段这样它对应相同的次要资源 无论它是如何展现的 要么应该让该片段未定义 即 未找到 对任何URI 片段标识符部件的使用不代表将执行一个获取动作 一个带了片段标识符的URI可被用于指向次要资源而不代表任何主要资源是可访问的或永远无法访问 片段标识符在信息获取系统中有一个特别的作用是作为客户端间接引用的主要格式 允许一个作者特别地识别一个现有的只由该资源所有者间接提供的资源的样子 同样 片段标识符不被用于一个URI的格式特有的处理 反之 在解参考之前片段标识符被从URI的其他部分分离出来 因而该片段本身的识别信息的解参考由用户代理执行 和该URI格式无关 尽管这个独立的处理经常被认为缺少信息 特别是当引用随时间移动的时候引用的准确重定向 它也用于防止信息提供者禁止引用作者在一个可选的资源中引用信息 间接引用也为系统使用URIs提供额外的可伸缩性和可扩展性 因为定义和部署新媒体类型比新身份格式更容易 斜杠 和问号 被允许在片段标识符内展示数据 注意一些旧的 错误的实现可能未正确处理这个数据 当它被用作相对引用的基础URI的时候 RFC3986 建立基础URI 5 1 用法 当应用引用一个URI的时候 它们不总是使用该 URI 语法规则定义的引用的完整格式 为了节省空间和方便层次化区域 一些互联网协议元素和媒体类型格式允许一个URI的缩写 反之其他则把语法限制到URI的某个特定格式 我们在本文定义引用语法的最常见格式 因为它们影响和以来通用语法的设计 为了解释的一致性而要求一个通用解析算法 URI引用 URI引用常常代表一个资源标识符的最常见的用法 source lang text URI reference URI relative ref source 一个URI引用要么是一个URI要么是一个相对引用 如果该URI引用的前缀和跟随在它的冒号后面的格式的语法不匹配 那么该URI引用是一个相对引用 一个URI引用典型地首先被解析成5个URI部件 以确定什么组件是当前的以及该引用是否是相对的 接着 每个部件被解析为子部件和它们的校验 URI引用的ABNF 遵循 先匹配者赢 的消除歧义规则 足够为通用语法定义一个校验解析器 对正则表达式熟悉的读者们应该去看 RFC3986 用正则表达式解析URI引用 附录B 的一个非校验的URI引用解析器的例子 它将使用任何给定的字符串并提取该URI部件 相对引用 一个相对引用可以方便地用层次化语法 RFC3986 层次标识符 1 2 3 表达和另一个层次化URI的命名空间相关的一个URI引用 source lang text relative ref relative part query fragment relative part authority path abempty path absolute path noscheme path empty source 由一个相对引用所指向的URI 也被认为是目标URI 通过应用 RFC3986 引用解析 第5章 的引用解析算法来获得 一个开始于两个斜杠字符的相对引用被称为一个网络路径引用 这类引用很少被使用 一个开始于单个斜杠字符的相对引用被称为一个绝对路径引用 一个不以斜杠字符开始的相对引用被称为一个相对路径引用 一个包含一个冒号字符的路径段落 例如 this that 不能被用作一个相对路径引用的第一个段落 因为它会被误认为一个格式名称 这样一个段落必须在它前面放一个点段落 例如 this that 以制作一个相对路径引用 绝对URI 一些协议元素仅被一个不带片段标识符的URI的绝对格式允许 例如 定义一个符合不允许片段的绝对URI语法规则的基础URI用于晚些时候供相对引用调用 source lang xml absolute URI scheme hier part query source URI格式协议必须定义它们自己的语法 这样所有和它们的格式特有的语法匹配的字符也将和 绝对URI 语法匹配 格式协议将不定义片段标识符语法或用法 不管它对来自那个格式的资源标识符的适用性如何 因为片段标识符直交于格式定义 无论如何 鼓励格式协议包含大范围的示例 包括展示携带了片段标识符的格式的URI如何使用 当这类用法是恰当的时候 同文引用 当一个URI引用指向这样一个URI 除了它的片段部件以外 如果有的话 和基础URI RFC3986 建立基础URI 5 1 完全一样 那个引用被称为一个 同文 引用 同文引用的最常用的例子是空的或只包含一个后面跟随着片段标识符的数字标记 分隔符的相对引用 当一个同文引用为了一个获取动作而被解参考 那个引用的目标被定义成在该引用的同一个实体 展示 文档 或消息 中 所以 一个解参考不应改导致一个新的获取动作 在基础的和目标的URIs的比较之前进行正规化 如 RFC3986 基于语法的正规化 6 2 2 和 RFC3986 基于格式的正规化 6 2 3 所述 是被允许的 但是实践中很少被执行 正规化可以增加同文引用集合 这有利于某些缓存引用 同样 引用作者不应该假定那是轻微的不同 甚至等价 引用URI将 或将不 被任何给定应用理解为一个同文引用 后缀引用 URI语法是为通过URI格式明确地引用资源和可扩展性而定义的 然而 因为URI识别和用法以及普及了 传统媒体 电视 广播 报纸 公告牌 等等 已经越来越多地使用一个URI的后缀来作为一个引用 只包含URI的机构和路径部分 类似 source lang xml www w3 org Addressing source 或简单的一个它自己的DNS注册名称 这类引用主要是为了自然人而不是机器理解 同时假定基于上下文的启发对完成该URI是足够的 例如 大部分以 www 开始的注册名似乎有一个URI前缀 http 尽管没有对一个URI后缀消除歧义的启发的标准集合 一些客户端实现云讯它们由用户输入并且启发式地理解 尽管使用后缀引用在实践中很常见 应该避免任何的可能并且应该永远不在被期望长期使用的引用的情况下使用 上面提到的启发将随事件改变 特别是当一个新的URI格式流行的时候 并且当超出上下文使用的时候经常是不正确的 进一步的 按照 http tools ietf org html rfc1535 RFC1535 的那些描述 它们能导致安全性问题 因为一个URI后缀和一个相对路径引用有相同的语法 一个后缀引用不能被用于被期望使用相对引用的上下文中 结果是 后缀引用被限制于没有定义基础URI的地方 类似对话框和离线广告 引用解析 本章定义解析一个允许相对引用的上下文中的URI引用的过程 结果是一个和 RFC3986 语法部件 第3章 的 URI 语法规则匹配的字符串 建立基础URI 术语 相对 暗示存在一个应用于相对引用的 基础URI 除了仅片段引用 RFC3986 同文引用 4 4 相对引用只在已知一个基础URI的时候有用 一个基础URI必须在解析可能被引用的URI之前由解析器建立 一个基础URI必须遵循 absolute URI 语法规则 RFC3986 绝对URI 4 3 如果该基础是从一个URI引用URI获得的 那么该引用必须在它被用作一个基础URI之前被转化成绝对格式并剥离任何片段部件 一个引用的基础URI可以以四种方法之一来建立 在下面按优先级逐一讨论 优先级的顺序以术语的层级来考虑 被定义得最靠近基础URI的就是最高优先级 图形化显示如下 source lang text relative reference 5 1 1 Base URI embedded in content 5 1 2 Base URI of the encapsulating entity message representation or none 5 1 3 URI used to retrieve the entity 5 1 4 Default Base URI application dependent source 嵌入在内容里的基础URI 在特定的媒体类型中 一个用于相对引用的基础URI可能被封装在内容本身之中 这它能很容易地被一个解析器获得 这对于描述性文档是很有用的 类似内容表格等 它可以通过协议被转换成其他东西而不是它们常常被获取的时候的上下文 例如 email 或 USENET 新闻 指定一个基础URI如何被每个媒体类型嵌入超出了本协议的范围 当有适当的语法可用的时候 它由和每个媒体类型相关的数据格式协议来描述 来自封装实体的基础URI 如果没有基础URI被封装 则该基础URI由展示的获取上下文来定义 对一个封闭在另一个实体中的文档来说 这样一个消息或存档 获取上下文就是那个实体 所以 一个展示的缺省基础URI就是把展现封装在其中的那个实体的基础URI 在一个MIME容器类型 例如 消息和多部件类型 中封装一个基础URI的机制由MHTML http tools ietf org html rfc2557 RFC2557 定义 协议不使用MIME消息头语法 但是的确允许某些标记元数据的格式被包含在消息中 可能为了定义一个基础URI成为一个消息的一部分来定义它们自己的语法 来自检索URI的基础URI 如果没有内嵌的基础URI并且表现未封装到一些其他实体中 那么 如果一个URI被用来获取表现 那个URI将被认为是基础URI 注意如果获取动作是一个重定向请求导致的 最后被使用URI 即 导致实际的获取表现的动作的URI 是基础URI 缺省基础URI 如果没有适用以上描述的条件 那么基础URI由应用的上下文定义 因为这个定义需要依赖应用 如果使用其他方法之一未能定义基础URI可能导致同样的内容在不同类型的应用中有不同的解释 一个包含相对引用的表现的发送者要负责确保那些应用的一个基础URI能被建立 除了仅片段的引用 相对引用只能被用于基础URI被良好定义的可靠情形之下 相对解析 本章描述了把一个和给定基础URI相关的URI引用转换成引用目标的已解析部件的算法 然后该部件被重写成目标URI的格式 如 RFC3986 部件重写 5 3 所述 这个算法提供最后的结果 能被用于测试其他实现的输出 应用可以使用某些其他算法来实现相对引用解析 提供的结果将和本算法的结果吻合 预解析基础URI 基础URI Base 是根据 RFC3986 建立基础URI 5 1 的步骤建立的并被解析成 RFC3986 语法部件 3 描述的五个主要的部件 注意在一个基础URI中只有格式部件是必需的 其他部件可以是空的或未定义的 如果一个部件的相关分割符未出现在该URI引用之中那么该部件是未定义的 路径部件永远不会是未定义的 虽然它可以是空的 基础URI的正规化 如 RFC3986 基于语法的正规化 6 2 2 和 RFC3986 基于格式的正规化 6 2 3 所述 是可选的 一个URI引用必须在它能被正规化之前被转换成它的目标URI 转换引用 对每个URI引用 R 来说 以下伪码描述了一个把R转换成它的目标URI T 的算法 source lang java URI引用被解析成5个URI部件 R scheme R authority R path R query R fragment parse R 一个非约束的解析器可以忽略引用中的格式 如果该引用和基础URI的格式是相同的 if not strict and R scheme Base scheme then undefine R scheme endif if defined R scheme then T scheme R scheme T authority R authority T path remove dot segments R path T query R query else if defined R authority then T authority R authority T path remove dot segments R path T query R query else if R path then T path Base path if defined R query then T query R query else T query Base query endif else if R path starts with then T path remove dot segments R path else T path merge Base path R path T path remove dot segments T path endif T query R query endif T authority Base authority endif T scheme Base scheme endif T fragment R fragment source 合并路径 上面的伪码适用于一个 合并 程序 用于合并相对路径引用和基础URI路径 它是如下完成的 如果基础URI有一个已定义的机构部件和一个空路径 则返回一个包含和引用路径一起的 的字符串 否则 返回一个字符串 包含该引用的路径部件加上除了该基础URI的路径的最后一个片段的所有其他片段 即 除基础URI路径最右边的 后面的任何符号 或除了完整的基础URI路径 如果该基础URI不包含任何 符号 移除点片段 该伪码也适用于一个 移除点片段 程序 用于从一个被引用路径解释和移除特定的 and 完整路径片段 这要在该路径被从一个引用提取出来之后来做 无论该路径是否相对的 目的是在格式化目标URI之前移除任何非法或无关的点片段 尽管有很多方法可以完成这个移除过程 我们描述一个使用两个字符串缓冲的简单方法 1 输入缓冲以刚加上的路径部件初始化 而输出缓冲被初始化成空字符串 2 当输入缓冲是空的时候 按以下回路 A 如果输入缓冲以前缀 或 开始 那么从输入缓冲移除该前缀 否则 B 如果输入缓冲以前缀 或 开始 这里 是一个完整的路径片段 那么在输入缓冲中把那个前缀替换成 否则 C 如果输入缓冲以前缀 或 开始 这里 是一个完整路径片段 那么在输入缓冲中把该前缀替换成 并从输出缓冲中移除最后的片段以及它前面的 如果有的话 否则 D 如果输入缓冲仅包含 或 那么从输入缓冲移除它 否则 E 在输入缓冲中把第一个路径片段移动到输出缓冲的尾部 包括初始的 符号 如果有的话 和任何随后的符号 但不包括下一个 符号或输入缓冲的结尾 3 最后 输出缓冲被返回一个 移除了点片段 的结果 注意点片段的目的是在URI引用中用于在基础URI中表达一个和名称的层次相对的标识符 移除点片段 算法通过移除额外的点片段来尊重层次而不是把它们当成一个错误或留着它们去被解参考实现误解 接下来演示上述步骤如何应用于合并路径的两个例子 展示每个步骤之后两个缓冲的状态 source lang text STEP OUTPUT BUFFER INPUT BUFFER 1 a b c g 2E a b c g 2E a b c g 2E a b c g 2B a b c g 2C a b g 2C a g 2E a g STEP OUTPUT BUFFER INPUT BUFFER 1 mid content 5 6 2E mid content 5 6 2E mid content 5 6 2C mid 6 2E mid 6 source 一些应用可能发现通过使用两个片段栈而不是字符串来实现移除点片段算法更加高效 注意 当心一些旧的 错误的实现将无法在合并基础和引用路径之前从它的路径部件分离出引用的查询部件 如果该查询部件包含字符串 或 会导致互操作性失败 部件重写 已解析的URI部件可以被重写以获得相应的URI引用字符串 使用伪码 如下 source lang pascal result if defined scheme then append scheme to result append to result endif if defined authority then append to result append authority to result endif append path to result if defined query then append to result append query to result endif if defined fragment then append to result append fragment to result endif return result source 注意我们要小心地保持一个未定义的部件和一个空部件之间的区别 未定义的部件 意味着在当前的引用中它的分隔符不是当前的 空部件 意味着该分隔符是当前的但是被下一个部件分隔符紧接跟在它后面或者在该引用的尾部 引用解析示例 对于有良好定义的基础URI的以下URI的陈述中 http a b c d p q 一个相对引用被转换成它的目标URI如下 常规示例 source lang html4strict g h g h g http a b c g g http a b c g g http a b c g g http a g g http g y http a b c d p y g y http a b c g y s http a b c d p q s g s http a b c g s g y s http a b c g y s x http a b c x g x http a b c g x g x y s http a b c g x y s http a b c d p q http a b c http a b c http a b http a b g http a b g http a http a g http a g source 反常示例 尽管以下反常示例未必发生在常规的实践中 所有URI解析器应该有能力一致性地解析它们 每个例子使用和上述相同的基础 比起在基础URI的路径中有多个层次 解析器必须更加小心地处理在一个相对路径引用中有多个 分段的情况 注意 语法不能被用于改变一个URI的机构部件 source lang html4strict g http a g g http a g source 类似的 解析器必须移除点片段 和 当它们是一个路径的完整部件的时候 但不是当它们是一个片段的仅有的部分的时候 source lang html4strict g http a g g http a g g http a b c g g http a b c g g http a b c g g http a b c g source 更罕见的情况是相对引用使用 和 的不必要或无意义的格式完成路径片段 source lang html4strict g http a b g g http a b c g g h http a b c g h g h http a b c h g x 1 y http a b c g x 1 y g x 1 y http a b c y source 一些应用在合并路径部件和基础路径并移除点片段之前未能从该路径部件分离出该引用的查询 和 或 片段部件 这个错误很少被注意到 因为一个片段的典型用法永远不会包含层次 符号并且查询部件通常不被用在相对引用中 source lang html4strict g y x http a b c g y x g y x http a b c g y x g s x http a b c g s x g s x http a b c g s x source 一些解析器允许格式名在相对引用中使用 如果它和基础URI格式相同 在之前的部分URI协议 RFC1630 http tools ietf org html rfc1630 中它被认为是一个漏洞 应该避免它的使用但是允许向后兼容 source lang html4strict http g http g for strict parsers http a b c g for backward compatibility source 正规化和比较 在URIs上最常见的操作之一是简单比较 在不使用URIs访问它们各自的资源的情况下确定两个URIs是否等价 每次一个应答缓存被访问的时候就执行比较动作 一个浏览器检查它的历史来给一个链接着色 或一个XML解析器处理一个命名空间中的标签 在比较URIs之前进行广泛的正规化经常被用于蜘蛛和索引引擎以精简搜索空间或减少重复的请求动作和应答存储 URI比较被执行用于一些特别的目的 为不同目的而比较URIs的协议或实现将经常受限于不同的设计去权衡应该花多少努力去减少别名标识符 这一章描述可以用于比较URIs的各种方法 它们之间的权衡 以及可以使用它们的应用的类型 等价 因为URIs存在识别资源 当它们标识到相同的资源想必它们应该认为它们是等价的 无论如何 等价的这一定义实际上没有用得那么多 因为对一个实现来说除非有它们的全部只是或控制没办法比较两个资源 基于这个原因 URIs的等价或不同的确定是基于字符串比较的 可能被URI格式定义提供的额外规则的引用所增强 我们使用术语 不同 和 等价 来描述这以比较的可能的结果 但是有很多依赖于应用的版本的等价 即使有可能确定两个URIs是等价的 URI比较不足以确定两个URIs是否标识不同的资源 例如 两个不同的域名的同一个所有者可能决定两者同时服务于相同的资源 导致两个不同的URIs 所以 比较方法被定义用来最小化错误的否定从而严格地避免错误的肯定 对于等价的测试 应用应该不直接比较相对引用 引用应该在比较之前被转换成它们各自的目标URIs 当URIs被比较以选择 或避免 一个网络动作 类似展示的获取 片段部件 如果有 应该从比较中排除 比较阶梯 实践中用来测试URI等价的方法有很多变种 这些方法落在一个范围里 需要多少过程来区分和哪种方法更能减少错误的否定 如上所述 错误的否定无法避免 实践中 它们的可能性能被减少 但是这个减少要求更多的处理并且不是对所有应用都合算的 如果比较实践的范围被看作一个阶梯 接下来的讨论将攀登这个阶梯 开始的实践是廉价但是有相对高的机会产生错误的否定 然后去到那些有更高计算成本和更低的错误否定风险的实践 简单字符串比较 如果两个URIs 当被认为是字符串 并且相同 那么断定它们等价是安全的 这类等价的测试的计算成本非常低并且广泛用于各种应用 特别是在解析域名中 测试字符串的等价性需要一些基本的注意事项 这个过程经常被称为 每比特 或 每字节 比较 它是潜在的误导 测试字符串的等价性通常是基于构成该字符串的字符对 从第一个开始一直到两个字符串结束且发现所有字符都等价 或直到一对字符比较不等价 或字符串之一在另一个之前结束 这一字符比较需要每一对字符是以可比较的格式存放的 例如 一个URI应该被存储成一个以EBCDIC编码的字节数组而第二个URI被存储成一个Java字符串对象 UTF 16 天真地应用每比特比较将产生错误 等价比较的更好的说法是基于每字符而不是每字节或每比特 实际上 每字符比较应该是在转换成通用字符编码之后的每码点比较 错误的否定是由URI别名的生产和使用造成的 无关比较方法 通过在一个已常规化的格式中一致性地提供URI引用 即 和应用常规化之后被生产的格式相同的一个格式 如下所述 可以减少不必要的别名 协议和数据格式经常限制了一些URI比较去简化字符串比较 基于这个理论人们和应用将出于他们自己的最佳利益 一致性地提供URI引用 或至少一致到足够否决任何从更多常规化中获得的效率 基于语法的常规化 实现可以使用基于本协议提供的定义的逻辑来降低错误否定的可能性 这个过程的开销适度地高于每字符的字符串比较 例如 一个使用这个方法的应用可能合理地认为以下两个URIs是等价的 source lang html4strict example a b c 7Bfoo 7D eXAMPLE a b b 63 7bfoo 7d source Web用户代理 类似浏览器 当决定是否一个缓存的应答可用的时候典型地应用这类URI常规化 基于语法的常规化包括这类技术 如案例常规化 百分号常规化 以及移除点片段 大写常规化 对于所有URIs来说 一个百分号编码的三连符中的十六进制数字 例如 3a 和 3A 是大小写不敏感的并且因此应该使用大写字母来常规化数字 A F 当一个URI使用通用语法部件 该部件语法语法等价规则总是适用 亦即 格式和主机是大小写不敏感的并且因此应该被常规化成小写 例如 URI HTTP www EXAMPLE com 等价于 http www example com 其他通用语法部件被假定是大小写敏感的 除非由格式特别定义 见 RFC3986 基于格式的常规化 6 2 3 百分号编码常规化 百分号编码机制 RFC3986 百分号 2 1 在其他相同的URIs中是一个频繁出现的来源 除了上面注意到的大写常规化问题 一些百分号编码八位字节的URI生产者不必需百分号编码 结果是那些URIs等价于它们的未编码部分 这些URIs应该被解码任何百分号编码来常规化以对应一个非保留的字符 如 RFC3986 非保留字符 2 3 所述 路径片段常规化 完整的路径片段 和 只打算用在相对引用中 RFC3986 URI引用 4 1 并且会作为引用解析过程的一部分被移除 RFC3986 相对解析 5 2 无论如何 一些已部署的实现不正确地假定当引用已经是一个URI的时候引用解析是不必要的 使得当它们遇到非相对路径时未能移除点片段 URI常规化者应该通过应用 移除点片段 算法来从该路径移除点片段 如 RFC3986 移除点片段 5 2 4 所述 基于格式的常规化 各个格式的URIs的语法和语义是不同的 如每个格式的定义协议所述 实现可以使用格式特有的规则 以更高的处理成本 来减少错误否定的可能性 例如 因为一个用于授权部件的 http 格式 有一个缺省端口 80 并且定义了一个空路径等价于 以下四个URIs是等价的 source lang html4strict http example com http example com http example com http example com 80 source 通常 一个使用通用语法来授权一个空路径的URI应该被常规化成一个路径 同样 一个显式的 port 这里这个端口号是空的或对该格式是缺省的 等价于该端口和它的 分隔符被省略了 从而应该被基于格式的常规化移除 例如 上述第二个URI对于 http 格式来说是常规格式 另一种由格式导致常规化的不同的情形是空的机构部件或空主机子部件的处理中 对于某些格式协议 一个空机构或主机被认为是一个错误 对于另一些格式协议 它被认为等价于 localhost 或最终用户的主机 当一个格式为机构定义了一个缺省值并且需要一个URI引用那个缺省值 为了保证一致性 简洁和国际化 那个引用应被常规化成一个空的机构 如果 无论如何 如果用户信息或端口子部件是非空的 那么主机应该被明确给出 即使它和缺省值是一样的 常规化应该不移除分割符 当它们的相关部件是空的时候 除非该格式协议允许这么做 例如 URI http example com 不能被假定等价于上述的任何例子 同样的 在一个用户信息子部件中分割符的出现与否常常是和它的解释有明显的关系 片段部件不受任何基于格式的常规化 于是 两个只是后缀 不同的URIs被认为是不同的 这和该格式无关 一些格式定义的额外的子部件包含了大小写不敏感的数据 把一个隐含的授权给了常规化者来把这个数据转换成一个常用大小写 例如 全部小写 例如 定义了一个路径子部件以包含一个互联网主机名的URI格式 类似 mailto URI格式 因为那个子部件是大小写不敏感的并且从而遵循大小写格式化 例如 mailto Joe Example COM 等价于 mailto Joe example com 即使通用语法认为路径部件是大小写敏感的 其他格式特有的常规化也是可能的 基于协议的常规化 降低错误否定的发生率的主要工夫常常对web蜘蛛是很合算的 所以 它们在URI比较上甚至实现了更具侵略性的技术 例如 如果它们观察到一个如下的URI source lang html4strict http example com data source 重定向到了一个只是多了一个尾随的斜杠的URI source lang html4strict http example com data source 它们或许将在未来把这两者视为等价 这种技术只是在等价同时清楚地被访问该资源的结果和它们的格式的解参考算法的通用惯例表示出来的时候才适合 在这个例子中 由HTPP源服务器使用的重定向避免了相对引用的问题 安全事项 URI本身不会产生安全性的威胁 然而 因为URIs经常被用于提供一系列指示用于访问网络资源 必须小心地适当解释一个URI中的数据 以防止那个数据被意外地访问 并且避免包含不应该在纯文本中出现的数据 可靠性和一致性 一个URI被用于取回信息 不保证将来同样的信息可以被那个URI取回 也不保证未来通过那个URI可取回的数据会和过去取回的数据明显类似 URI语法不约束一个给定的格式或机构如何分配它的命名空间或维护它的超时 这类保证只能来自控制那个问题中的命名空间和资源的人 们 一个特定的URI格式可以定义额外的语义 类似名字持久化 如果那些语义对于那个格式的所有命名机构都是必需的话 恶意构造 有时可能会有人构造一个URI来尝试执行一个貌似有害的幂等操作 例如取回一个表示 将实际导致一个可能有害的远程操作 不安全的URI典型地是通过指定一个和网络协议的保留端口不同的端口号来构造的 客户端不知不觉地联系了一个运行了不同协议服务的网站 以及该URI包含的数据的指示 当根据另一个协议解释的时候 导致意外的操作 一个常见的此类例子是对基于协议的格式因而带有的端口号 25 的滥用 从而欺骗用户代理软件通过一个SMTP服务器发送一个意想不到的或假冒的消息 应用应该防止一个URI的解参考指定一个 广为人知的端口范围 0 1023 中的TCP端口 除非用来解参考那个URI的协议和那个端口上预期的协议是兼容的 尽管IANA维护了一个已知端口号的注册表 应用应该让这些约束成为用户可配置的以避免妨碍新服务的部署 当一个URI包含的百分号八位字节和用于给定的解释或解参考协议的分隔符匹配 例如 用于TELNET协议的 CR 和 LF 符号 在传输穿过那个协议之前这些百分号编码不能被解码 百分号编码的传输 它可能违反协议 的伤害可能低于允许被解码的八位字节被解释成额外的操作或参数 可能触发一个意外和可能有害的远程操作 后端转码 当一个URI被解参考 它里面的数据经常同时被用户代理和一个或多个服务器解析 在HTTP中 例如 一个典型的用户代理把一个URI解析成它的五个主要的部件 访问机构的服务器 并向它发送机构 路径和查询部件中的数据 一个典型的服务器将获得那些信息 把路径解析成片段并查询 键 值 对 然后调用实现特有的处理程序以应答该请求 结果是 对于处理一个作为整体或分离成独立部件的URI的服务器实现来说 一个常见的安全问题是 它是对那个URI中的字符串和百分号编码展示的八位字节数据的适当的解释 百分号字节在解参考过程中必须在某些点被解码 应用必须在解码这些字节之前把URI分离成它的部件和子部件 否则被解码的字节可能被误解为分隔符 在一个URI中的数据的安全性检查应该在字节被解码之后应用 记住 无论如何 00 百分号 空 可能要求特殊的处理并且如果应用不期望在一个部件里接收原数据则应该被拒绝 当URI路径解释过程包含了对后端文件系统或相关的系统功能的使用的时候应特别小心 文件系统典型地把一个可操作的含义赋予给特定的字符 例如 和 字符 以及特别的设备名类似 aux lpt 等等 在某些情况下 对这类名称的存在很少测试将导致操作系统暂停或请求和系统无关的调用 导致明显的拒绝服务和意外的数据传输的安全问题 有可能的话本协议将列出所有这类重要字符和设备名称 实现应该研究为可能被挂载到它们的应用的存储类型保留名称和字符并从而限制从URI部件获得的数据中使用它们 罕见的IP地址格式 尽管用于IPv4address的URI语法只允许常见的IPv4地址文字的 点 十进制 格式 很多处理URIs的实现使用了独立于平台的系统函数 例如 gethostbyname 和 inet aton 来把字符文字翻译成一个确切的IP地址 不幸的是 这类系统函数经常允许和处理比 RFC3986 主机 3 2 2 中描述的格式更大的集合 例如 很多实现允许三个数字的点格式 其最后部分被解释为一个16比特的数量并被放到网络地址的最右边的两个字节 例如 一个B类网络 同样的 两个数字的点格式意味着最后部分被解释为一个24比特的数量并被放到地址的最右边的三个字节 A类 而一个单独的数字 没有点 被解释为一个32比特的数量并被直接存到网络地址 更多的混乱是 一些实现允许每个点部分被解释为十进制 八进制 或十六进制 特别是在C语言中 即 一个打头的 0x 或 0X 暗示一个十六进制 一个打头的 0 暗示八进制 否则 该数字被解释为十进制 在URi语法中不允许额外的IP地址格式是因为平台实现之间的不同 无论如何 如果一个应用尝试基于字符文本格式的IP地址过滤到资源的访问 它们可能成为一个安全问题 如果这个过滤被执行了 文字应该被转换成数字格式并基于数字值过滤 不要基于一个字符格式的前缀或后缀 敏感信息 URI制作者应该不提供包含了了通常保密的用户名和密码的URI URIs经常由浏览器显示 被存储成纯文本书签 并且被用户代理历史和中介应用 代理 记录了日志 在用户信息部件中包含密码是被反对的并且应该被视为一个错误 或简单地忽略 除非在那些罕见的情况下 password 参数才会公开出现 语义攻击 因为在机构部件中用户信息子部件在主机之前很少被使用和出现 它可能被用于构造一个URI来误导一个自然人用户 看似标识一个 可信的 命名机构 实际上标识一个隐藏在噪音后面的不同的机构 例如 source lang text ftp cnn example com story breaking news 10 0 0 1 top story htm source 可能引导一个自然人用户假定该主机为 cnn example com 而它实际上是 10 0 0 1 注意一个误导的用户信息子部件可能比上述的例子更长 一个误导的URI 类似上面那个 是对用户对于一个URI的含义的先入为主的概念的攻击而不是对对该软件本身的攻击 用户代理可能可以通过在呈现该URI的多个部件的时候区别开它们来减少这类攻击的影响 例如通过使用不同的颜色或声音来呈现用户信息 如果有的话 尽管没有灵丹妙药 更多关于基于URI的语义的攻击可以在 http tools ietf org html rfc3986 ref Siedzik Siedzik 找到 IANA事项 URI格式名称 在 RFC3986 Scheme 3 1 中的 scheme 定义 格式化一个根据 RFC3986 参考文献 BCP35 定义的流程由IANA管理的已注册的命名空间 本文不需要任何IANA操作 致谢 本协议来源于 http tools ietf org html rfc2396 RFC 2396 http tools ietf org html rfc1808 RFC 1808 和 http tools ietf org html rfc1738 RFC 1738 那些文档中的致谢在本文仍然适用 本协议也合并了主机语法中的IPv6文字的更新 及修正 如 Robert M Hinden Brian E Carpenter 和 Larry Masinter 在 http tools ietf org html rfc2732 RFC2732 中定义的那样 另外 非常感谢下列人员的贡献 Gisle Aas Reese Anschultz Daniel Barclay Tim Bray Mike Brown Rob Cameron Jeremy Carroll Dan Connolly Adam M Costello John Cowan Jason Diamond Martin Duerst Stefan Eissing Clive D W Feather Al Gilman Tony Hammond Elliotte Harold Pat Hayes Henry Holtzman Ian B Jacobs Michael Kay John C Klensin Graham Klyne Dan Kohn Bruce Lilly Andrew Main Dave McAlpin Ira McDonald Michael Mealling Ray Merkert Stephen Pollei Julian Reschke Tomas Rokicki Miles Sabin Kai Schaetzl Mark Thomson Ronald Tschalaer Norm Walsh Marc Warne Stuart Williams 和 Henry Zongaro 参考 规范引用 ASCII American National Standards Institute Coded Character Set 7 bit American Standard Code for Information Interchange ANSI X3 4 1986 RFC2234 Crocker D and P Overell Augmented BNF for Syntax Specifications ABNF RFC 2234 November 1997 STD63 Yergeau F UTF 8 a transformation format of ISO 10646 STD 63 RFC 3629 November 2003 UCS International Organization for Standardization Information Technology Universal Multiple Octet Coded Character Set UCS ISO IEC 10646 2003 December 2003 参考文献 BCP19 Freed N and J Postel IANA Charset Registration Procedures BCP 19 RFC 2978 October 2000 BCP35 Petke R and I King Registration Procedures for URL Scheme Names BCP 35 RFC 2717 November 1999 RFC0952 Harrenstien K Stahl M and E Feinler DoD Internet host table specification RFC 952 October 1985 RFC1034 Mockapetris P Domain names concepts and facilities STD 13 RFC 1034 November 1987 RFC1123 Braden R Requirements for Internet Hosts Application and Support STD 3 RFC 1123 October 1989 RFC1535 Gavron E A Security Problem and Proposed Correction With Widely Deployed DNS Software RFC 1535 October 1993 RFC1630 Berners Lee T Universal Resource Identifiers in WWW A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World Wide Web RFC 1630 June 1994 RFC1736 Kunze J Functional Recommendations for Internet Resource Locators RFC 1736 February 1995 RFC1737 Sollins K and L Masinter Functional Requirements for Uniform Resource Names RFC 1737 December 1994 RFC1738 Berners Lee T Masinter L and M McCahill Uniform Resource Locators URL RFC 1738 December 1994 RFC1808 Fielding R Relative Uniform Resource Locators RFC 1808 June 1995 RFC2046 Freed N and N Borenstein Multipurpose Internet Mail Extensions MIME Part Two Media Types RFC 2046 November 1996 RFC2141 Moats R URN Syntax RFC 2141 May 1997 RFC2396 Berners Lee T Fielding R and L Masinter Uniform Resource Identifiers URI Generic Syntax RFC 2396 August 1998 RFC2518 Goland Y Whitehead E Faizi A Carter S and D Jensen HTTP Extensions for Distributed Authoring WEBDAV RFC 2518 February 1999 RFC2557 Palme J Hopmann A and N Shelness MIME Encapsulation of Aggregate Documents such as HTML MHTML RFC 2557 March 1999 RFC2718 Masinter L Alvestrand H Zigmond D and R Petke Guidelines for new URL Schemes RFC 2718 November 1999 RFC2732 Hinden R Carpenter B and L Masinter Format for Literal IPv6 Addresses in URL s RFC 2732 December 1999 RFC3305 Mealling M and R Denenberg Report from the Joint W3C IETF URI Planning Interest Group Uniform Resource Identifiers URIs URLs and Uniform Resource Names URNs Clarifications and Recommendations RFC 3305 August 2002 RFC3490 Faltstrom P Hoffman P and A Costello Internationalizing Domain Names in Applications IDNA RFC 3490 March 2003 RFC3513 Hinden R and S Deering Internet Protocol Version 6 IPv6 Addressing Architecture RFC 3513 April 2003 Siedzik Siedzik R Semantic Attacks What s in a URL April 2001 http www giac org practical gsec Richard Siedzik GSEC pdf 附录A 为URI收集的ABNF source lang text URI scheme hier part query fragment hier part authority path abempty path absolute path rootless path empty URI reference URI relative ref absolute URI scheme hier part query relative ref relative part query fragment relative part authority path abempty path absolute path noscheme path empty scheme ALPHA ALPHA DIGIT authority userinfo host port userinfo unreserved pct encoded sub delims host IP literal IPv4address reg name port DIGIT IP literal IPv6address IPvFuture IPvFuture v 1 HEXDIG 1 unreserved sub delims IPv6address 6 h16 ls32 5 h16 ls32 h16 4 h16 ls32 1 h16 h16 3 h16 ls32 2 h16 h16 2 h16 ls32 3 h16 h16 h16 ls32 4 h16 h16 ls32 5 h16 h16 h16 6 h16 h16 h16 1 4HEXDIG ls32 h16 h16 IPv4address IPv4address dec octet dec octet dec octet dec octet dec octet DIGIT 0 9 x31 39 DIGIT 10 99 1 2DIGIT 100 199 2 x30 34 DIGIT 200 249 25 x30 35 250 255 reg name unreserved pct encoded sub

    Original URL path: http://wiki.jabbercn.org/index.php?title=RFC3986&action=edit (2016-04-25)
    Open archived version from archive

  • “RFC3986”的版本历史 - Jabber/XMPP中文翻译计划
    当前 先前 2013年12月12日 四 15 53 Admin 讨论 贡献 小 92 663字节 参考文献 当前 先前 2013年12月12日 四 15 51 Admin 讨论 贡献 89 489字节 致谢 当前 先前 2013年12月12日 四 15 42 Admin 讨论 贡献 86 035字节 致谢 当前 先前 2013年12月11日 三 14 39 Admin 讨论 贡献 86 007字节 IANA事项 当前 先前 2013年11月29日 五 14 17 Admin 讨论 贡献 小 86 015字节 语义攻击 当前 先前 2013年11月29日 五 14 16 Admin 讨论 贡献 84 743字节 语义攻击 当前 先前 2013年11月26日 二 11 04 Admin 讨论 贡献 83 710字节 敏感信息 当前 先前 2013年11月21日 四 12 06 Admin 讨论 贡献 83 324字节 罕见的IP地址格式 当前 先前 2013年11月19日 二 11 39 Admin 讨论 贡献 小 83 540字节 罕见的IP地址格式 当前 先前 2013年11月18日 一 12 48 Admin 讨论 贡献 81 898字节 后端转码 当前 先前 2013年11月16日 六 13 32 Admin 讨论 贡献 小 82 161字节 后端转码 当前 先前 2013年11月15日 五 10 25 Admin 讨论 贡献 小 82 267字节 后端转码 当前 先前 2013年11月14日 四 10 00 Admin 讨论 贡献 80 087字节 恶意构造 当前 先前 2013年11月13日 三 10 46 Admin 讨论 贡献 小 80 321字节 恶意构造 当前 先前 2013年11月12日 二 23 01 Admin 讨论 贡献 78 685字节 可靠性和一致性 当前 先前 2013年11月12日 二 10 42 Admin 讨论 贡献 78 167字节 安全事项 当前 先前 2013年11月11日 一 11 13 Admin 讨论 贡献 小 77 894字节 基于协议的常规化 当前 先前 2013年11月11日 一 11 11 Admin 讨论 贡献 77 742字节 基于协议的常规化 当前 先前 2013年11月11日 一 11 04 Admin 讨论 贡献 小 77 840字节 基于协议的常规化 当前 先前 2013年11月3日 日 23 35 Admin 讨论 贡献 77 050字节 基于格式的常规化 当前 先前 2013年11月1日 五 14 50 Admin 讨论 贡献 小 77 506字节 给予协议的常规化 当前 先前 2013年11月1日 五 14 50 Admin 讨论 贡献 小 77 506字节 基于格式的常规化 当前 先前 2013年10月31日 四 11 10 Admin 讨论 贡献 74 569字节 基于语法的常规化 当前 先前 2013年10月31日 四 11 10 Admin 讨论 贡献 74 570字节 路径片段常规化 当前 先前

    Original URL path: http://wiki.jabbercn.org/index.php?title=RFC3986&action=history (2016-04-25)
    Open archived version from archive

  • 链接至“RFC3986”的页面 - Jabber/XMPP中文翻译计划
    MediaWiki讨论 模板 模板讨论 帮助 帮助讨论 分类 分类讨论 过滤器 隐藏 包含 隐藏 链接 隐藏 重定向 下列页面链接至 RFC3986 查看 上50个 下50个 20 50 100 250 500 首页 链入页面 模板 最新消息 链入页面 Jabber XMPP中文翻译计划 新闻动态 链入页面 RFC3986 链入页面 查看 上50个 下50个 20 50 100 250 500 来自 http wiki jabbercn org E7 89 B9 E6 AE 8A E9 93 BE E5 85 A5 E9 A1 B5 E9 9D A2 RFC3986 查看 页面 讨论

    Original URL path: http://wiki.jabbercn.org/%E7%89%B9%E6%AE%8A:%E9%93%BE%E5%85%A5%E9%A1%B5%E9%9D%A2/RFC3986 (2016-04-25)
    Open archived version from archive

  • 对于“RFC3986”有关的链出更改 - Jabber/XMPP中文翻译计划
    50 100 250 500 次改动 隐藏 小编辑 显示 机器人的编辑 隐藏 匿名用户的编辑 隐藏 登录用户的编辑 隐藏 我的编辑 显示自 2016年4月25日 一 16 56 起的新更改 名字空间 全部 主要 讨论 用户 用户讨论 Jabber XMPP中文翻译计划 Jabber XMPP中文翻译计划讨论 文件 文件讨论 MediaWiki MediaWiki讨论 模板 模板讨论 帮助 帮助讨论 分类 分类讨论 反选 相关名字空间 页面名称 显示链到所给出的页面 在这一段时间中链接的页面并无更改 来自 http wiki jabbercn org E7 89 B9 E6 AE 8A E9 93 BE E5 87 BA E6 9B B4 E6 94 B9 RFC3986

    Original URL path: http://wiki.jabbercn.org/%E7%89%B9%E6%AE%8A:%E9%93%BE%E5%87%BA%E6%9B%B4%E6%94%B9/RFC3986 (2016-04-25)
    Open archived version from archive

  • RFC3986 - Jabber/XMPP中文翻译计划
    一些URI schemes包含一个层次元素来描述一个命名的机构 这样由该URI的其他部分定义的命名空间的管理方式就被授予那个机构 它可以相应地进一步授予 通用语法提供了一个常见方法来基于已注册的名称或服务器地址来区分一个机构 以及可选的端口和用户信息 机构部件的前面是一个双斜杠 并结束于下一个斜杠 问号 或井号 字符 或随着该URI结束 authority userinfo host port 如果端口部件是空的 URI制作者和正规化者应该省略把端口和主机分隔开的 分隔符 一些schemes不允许用户信息 和 或 端口子部件 如果一个URI包含一个机构部件 那么路径部件必须要么是空的要么以一个斜杠 字符开始 不检查的解析器 那些很少分隔一个URI参数到它的主要部件的解析器 将经常忽略机构的子部件结构 把从双斜杠到第一个终止分隔符之间的东西当成一个不透明的字符串 直到该URI被解析的时间 用户信息 用户信息子部件可以包含一个用户名和 可选的 关于如何获得授权访问资源的格式特有的信息 用户信息 如果出现 后面会跟随一个商标 以和主机分开 userinfo unreserved pct encoded sub delims 在用户信息字段对格式 user password 的使用已经被废弃了 应用不应该在一个用户信息子部件中找到的第一个冒号 字符后面提出任何明码文本数据 除非在该冒号后面的数据是空字符串 表示没有密码 当收到作为一个参数的一部分的这样的数据的时候 应用可以选择忽略或拒绝这类数据并且应该拒绝这类数据以未加密方式存储 以明码方式通过验证信息已经被证明在绝大多数情况使用它是一个安全风险 为了用户反馈的目的而提供一个URI的应用 类似图形化的超文本浏览 应该以某种从一个URI的其他部分区分出来的方式提供用户信息 在可能的时候 当发生用户信息已经被手工误导看起来像一个被信任的域名的情况 这类表达可以帮助到用户 7 6 主机 机构的主机子部件是由一个封装在方括号内的IP文字 一个点分十进制格式的IPv4地址 或一个注册名称来标识的 主机子部件是大小写敏感的 在一个URI中出现了主机子部件不意味着该格式要求访问互联网上的给定主机 在一些情况下 主机语法只被用于重用现有的用于DNS的创建和部署的注册流程 从而获得一个全局唯一的名称而不用费劲部署另一个注册表 无论如何 这种用法有它自己的代价 域名所有者可能因为URI制作者无法预计的原因而随时变更 在另外一些情况下 子部件内的数据标识一个注册名称但没有任何事情要在一个互联网主机上去做 我们使用ABNF规则的名称 host 是因为那是它最常用的目的 不是它仅有的目的 host IP literal IPv4address reg name 主机的语法规则是含糊的 因为不能完全区分一个IPv4地址和一个注册名称 为了澄清语法 我们应用 先匹配者赢 算法 如果主机匹配IPv4地址规则 那么它应该被认为是一个IPv4地址文字而不是一个注册名称 尽管主机是大小写敏感的 为了统一的目的制作者和正规化者应该对注册名和十六进制地址使用小写 只在百分号编码使用大写字母 由版本6 RFC3513 或更晚版本的互联网协议文字地址标识的主机 是通过方括号 和 围起IP文字来区分的 这是唯一一个被允许在URI语法中出现方括号字符的地方 在可预见的将来 还未定义的IP文字地址格式 实现可以使用一个可选的版本标记来显式地指示这样一个格式而不是依靠启发式的决定 IP literal IPv6address IPvFuture IPvFuture v 1 HEXDIG 1 unreserved sub delims 版本标记不指示IP版本 而是指示该文字格式的未来版本 同样的 实现不能为下面描述的现有的IPv4和IPv6文字地址格式提供该版本标记 如果一个URI包含一个以 v 大小写不敏感 开始的IP 文字 标识那个版本标记是当前的 当它由一个不理解该版本标记的含义的应用解参考的时候 那么该应用返回一个适当的错误 地址机制不支持 一个由IPv6文字地址标识的主机被展现在不带前述的版本标记的方括号内 这里的ABNF是对一个 RFC3513 提供的IPv6文字地址的文本定义的翻译 这个语法不支持IPv6范围地址区域标识 一个128位的IPv6地址被分为8个16位的片段 每一片展现为大小写敏感的16进制数字 使用一到四个十六进制数字 允许以零开头 这8个编码的片首先是给定的最大有效数 由冒号分开 可选的 最小有效的两个片段可以被替换来展现IPv4地址的文本格式 地址中的一系列一个或多个连续的零值的16位片段可以被忽略 省略它们的所有数字并确切地在它们的位置留下两个连续的冒号以标记该省略 IPv6address 6 h16 ls32 5 h16 ls32 h16 4 h16 ls32 1 h16 h16 3 h16 ls32 2 h16 h16 2 h16 ls32 3 h16 h16 h16 ls32 4 h16 h16 ls32 5 h16 h16 h16 6 h16 h16 ls32 h16 h16 IPv4address least significant 32 bits of address h16 1 4HEXDIG 16 bits of address represented in hexadecimal 一个由IPv4文字地址标识的主机被展现为点分十进制表示法 一系列四个范围为0到255的十进制数字 以 分隔 如 RFC1123 所述 参考 RFC0952 注意点符号的其他格式可以在一些平台上被解释执行 如 7 4 所述 但本语法只允许四个八位字节的点分十进制格式 IPv4address dec octet dec octet dec octet dec octet dec octet DIGIT 0 9 x31 39 DIGIT 10 99 1 2DIGIT 100 199 2 x30 34 DIGIT 200 249 25 x30 35 250 255 一个被注册名标识的主机是一系列字符 常常要用它在一个本地定义的主机或服务名称注册表中来查找 尽管该URI的格式特有的语义可以要求替换成一个特有的注册表 或固定的名称表 大部分常用名称注册表机制是域名系统 DNS 在DNS中查询到一个注册名要使用 RFC1034的3 5节 和 RFC1123的2 1节 中定义的语法 这样一个名称包含了一系列以 分隔的域标签 每个域标签以一个文字数字字符开始和结束 也可能包含 字符 一个在DNS中完全合格的域名的最右边的域标签可以在后面带一个单独的 并且如果有必要把完整域名和一些本地域名去分开的话则必须带它 reg name unreserved pct encoded sub delims 如果URI格式为主机定义了一个缺省值 那么当该主机子部件未定义或当注册名称为空 零长度 的时候那个缺省值适用 例如 file URI格式被定义成没有机构 空主机 且 localhost 全都代表最终用户的机器 反之一个缺少机构或空主机的 http 格式被认为是非法的 本协议不强制一个特定的注册名称查询技术并且因而如果不在互操作性的必要情况之上约束reg name语法 反之 它把注册名称语法一致性问题委托给每个执行URI解析的应用的操作系统 并且那个and操作系统来决定允许使用哪种技术来确定主机身份 一个URI解析实现可能使用DNS 主机表 黄页 NetInfo WINS 或任何其他系统来查询注册名称 然而 一个全局范围的命名系统 类似DNS完全合格的域名 对打算全局范围使用的URIs是必要的 URI制作者应该按照DNS语法使用名称 即使当DNS的使用不会立刻被看到的时候 并且应该限制这些名称的长度不超过255个字符 reg name语法允许百分号编码字节 这是为了以一个独立于基本的名称解析技术的统一的方法来展现非ASCII注册名称 非ASCII字符必须首先被根据UTF 8 STD63 编码 并且接着每个UTF 8序列相应的八位字节必须被百分号编码以展现成URI字符 URI制作应用不能对主机使用百分号编码 除非它被用于展示一个UTF 8字符序列 当一个非ASCII注册名称展现了一个打算通过DNS解析的国际化域名 该名称必须在名称查询之前被转换成IDNA编码 RFC3490 URI制作者应该以IDNA编码提供这些注册名称 而不是一个百分号编码 如果他们希望最大化和外部URI解析者的互操作能力 端口 机构的端口子部件由一个可选的跟随在主机后面并且从单个的冒号 字符之后开始的十进制端口号来指定 port DIGIT 一个格式可以定义一个缺省端口 例如 http 格式定义了一个缺省端口 80 和它的保留TCP端口号码一致 由端口号指定的端口的类型 例如 TCP UDP SCTP 是由该URI格式定义的 URI制作者和正规化者应该省略端口部件和它的 边界 如果端口是空的或它的值和该格式的缺省值相同的话 路径 路径部件包含数据 常常组织成层次格式 它连同非层次化的查询部件 3 4 的数据 服务于识别在该URI的格式和命名机构 如果有 范围内的一个资源 路径由第一个问号 或数字符号 字符或该URI的结尾来终止 如果一个URI包含一个机构部件 那么该路径部件必须要么是空的要么以一个斜杠 字符开始 如果一个URI不包含一个机构部件 那么路径不能以双斜杠字符 开始 此外 一个URI引用 4 1 可以是一个和路径相关的引用 在那种情况下第一个路径片段不能包含一个冒号 字符 ABNF要求五个独立的规则来消除这些情况的歧义 只有其中一种情况将会在一个给定的URI引用中和该路径子字符串匹配 我们使用通用术语 路径部件 来描述由这些规则的解析器匹配的该URI子字符串 path path abempty begins with or is empty path absolute begins with but not path noscheme begins with a non colon segment path rootless begins with a segment path empty zero characters path abempty segment path absolute segment nz segment path noscheme segment nz nc segment path rootless segment nz segment path empty 0 pchar segment pchar segment nz 1 pchar segment nz nc 1 unreserved pct encoded sub delims non zero length segment without any colon pchar unreserved pct encoded sub delims 一个路径包含一系列由斜杠 字符分隔的路径片段 对于一个URI来说总是会定义一个路径 尽管定义的路径可能是空 零长度 指示层次用的斜杠字符之在一个URI用作指示相对引用的时候是必需的 例如 URI mailto fred example com 有一个路径 fred example com 反之 URI foo info example com fred 有一个空路径 路径片段 和 也就是点片段 被定义用于路径名称层次的相对引用 它们被用于相对路径引用的开始 RFCSection 4 2 以指示名称的层次树中的相对位置 这和某些操作系统的文件目录结构分别指示当前目录和父目录的它们的角色类似 无论如何 和在一个文件系统中不一样 这些点片段只在URI层次中被这样理解并且被从解析过程的一部分中移除 5 2 除了层次路径中的点片段之外 一个路径片段被通用语法当成不透明的 URI制作应用经常在一个片段中使用保留字符以界定格式特有的或解参考处理者特有的子部件 例如 分号 和等号 保留字符经常被用于界定适用于那个片段的参数和参数值 逗号 保留字符经常被用于类似的目的 例如 一个URI制作者可以使用一个类似 name v 1 1 的片段来指示一个对 name 的1 1版的引用 反之另一个可能使用类似 name 1 1 的片段来指示相同的东西 参数类型可以由格式特有的语义来定义 但是在大多数情况下一个参数的语法对该URI的解参考算法的实现来说是特有的 查询 查询部件包含非层次化的数据 以及路径部件中的数据 3 3 用来从该URI的格式和命名机构 如果有 中识别一个资源 查询部件由第一个问号 字符指示并由一个数字符号 字符或该URI的结尾终止 query pchar 字符斜杠 和问号 可以展现该查询部件内的数据 注意当它被用于相对引用的基础URI的时候 5 1 一些旧的 错误的实现可能没有正确处理这类数据 显然是因为它们在查找层次分隔符的时候未能把查询部件从路径数据中区分开来 无论如何 因为查询部件经常被用于以 键 值 对的格式携带识别信息并且一个常被使用的值是对另一个URI的引用 它经常比百分号编码那些字符有更好的可用性 片段 一个URI的片段标识符部件允许对一个主要资源引用的次要资源的非直接身份认证以及额外的识别信息 被识别的次要资源可以是该主要资源的一部分或子集 或一些由那些陈述所定义或描述的资源 一个片段标识符部件是通过一个数字符号 字符的出现来指示的并由该URI的结尾来终止 fragment pchar 一个片段标识符的语义可以是由一组从主要资源的获取动作导致的表现来定义的 所以片段的格式和解析依赖于一个潜在的获取展现的媒体类型 RFC2046 即使这样一个获取只在URI被解参考的时候执行 如果没有这类体现存在 那么该片段的语义被认为是未知的并且是有效的无限制 片段标识符语义独立于URI格式并且因而不能被格式协议重新定义 单独的媒体类型可以在片段标识符语法内定义它们自己的约束或结构用于指定不同类型的子集 视图或对那个媒体类型可识别的次要资源的外部引用 如果主要资源有多个展现 这中情况常常是资源的展现是该获取请求的属性的可选的基础 又名 内容协商 那么无论该片段识别的什么都应该和那些展现一致 每个展现应该要么定义片段这样它对应相同的次要资源 无论它是如何展现的 要么应该让该片段未定义 即 未找到 对任何URI 片段标识符部件的使用不代表将执行一个获取动作 一个带了片段标识符的URI可被用于指向次要资源而不代表任何主要资源是可访问的或永远无法访问 片段标识符在信息获取系统中有一个特别的作用是作为客户端间接引用的主要格式 允许一个作者特别地识别一个现有的只由该资源所有者间接提供的资源的样子 同样 片段标识符不被用于一个URI的格式特有的处理 反之 在解参考之前片段标识符被从URI的其他部分分离出来 因而该片段本身的识别信息的解参考由用户代理执行 和该URI格式无关 尽管这个独立的处理经常被认为缺少信息 特别是当引用随时间移动的时候引用的准确重定向 它也用于防止信息提供者禁止引用作者在一个可选的资源中引用信息 间接引用也为系统使用URIs提供额外的可伸缩性和可扩展性 因为定义和部署新媒体类型比新身份格式更容易 斜杠 和问号 被允许在片段标识符内展示数据 注意一些旧的 错误的实现可能未正确处理这个数据 当它被用作相对引用的基础URI的时候 5 1 用法 当应用引用一个URI的时候 它们不总是使用该 URI 语法规则定义的引用的完整格式 为了节省空间和方便层次化区域 一些互联网协议元素和媒体类型格式允许一个URI的缩写 反之其他则把语法限制到URI的某个特定格式 我们在本文定义引用语法的最常见格式 因为它们影响和以来通用语法的设计 为了解释的一致性而要求一个通用解析算法 URI引用 URI引用常常代表一个资源标识符的最常见的用法 URI reference URI relative ref 一个URI引用要么是一个URI要么是一个相对引用 如果该URI引用的前缀和跟随在它的冒号后面的格式的语法不匹配 那么该URI引用是一个相对引用 一个URI引用典型地首先被解析成5个URI部件 以确定什么组件是当前的以及该引用是否是相对的 接着 每个部件被解析为子部件和它们的校验 URI引用的ABNF 遵循 先匹配者赢 的消除歧义规则 足够为通用语法定义一个校验解析器 对正则表达式熟悉的读者们应该去看 附录B 的一个非校验的URI引用解析器的例子 它将使用任何给定的字符串并提取该URI部件 相对引用 一个相对引用可以方便地用层次化语法 1 2 3 表达和另一个层次化URI的命名空间相关的一个URI引用 relative ref relative part query fragment relative part authority path abempty path absolute path noscheme path empty 由一个相对引用所指向的URI 也被认为是目标URI 通过应用 第5章 的引用解析算法来获得 一个开始于两个斜杠字符的相对引用被称为一个网络路径引用 这类引用很少被使用 一个开始于单个斜杠字符的相对引用被称为一个绝对路径引用 一个不以斜杠字符开始的相对引用被称为一个相对路径引用 一个包含一个冒号字符的路径段落 例如 this that 不能被用作一个相对路径引用的第一个段落 因为它会被误认为一个格式名称 这样一个段落必须在它前面放一个点段落 例如 this that 以制作一个相对路径引用 绝对URI 一些协议元素仅被一个不带片段标识符的URI的绝对格式允许 例如 定义一个符合不允许片段的绝对URI语法规则的基础URI用于晚些时候供相对引用调用 absolute URI scheme hier part query URI格式协议必须定义它们自己的语法 这样所有和它们的格式特有的语法匹配的字符也将和 绝对URI 语法匹配 格式协议将不定义片段标识符语法或用法 不管它对来自那个格式的资源标识符的适用性如何 因为片段标识符直交于格式定义 无论如何 鼓励格式协议包含大范围的示例 包括展示携带了片段标识符的格式的URI如何使用 当这类用法是恰当的时候 同文引用 当一个URI引用指向这样一个URI 除了它的片段部件以外 如果有的话 和基础URI 5 1 完全一样 那个引用被称为一个 同文 引用 同文引用的最常用的例子是空的或只包含一个后面跟随着片段标识符的数字标记 分隔符的相对引用 当一个同文引用为了一个获取动作而被解参考 那个引用的目标被定义成在该引用的同一个实体 展示 文档 或消息 中 所以 一个解参考不应改导致一个新的获取动作 在基础的和目标的URIs的比较之前进行正规化 如 6 2 2 和 6 2 3 所述 是被允许的 但是实践中很少被执行 正规化可以增加同文引用集合 这有利于某些缓存引用 同样 引用作者不应该假定那是轻微的不同 甚至等价 引用URI将 或将不 被任何给定应用理解为一个同文引用 后缀引用 URI语法是为通过URI格式明确地引用资源和可扩展性而定义的 然而 因为URI识别和用法以及普及了 传统媒体 电视 广播 报纸 公告牌 等等 已经越来越多地使用一个URI的后缀来作为一个引用 只包含URI的机构和路径部分 类似 www w3 org Addressing 或简单的一个它自己的DNS注册名称 这类引用主要是为了自然人而不是机器理解 同时假定基于上下文的启发对完成该URI是足够的 例如 大部分以 www 开始的注册名似乎有一个URI前缀 http 尽管没有对一个URI后缀消除歧义的启发的标准集合 一些客户端实现云讯它们由用户输入并且启发式地理解 尽管使用后缀引用在实践中很常见 应该避免任何的可能并且应该永远不在被期望长期使用的引用的情况下使用 上面提到的启发将随事件改变 特别是当一个新的URI格式流行的时候 并且当超出上下文使用的时候经常是不正确的 进一步的 按照 RFC1535 的那些描述 它们能导致安全性问题 因为一个URI后缀和一个相对路径引用有相同的语法 一个后缀引用不能被用于被期望使用相对引用的上下文中 结果是 后缀引用被限制于没有定义基础URI的地方 类似对话框和离线广告 引用解析 本章定义解析一个允许相对引用的上下文中的URI引用的过程 结果是一个和 第3章 的 URI 语法规则匹配的字符串 建立基础URI 术语 相对 暗示存在一个应用于相对引用的 基础URI 除了仅片段引用 4 4 相对引用只在已知一个基础URI的时候有用 一个基础URI必须在解析可能被引用的URI之前由解析器建立 一个基础URI必须遵循 absolute URI 语法规则 4 3 如果该基础是从一个URI引用URI获得的 那么该引用必须在它被用作一个基础URI之前被转化成绝对格式并剥离任何片段部件 一个引用的基础URI可以以四种方法之一来建立 在下面按优先级逐一讨论 优先级的顺序以术语的层级来考虑 被定义得最靠近基础URI的就是最高优先级 图形化显示如下 relative reference 5 1 1 Base URI embedded in content 5 1 2 Base URI of the encapsulating entity message representation or none 5 1 3 URI used to retrieve the entity 5 1 4 Default Base URI application dependent 嵌入在内容里的基础URI 在特定的媒体类型中 一个用于相对引用的基础URI可能被封装在内容本身之中 这它能很容易地被一个解析器获得 这对于描述性文档是很有用的 类似内容表格等 它可以通过协议被转换成其他东西而不是它们常常被获取的时候的上下文 例如 email 或 USENET 新闻 指定一个基础URI如何被每个媒体类型嵌入超出了本协议的范围 当有适当的语法可用的时候 它由和每个媒体类型相关的数据格式协议来描述 来自封装实体的基础URI 如果没有基础URI被封装 则该基础URI由展示的获取上下文来定义 对一个封闭在另一个实体中的文档来说 这样一个消息或存档 获取上下文就是那个实体 所以 一个展示的缺省基础URI就是把展现封装在其中的那个实体的基础URI 在一个MIME容器类型 例如 消息和多部件类型 中封装一个基础URI的机制由MHTML RFC2557 定义 协议不使用MIME消息头语法 但是的确允许某些标记元数据的格式被包含在消息中 可能为了定义一个基础URI成为一个消息的一部分来定义它们自己的语法 来自检索URI的基础URI 如果没有内嵌的基础URI并且表现未封装到一些其他实体中 那么 如果一个URI被用来获取表现 那个URI将被认为是基础URI 注意如果获取动作是一个重定向请求导致的 最后被使用URI 即 导致实际的获取表现的动作的URI 是基础URI 缺省基础URI 如果没有适用以上描述的条件 那么基础URI由应用的上下文定义 因为这个定义需要依赖应用 如果使用其他方法之一未能定义基础URI可能导致同样的内容在不同类型的应用中有不同的解释 一个包含相对引用的表现的发送者要负责确保那些应用的一个基础URI能被建立 除了仅片段的引用 相对引用只能被用于基础URI被良好定义的可靠情形之下 相对解析 本章描述了把一个和给定基础URI相关的URI引用转换成引用目标的已解析部件的算法 然后该部件被重写成目标URI的格式 如 5 3 所述 这个算法提供最后的结果 能被用于测试其他实现的输出 应用可以使用某些其他算法来实现相对引用解析 提供的结果将和本算法的结果吻合 预解析基础URI 基础URI Base 是根据 5 1 的步骤建立的并被解析成 3 描述的五个主要的部件 注意在一个基础URI中只有格式部件是必需的 其他部件可以是空的或未定义的 如果一个部件的相关分割符未出现在该URI引用之中那么该部件是未定义的 路径部件永远不会是未定义的 虽然它可以是空的 基础URI的正规化 如 6 2 2 和 6 2 3 所述 是可选的 一个URI引用必须在它能被正规化之前被转换成它的目标URI 转换引用 对每个URI引用 R 来说 以下伪码描述了一个把R转换成它的目标URI T 的算法 URI引用被解析成 5 个URI部件 R scheme R authority R path R query R fragment parse R 一个非约束的解析器可以忽略引用中的格式 如果该引用和基础URI的格式是相同的 if not strict and R scheme Base scheme then undefine R scheme endif if defined R scheme then T scheme R scheme T authority R authority T path remove dot segments R path T query R query else if defined R authority then T authority R authority T path remove dot segments R path T query R query else if R path then T path Base path if defined R query then T query R query else T query Base query endif else if R path starts with then T path remove dot segments R path else T path merge Base path R path T path remove dot segments T path endif T query R query endif T authority Base authority endif T scheme Base scheme endif T fragment R fragment 合并路径 上面的伪码适用于一个 合并 程序 用于合并相对路径引用和基础URI路径 它是如下完成的 如果基础URI有一个已定义的机构部件和一个空路径 则返回一个包含和引用路径一起的 的字符串 否则 返回一个字符串 包含该引用的路径部件加上除了该基础URI的路径的最后一个片段的所有其他片段 即 除基础URI路径最右边的 后面的任何符号 或除了完整的基础URI路径 如果该基础URI不包含任何 符号 移除点片段 该伪码也适用于一个 移除点片段 程序 用于从一个被引用路径解释和移除特定的 and 完整路径片段 这要在该路径被从一个引用提取出来之后来做 无论该路径是否相对的 目的是在格式化目标URI之前移除任何非法或无关的点片段 尽管有很多方法可以完成这个移除过程 我们描述一个使用两个字符串缓冲的简单方法 1 输入缓冲以刚加上的路径部件初始化 而输出缓冲被初始化成空字符串 2 当输入缓冲是空的时候 按以下回路 A 如果输入缓冲以前缀 或 开始 那么从输入缓冲移除该前缀 否则 B 如果输入缓冲以前缀 或 开始 这里 是一个完整的路径片段 那么在输入缓冲中把那个前缀替换成 否则 C 如果输入缓冲以前缀 或 开始 这里 是一个完整路径片段 那么在输入缓冲中把该前缀替换成 并从输出缓冲中移除最后的片段以及它前面的 如果有的话 否则 D 如果输入缓冲仅包含 或 那么从输入缓冲移除它 否则 E 在输入缓冲中把第一个路径片段移动到输出缓冲的尾部 包括初始的 符号 如果有的话 和任何随后的符号 但不包括下一个 符号或输入缓冲的结尾 3 最后 输出缓冲被返回一个 移除了点片段 的结果 注意点片段的目的是在URI引用中用于在基础URI中表达一个和名称的层次相对的标识符 移除点片段 算法通过移除额外的点片段来尊重层次而不是把它们当成一个错误或留着它们去被解参考实现误解 接下来演示上述步骤如何应用于合并路径的两个例子 展示每个步骤之后两个缓冲的状态 STEP OUTPUT BUFFER INPUT BUFFER 1 a b c g 2E a b c g 2E a b c g 2E a b c g 2B a b c g 2C a b g 2C a g 2E a g STEP OUTPUT BUFFER INPUT BUFFER 1 mid content 5 6 2E mid content 5 6 2E mid content 5 6 2C mid 6 2E mid 6 一些应用可能发现通过使用两个片段栈而不是字符串来实现移除点片段算法更加高效 注意 当心一些旧的 错误的实现将无法在合并基础和引用路径之前从它的路径部件分离出引用的查询部件 如果该查询部件包含字符串 或 会导致互操作性失败 部件重写 已解析的URI部件可以被重写以获得相应的URI引用字符串 使用伪码 如下 result if defined scheme then append scheme to result append to result endif if defined authority then append to result append authority to result endif append path to result if defined query then append to result append query to result endif if defined fragment then append to result append fragment to result endif return result 注意我们要小心地保持一个未定义的部件和一个空部件之间的区别 未定义的部件 意味着在当前的引用中它的分隔符不是当前的 空部件 意味着该分隔符是当前的但是被下一个部件分隔符紧接跟在它后面或者在该引用的尾部 引用解析示例 对于有良好定义的基础URI的以下URI的陈述中 http a b c d p q 一个相对引用被转换成它的目标URI如下 常规示例 g h g h g http a b c g g http a b c g g http a b c g g http a g g http g y http a b c d p y g y http a b c g y s http a b c d p q s g s http a b c g s g y s http a b c g y s x http a b c x g x http a b c g x g x y s http a b c g x y s http a b c d p q http a b c http a b c http a b http a b g http a b g http a http a g http a g 反常示例 尽管以下反常示例未必发生在常规的实践中 所有URI解析器应该有能力一致性地解析它们 每个例子使用和上述相同的基础 比起在基础URI的路径中有多个层次 解析器必须更加小心地处理在一个相对路径引用中有多个 分段的情况 注意 语法不能被用于改变一个URI的机构部件 g http a g g http a g 类似的 解析器必须移除点片段 和 当它们是一个路径的完整部件的时候 但不是当它们是一个片段的仅有的部分的时候 g http a g g http a g g http a b c g g http a b c g g http a b c g g http a b c g 更罕见的情况是相对引用使用 和 的不必要或无意义的格式完成路径片段 g http a b g g http a b c g g h http a b c g h g h http a b c h g x 1 y http a b c g x 1 y g x 1 y http a b c y 一些应用在合并路径部件和基础路径并移除点片段之前未能从该路径部件分离出该引用的查询 和 或 片段部件 这个错误很少被注意到 因为一个片段的典型用法永远不会包含层次 符号并且查询部件通常不被用在相对引用中 g y x http a b c g y x g y x http a b c g y x g s x http a b c g s x g s x http a b c g s x 一些解析器允许格式名在相对引用中使用 如果它和基础URI格式相同 在之前的部分URI协议 RFC1630 http tools ietf org html rfc1630 中它被认为是一个漏洞 应该避免它的使用但是允许向后兼容 http g http g for strict parsers http a b c g for backward compatibility 正规化和比较 在URIs上最常见的操作之一是简单比较 在不使用URIs访问它们各自的资源的情况下确定两个URIs是否等价 每次一个应答缓存被访问的时候就执行比较动作 一个浏览器检查它的历史来给一个链接着色 或一个XML解析器处理一个命名空间中的标签 在比较URIs之前进行广泛的正规化经常被用于蜘蛛和索引引擎以精简搜索空间或减少重复的请求动作和应答存储 URI比较被执行用于一些特别的目的 为不同目的而比较URIs的协议或实现将经常受限于不同的设计去权衡应该花多少努力去减少别名标识符 这一章描述可以用于比较URIs的各种方法 它们之间的权衡 以及可以使用它们的应用的类型 等价 因为URIs存在识别资源 当它们标识到相同的资源想必它们应该认为它们是等价的 无论如何 等价的这一定义实际上没有用得那么多 因为对一个实现来说除非有它们的全部只是或控制没办法比较两个资源 基于这个原因 URIs的等价或不同的确定是基于字符串比较的 可能被URI格式定义提供的额外规则的引用所增强 我们使用术语 不同 和 等价 来描述这以比较的可能的结果 但是有很多依赖于应用的版本的等价 即使有可能确定两个URIs是等价的 URI比较不足以确定两个URIs是否标识不同的资源 例如 两个不同的域名的同一个所有者可能决定两者同时服务于相同的资源 导致两个不同的URIs 所以 比较方法被定义用来最小化错误的否定从而严格地避免错误的肯定 对于等价的测试 应用应该不直接比较相对引用 引用应该在比较之前被转换成它们各自的目标URIs 当URIs被比较以选择 或避免 一个网络动作 类似展示的获取 片段部件 如果有 应该从比较中排除 比较阶梯 实践中用来测试URI等价的方法有很多变种 这些方法落在一个范围里 需要多少过程来区分和哪种方法更能减少错误的否定 如上所述 错误的否定无法避免 实践中 它们的可能性能被减少 但是这个减少要求更多的处理并且不是对所有应用都合算的 如果比较实践的范围被看作一个阶梯 接下来的讨论将攀登这个阶梯 开始的实践是廉价但是有相对高的机会产生错误的否定 然后去到那些有更高计算成本和更低的错误否定风险的实践 简单字符串比较 如果两个URIs 当被认为是字符串 并且相同 那么断定它们等价是安全的 这类等价的测试的计算成本非常低并且广泛用于各种应用 特别是在解析域名中 测试字符串的等价性需要一些基本的注意事项 这个过程经常被称为 每比特 或 每字节 比较 它是潜在的误导 测试字符串的等价性通常是基于构成该字符串的字符对 从第一个开始一直到两个字符串结束且发现所有字符都等价 或直到一对字符比较不等价 或字符串之一在另一个之前结束 这一字符比较需要每一对字符是以可比较的格式存放的 例如 一个URI应该被存储成一个以EBCDIC编码的字节数组而第二个URI被存储成一个Java字符串对象 UTF 16 天真地应用每比特比较将产生错误 等价比较的更好的说法是基于每字符而不是每字节或每比特 实际上 每字符比较应该是在转换成通用字符编码之后的每码点比较 错误的否定是由URI别名的生产和使用造成的 无关比较方法 通过在一个已常规化的格式中一致性地提供URI引用 即 和应用常规化之后被生产的格式相同的一个格式 如下所述 可以减少不必要的别名 协议和数据格式经常限制了一些URI比较去简化字符串比较 基于这个理论人们和应用将出于他们自己的最佳利益 一致性地提供URI引用 或至少一致到足够否决任何从更多常规化中获得的效率 基于语法的常规化 实现可以使用基于本协议提供的定义的逻辑来降低错误否定的可能性 这个过程的开销适度地高于每字符的字符串比较 例如 一个使用这个方法的应用可能合理地认为以下两个URIs是等价的 example a b c 7Bfoo 7D eXAMPLE a b b 63 7bfoo 7d Web用户代理 类似浏览器 当决定是否一个缓存的应答可用的时候典型地应用这类URI常规化 基于语法的常规化包括这类技术 如案例常规化 百分号常规化 以及移除点片段 大写常规化 对于所有URIs来说 一个百分号编码的三连符中的十六进制数字 例如 3a 和 3A 是大小写不敏感的并且因此应该使用大写字母来常规化数字 A F 当一个URI使用通用语法部件 该部件语法语法等价规则总是适用 亦即 格式和主机是大小写不敏感的并且因此应该被常规化成小写 例如 URI HTTP www EXAMPLE com 等价于 http www example com 其他通用语法部件被假定是大小写敏感的 除非由格式特别定义 见 6 2 3 百分号编码常规化 百分号编码机制 2 1 在其他相同的URIs中是一个频繁出现的来源 除了上面注意到的大写常规化问题 一些百分号编码八位字节的URI生产者不必需百分号编码 结果是那些URIs等价于它们的未编码部分 这些URIs应该被解码任何百分号编码来常规化以对应一个非保留的字符 如 2 3 所述 路径片段常规化 完整的路径片段 和 只打算用在相对引用中 4 1 并且会作为引用解析过程的一部分被移除 5 2 无论如何 一些已部署的实现不正确地假定当引用已经是一个URI的时候引用解析是不必要的 使得当它们遇到非相对路径时未能移除点片段 URI常规化者应该通过应用 移除点片段 算法来从该路径移除点片段 如 5 2 4 所述 基于格式的常规化 各个格式的URIs的语法和语义是不同的 如每个格式的定义协议所述 实现可以使用格式特有的规则 以更高的处理成本 来减少错误否定的可能性 例如 因为一个用于授权部件的 http 格式 有一个缺省端口 80 并且定义了一个空路径等价于 以下四个URIs是等价的 http example com http example com http example com http example com 80 通常 一个使用通用语法来授权一个空路径的URI应该被常规化成一个路径 同样 一个显式的 port 这里这个端口号是空的或对该格式是缺省的 等价于该端口和它的 分隔符被省略了 从而应该被基于格式的常规化移除 例如 上述第二个URI对于 http 格式来说是常规格式 另一种由格式导致常规化的不同的情形是空的机构部件或空主机子部件的处理中 对于某些格式协议 一个空机构或主机被认为是一个错误 对于另一些格式协议 它被认为等价于 localhost 或最终用户的主机 当一个格式为机构定义了一个缺省值并且需要一个URI引用那个缺省值 为了保证一致性 简洁和国际化 那个引用应被常规化成一个空的机构 如果 无论如何 如果用户信息或端口子部件是非空的 那么主机应该被明确给出 即使它和缺省值是一样的 常规化应该不移除分割符 当它们的相关部件是空的时候 除非该格式协议允许这么做 例如 URI http example com 不能被假定等价于上述的任何例子 同样的 在一个用户信息子部件中分割符的出现与否常常是和它的解释有明显的关系 片段部件不受任何基于格式的常规化 于是 两个只是后缀 不同的URIs被认为是不同的 这和该格式无关 一些格式定义的额外的子部件包含了大小写不敏感的数据 把一个隐含的授权给了常规化者来把这个数据转换成一个常用大小写 例如 全部小写 例如 定义了一个路径子部件以包含一个互联网主机名的URI格式 类似 mailto URI格式 因为那个子部件是大小写不敏感的并且从而遵循大小写格式化 例如 mailto Joe Example COM 等价于 mailto Joe example com 即使通用语法认为路径部件是大小写敏感的 其他格式特有的常规化也是可能的 基于协议的常规化 降低错误否定的发生率的主要工夫常常对web蜘蛛是很合算的 所以 它们在URI比较上甚至实现了更具侵略性的技术 例如 如果它们观察到一个如下的URI http example com data 重定向到了一个只是多了一个尾随的斜杠的URI http example com data 它们或许将在未来把这两者视为等价 这种技术只是在等价同时清楚地被访问该资源的结果和它们的格式的解参考算法的通用惯例表示出来的时候才适合 在这个例子中 由HTPP源服务器使用的重定向避免了相对引用的问题 安全事项 URI本身不会产生安全性的威胁 然而 因为URIs经常被用于提供一系列指示用于访问网络资源 必须小心地适当解释一个URI中的数据 以防止那个数据被意外地访问 并且避免包含不应该在纯文本中出现的数据 可靠性和一致性 一个URI被用于取回信息 不保证将来同样的信息可以被那个URI取回 也不保证未来通过那个URI可取回的数据会和过去取回的数据明显类似 URI语法不约束一个给定的格式或机构如何分配它的命名空间或维护它的超时 这类保证只能来自控制那个问题中的命名空间和资源的人 们 一个特定的URI格式可以定义额外的语义 类似名字持久化 如果那些语义对于那个格式的所有命名机构都是必需的话 恶意构造 有时可能会有人构造一个URI来尝试执行一个貌似有害的幂等操作 例如取回一个表示 将实际导致一个可能有害的远程操作 不安全的URI典型地是通过指定一个和网络协议的保留端口不同的端口号来构造的 客户端不知不觉地联系了一个运行了不同协议服务的网站 以及该URI包含的数据的指示 当根据另一个协议解释的时候 导致意外的操作 一个常见的此类例子是对基于协议的格式因而带有的端口号 25 的滥用 从而欺骗用户代理软件通过一个SMTP服务器发送一个意想不到的或假冒的消息 应用应该防止一个URI的解参考指定一个 广为人知的端口范围 0 1023 中的TCP端口 除非用来解参考那个URI的协议和那个端口上预期的协议是兼容的 尽管IANA维护了一个已知端口号的注册表 应用应该让这些约束成为用户可配置的以避免妨碍新服务的部署 当一个URI包含的百分号八位字节和用于给定的解释或解参考协议的分隔符匹配 例如 用于TELNET协议的 CR 和 LF 符号 在传输穿过那个协议之前这些百分号编码不能被解码 百分号编码的传输 它可能违反协议 的伤害可能低于允许被解码的八位字节被解释成额外的操作或参数 可能触发一个意外和可能有害的远程操作 后端转码 当一个URI被解参考 它里面的数据经常同时被用户代理和一个或多个服务器解析 在HTTP中 例如 一个典型的用户代理把一个URI解析成它的五个主要的部件 访问机构的服务器 并向它发送机构 路径和查询部件中的数据 一个典型的服务器将获得那些信息 把路径解析成片段并查询 键 值 对 然后调用实现特有的处理程序以应答该请求 结果是 对于处理一个作为整体或分离成独立部件的URI的服务器实现来说 一个常见的安全问题是 它是对那个URI中的字符串和百分号编码展示的八位字节数据的适当的解释 百分号字节在解参考过程中必须在某些点被解码 应用必须在解码这些字节之前把URI分离成它的部件和子部件 否则被解码的字节可能被误解为分隔符 在一个URI中的数据的安全性检查应该在字节被解码之后应用 记住 无论如何 00 百分号 空 可能要求特殊的处理并且如果应用不期望在一个部件里接收原数据则应该被拒绝 当URI路径解释过程包含了对后端文件系统或相关的系统功能的使用的时候应特别小心 文件系统典型地把一个可操作的含义赋予给特定的字符 例如 和 字符 以及特别的设备名类似 aux lpt 等等 在某些情况下 对这类名称的存在很少测试将导致操作系统暂停或请求和系统无关的调用 导致明显的拒绝服务和意外的数据传输的安全问题 有可能的话本协议将列出所有这类重要字符和设备名称 实现应该研究为可能被挂载到它们的应用的存储类型保留名称和字符并从而限制从URI部件获得的数据中使用它们 罕见的IP地址格式 尽管用于IPv4address的URI语法只允许常见的IPv4地址文字的 点 十进制 格式 很多处理URIs的实现使用了独立于平台的系统函数 例如 gethostbyname 和 inet aton 来把字符文字翻译成一个确切的IP地址 不幸的是 这类系统函数经常允许和处理比 3 2 2 中描述的格式更大的集合 例如 很多实现允许三个数字的点格式 其最后部分被解释为一个16比特的数量并被放到网络地址的最右边的两个字节 例如 一个B类网络 同样的 两个数字的点格式意味着最后部分被解释为一个24比特的数量并被放到地址的最右边的三个字节 A类 而一个单独的数字 没有点 被解释为一个32比特的数量并被直接存到网络地址 更多的混乱是 一些实现允许每个点部分被解释为十进制 八进制 或十六进制 特别是在C语言中 即 一个打头的 0x 或 0X 暗示一个十六进制 一个打头的 0 暗示八进制 否则 该数字被解释为十进制 在URi语法中不允许额外的IP地址格式是因为平台实现之间的不同 无论如何 如果一个应用尝试基于字符文本格式的IP地址过滤到资源的访问 它们可能成为一个安全问题 如果这个过滤被执行了 文字应该被转换成数字格式并基于数字值过滤 不要基于一个字符格式的前缀或后缀 敏感信息 URI制作者应该不提供包含了了通常保密的用户名和密码的URI URIs经常由浏览器显示 被存储成纯文本书签 并且被用户代理历史和中介应用 代理 记录了日志 在用户信息部件中包含密码是被反对的并且应该被视为一个错误 或简单地忽略 除非在那些罕见的情况下 password 参数才会公开出现 语义攻击 因为在机构部件中用户信息子部件在主机之前很少被使用和出现 它可能被用于构造一个URI来误导一个自然人用户 看似标识一个 可信的 命名机构 实际上标识一个隐藏在噪音后面的不同的机构 例如 ftp cnn example com story breaking news 10 0 0 1 top story htm 可能引导一个自然人用户假定该主机为 cnn example com 而它实际上是 10 0 0 1 注意一个误导的用户信息子部件可能比上述的例子更长 一个误导的URI 类似上面那个 是对用户对于一个URI的含义的先入为主的概念的攻击而不是对对该软件本身的攻击 用户代理可能可以通过在呈现该URI的多个部件的时候区别开它们来减少这类攻击的影响 例如通过使用不同的颜色或声音来呈现用户信息 如果有的话 尽管没有灵丹妙药 更多关于基于URI的语义的攻击可以在 Siedzik 找到 IANA事项 URI格式名称 在 Scheme 3 1 中的 scheme 定义 格式化一个根据 BCP35 定义的流程由IANA管理的已注册的命名空间 本文不需要任何IANA操作 致谢 本协议来源于 RFC 2396 RFC 1808 和 RFC 1738 那些文档中的致谢在本文仍然适用 本协议也合并了主机语法中的IPv6文字的更新 及修正 如 Robert M Hinden Brian E Carpenter 和 Larry Masinter 在 RFC2732 中定义的那样 另外 非常感谢下列人员的贡献 Gisle Aas Reese Anschultz Daniel Barclay Tim Bray Mike Brown Rob Cameron Jeremy Carroll Dan Connolly Adam M Costello John Cowan Jason Diamond Martin Duerst Stefan Eissing Clive D W Feather Al Gilman Tony Hammond Elliotte Harold Pat Hayes Henry Holtzman Ian B Jacobs Michael Kay John C Klensin Graham Klyne Dan Kohn Bruce Lilly Andrew Main Dave McAlpin Ira McDonald Michael Mealling Ray Merkert Stephen Pollei Julian Reschke Tomas Rokicki Miles Sabin Kai Schaetzl Mark Thomson Ronald Tschalaer Norm Walsh Marc Warne Stuart Williams 和 Henry Zongaro 参考 规范引用 ASCII American National Standards Institute Coded Character Set 7 bit American Standard Code for Information Interchange ANSI X3 4 1986 RFC2234 Crocker D and P Overell Augmented BNF for Syntax Specifications ABNF RFC 2234 November 1997 STD63 Yergeau F UTF 8 a transformation format of ISO 10646 STD 63 RFC 3629 November 2003 UCS International Organization for Standardization Information Technology Universal Multiple Octet Coded Character Set UCS ISO IEC 10646 2003 December 2003 参考文献 BCP19 Freed N and J Postel IANA Charset Registration Procedures BCP 19 RFC 2978 October 2000 BCP35 Petke R and I King Registration Procedures for URL Scheme Names BCP 35 RFC 2717 November 1999 RFC0952 Harrenstien K Stahl M and E Feinler DoD Internet host table specification RFC 952 October 1985 RFC1034 Mockapetris P Domain names concepts and facilities STD 13 RFC 1034 November 1987 RFC1123 Braden R Requirements for Internet Hosts Application and Support STD 3 RFC 1123 October 1989 RFC1535 Gavron E A Security Problem and Proposed Correction With Widely Deployed DNS Software RFC 1535 October 1993 RFC1630 Berners Lee T Universal Resource Identifiers in WWW A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World Wide Web RFC 1630 June 1994 RFC1736 Kunze J Functional Recommendations for Internet Resource Locators RFC 1736 February 1995 RFC1737 Sollins K and L Masinter Functional Requirements for Uniform Resource Names RFC 1737 December 1994 RFC1738 Berners Lee T Masinter L and M McCahill Uniform Resource Locators URL RFC 1738 December 1994 RFC1808 Fielding R Relative Uniform Resource Locators RFC 1808 June 1995 RFC2046 Freed N and N Borenstein Multipurpose Internet Mail Extensions MIME Part Two Media Types RFC 2046 November 1996 RFC2141 Moats R URN Syntax RFC 2141 May 1997 RFC2396 Berners Lee T Fielding R and L Masinter Uniform Resource Identifiers URI Generic Syntax RFC 2396 August 1998 RFC2518 Goland Y Whitehead E Faizi A Carter S and D Jensen HTTP Extensions for Distributed Authoring WEBDAV RFC 2518 February 1999 RFC2557 Palme J Hopmann A and N Shelness MIME Encapsulation of Aggregate Documents such as HTML MHTML RFC 2557 March 1999 RFC2718 Masinter L Alvestrand H Zigmond D and R Petke Guidelines for new URL Schemes RFC 2718 November 1999 RFC2732 Hinden R Carpenter B and L Masinter Format for Literal IPv6 Addresses in URL s RFC 2732 December 1999 RFC3305 Mealling M and R Denenberg Report from the Joint W3C IETF URI Planning Interest Group Uniform Resource Identifiers URIs URLs and Uniform Resource Names URNs Clarifications and Recommendations RFC 3305 August 2002 RFC3490 Faltstrom P Hoffman P and A Costello Internationalizing Domain Names in Applications IDNA RFC 3490 March 2003 RFC3513 Hinden R and S Deering Internet Protocol Version 6 IPv6 Addressing Architecture RFC 3513 April 2003 Siedzik Siedzik R Semantic Attacks What s in a URL April 2001 http www giac org practical gsec Richard Siedzik GSEC pdf 附录A 为URI收集的ABNF URI scheme hier part query fragment hier part authority path abempty path absolute path rootless path empty URI reference URI relative ref absolute URI scheme hier part query relative ref relative part query fragment relative part authority path abempty path absolute path noscheme path empty scheme ALPHA ALPHA DIGIT authority userinfo host port userinfo unreserved pct encoded sub delims host IP literal IPv4address reg name port DIGIT IP literal IPv6address IPvFuture IPvFuture v 1 HEXDIG 1 unreserved sub delims IPv6address 6 h16 ls32 5 h16 ls32 h16 4 h16 ls32 1 h16 h16 3 h16 ls32 2 h16 h16 2 h16 ls32 3 h16 h16 h16 ls32 4 h16 h16 ls32 5 h16 h16 h16 6 h16 h16 h16 1 4HEXDIG ls32 h16 h16 IPv4address IPv4address dec octet dec octet dec octet dec octet dec octet DIGIT 0 9 x31 39 DIGIT 10 99 1 2DIGIT 100 199 2 x30 34 DIGIT 200 249 25 x30 35 250 255 reg name unreserved pct encoded sub delims path path abempty begins with or is empty path absolute begins with but not path noscheme begins with a non colon segment path rootless begins with a segment path empty zero characters path abempty segment path absolute segment nz segment path noscheme segment nz nc segment path rootless segment nz segment path empty 0 pchar segment pchar segment nz 1 pchar segment nz nc 1 unreserved pct encoded sub delims non zero length segment without any

    Original URL path: http://wiki.jabbercn.org/index.php?title=RFC3986&printable=yes (2016-04-25)
    Open archived version from archive

  • 用户:Admin - Jabber/XMPP中文翻译计划
    差异 跳转到 导航 搜索 最近的OPENFIRE3 6 3支持了LDAP 但是有两个限制 安装的时候要选择内部数据库 就是hsql数据库 OPENFIRE对于LDAP是只读的 也就是说无法注册用户 解决的办法是 把LdapUserProvider java的isReadOnly只读特性改为false 然后把其中欠缺的createUser deleteUser setName setEmail方法补充完整 实现用户的新增 删除 修改昵称和邮箱 把LdapAuthProvider java欠缺的setPassword补充完整 实现修改密码 其他 待续 来自 http wiki jabbercn org index php title E7 94 A8 E6 88 B7 Admin oldid 50 查看 用户页面 讨论 查看源代码 历史 个人工具 登录 创建账户 导航 首页 社区专页 新闻动态 最近更改 随机页面 帮助 XMPP资源 XMPP公共服务 XMPP客户端软件 XMPP服务器软件 友情链接 搜索 站外搜索 工具箱 链入页面 链出更改 用户贡献

    Original URL path: http://wiki.jabbercn.org/index.php?title=%E7%94%A8%E6%88%B7:Admin&oldid=50 (2016-04-25)
    Open archived version from archive

  • 用户讨论:Admin - Jabber/XMPP中文翻译计划
    E6 88 B7 E8 AE A8 E8 AE BA Admin oldid 146 查看 用户页面 讨论 查看源代码 历史 个人工具 登录 创建账户 导航 首页 社区专页 新闻动态 最近更改 随机页面 帮助 XMPP资源 XMPP公共服务 XMPP客户端软件 XMPP服务器软件 友情链接 搜索 站外搜索 工具箱 链入页面 链出更改 用户贡献 日志 特殊页面

    Original URL path: http://wiki.jabbercn.org/%E7%94%A8%E6%88%B7%E8%AE%A8%E8%AE%BA:Admin (2016-04-25)
    Open archived version from archive



  •