Internet Engineering Task Force (IETF) A. Bryan
Request for Comments: 6249 N. McNab
Category: Standards Track T. Tsujikawa
ISSN: 2070-1721
P. Poeml
MirrorBrain
H. Nordstrom
June 2011
Internet Engineering Task Force (IETF) A. Bryan
Request for Comments: 6249 N. McNab
Category: Standards Track T. Tsujikawa
ISSN: 2070-1721
P. Poeml
MirrorBrain
H. Nordstrom
June 2011
Metalink/HTTP: Mirrors and Hashes
Metalink/HTTP：镜像和哈希
Abstract
摘要
This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements for Metalink/HTTP clients and servers are described here.
本文档在HTTP头字段中指定Metalink/HTTP:Mirrors和Cryptographic hash，这是获取通常包含在基于Metalink XML的下载描述格式中的信息的另一种方式。Metalink/HTTP使用HTTP头字段的现有标准描述多个下载位置（镜像）、对等、加密哈希、数字签名和其他信息。Metalink客户端可以使用此信息使文件传输更加健壮和可靠。此处描述了Metalink/HTTP客户端和服务器的规范性要求。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6249.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6249.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Example Metalink Server Response ...........................4
1.2. Notational Conventions .....................................4
1.3. Terminology ................................................5
2. Requirements ....................................................5
3. Mirrors / Multiple Download Locations ...........................7
3.1. Mirror Priority ............................................8
3.2. Mirror Geographical Location ...............................8
3.3. Coordinated Mirror Policies ................................8
3.4. Mirror Depth ...............................................9
4. Peer-to-Peer / Metainfo .........................................9
4.1. Metalink/XML Files ........................................10
5. Signatures .....................................................10
5.1. OpenPGP Signatures ........................................10
5.2. S/MIME Signatures .........................................10
6. Cryptographic Hashes of Whole Documents ........................11
7. Client / Server Multi-Source Download Interaction ..............11
7.1. Error Prevention, Detection, and Correction ...............15
7.1.1. Error Prevention (Early File Mismatch Detection) ...15
7.1.2. Error Correction ...................................16
8. IANA Considerations ............................................16
9. Security Considerations ........................................17
9.1. URIs and IRIs .............................................17
9.2. Spoofing ..................................................17
9.3. Cryptographic Hashes ......................................17
9.4. Signing ...................................................17
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
Appendix A. Acknowledgements and Contributors .....................20
1. Introduction ....................................................3
1.1. Example Metalink Server Response ...........................4
1.2. Notational Conventions .....................................4
1.3. Terminology ................................................5
2. Requirements ....................................................5
3. Mirrors / Multiple Download Locations ...........................7
3.1. Mirror Priority ............................................8
3.2. Mirror Geographical Location ...............................8
3.3. Coordinated Mirror Policies ................................8
3.4. Mirror Depth ...............................................9
4. Peer-to-Peer / Metainfo .........................................9
4.1. Metalink/XML Files ........................................10
5. Signatures .....................................................10
5.1. OpenPGP Signatures ........................................10
5.2. S/MIME Signatures .........................................10
6. Cryptographic Hashes of Whole Documents ........................11
7. Client / Server Multi-Source Download Interaction ..............11
7.1. Error Prevention, Detection, and Correction ...............15
7.1.1. Error Prevention (Early File Mismatch Detection) ...15
7.1.2. Error Correction ...................................16
8. IANA Considerations ............................................16
9. Security Considerations ........................................17
9.1. URIs and IRIs .............................................17
9.2. Spoofing ..................................................17
9.3. Cryptographic Hashes ......................................17
9.4. Signing ...................................................17
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
Appendix A. Acknowledgements and Contributors .....................20
Metalink/HTTP is an alternative and complementary representation of Metalink information, which is usually presented as an XML-based document format [RFC5854]. Metalink/HTTP attempts to provide as much functionality as the Metalink/XML format by using existing standards, such as Web Linking [RFC5988], Instance Digests in HTTP [RFC3230], and Entity Tags (also known as ETags) [RFC2616]. Metalink/HTTP is used to list information about a file to be downloaded. This can include lists of multiple URIs (mirrors), Peer-to-Peer information, cryptographic hashes, and digital signatures.
Metalink/HTTP是Metalink信息的一种替代和补充表示形式，通常以基于XML的文档格式[RFC5854]表示。Metalink/HTTP试图通过使用现有标准提供与Metalink/XML格式相同的功能，例如Web链接[RFC5988]、HTTP中的实例摘要[RFC3230]和实体标记（也称为etag）[RFC2616]。Metalink/HTTP用于列出有关要下载的文件的信息。这可以包括多个URI（镜像）、对等信息、加密哈希和数字签名的列表。
Identical copies of a file are frequently accessible in multiple locations on the Internet over a variety of protocols (such as FTP, HTTP, and Peer-to-Peer). In some cases, users are shown a list of these multiple download locations (mirrors) and must manually select a single one on the basis of geographical location, priority, or bandwidth. This distributes the load across multiple servers, and should also increase throughput and resilience. At times, however, individual servers can be slow, outdated, or unreachable, but this cannot be determined until the download has been initiated. Users will rarely have sufficient information to choose the most appropriate server and will often choose the first in a list, which might not be optimal for their needs, and will lead to a particular server getting a disproportionate share of load. The use of suboptimal mirrors can lead to the user canceling and restarting the download to try to manually find a better source. During downloads, errors in transmission can corrupt the file. There are no easy ways to repair these files. For large downloads, this can be extremely troublesome. Any of the number of problems that can occur during a download lead to frustration on the part of users.
通过各种协议（如FTP、HTTP和对等协议），可以在Internet上的多个位置访问文件的相同副本。在某些情况下，用户会看到这些多个下载位置（镜像）的列表，并且必须根据地理位置、优先级或带宽手动选择一个。这可以将负载分布到多个服务器上，还可以提高吞吐量和恢复能力。但是，有时个别服务器可能速度慢、过时或无法访问，但在下载启动之前无法确定这一点。用户很少有足够的信息来选择最合适的服务器，通常会选择列表中的第一个服务器，这可能不适合他们的需要，并且会导致特定服务器获得不成比例的负载份额。使用次优镜像可能会导致用户取消并重新启动下载，以尝试手动查找更好的源。在下载过程中，传输错误会损坏文件。修复这些文件没有简单的方法。对于大型下载，这可能会非常麻烦。下载过程中可能出现的任何问题都会让用户感到沮丧。
Some popular sites automate the process of selecting mirrors using DNS load balancing, both to approximately balance load between servers, and to direct clients to nearby servers with the hope that this improves throughput. Indeed, DNS load balancing can balance long-term server load fairly effectively, but it is less effective at delivering the best throughput to users when the bottleneck is not the server but the network.
一些流行的站点使用DNS负载平衡自动化选择镜像的过程，既可以大致平衡服务器之间的负载，也可以将客户端定向到附近的服务器，希望这样可以提高吞吐量。事实上，DNS负载平衡可以相当有效地平衡长期服务器负载，但当瓶颈不是服务器而是网络时，它在向用户提供最佳吞吐量方面的效率较低。
This document describes a mechanism by which the benefit of mirrors can be automatically and more effectively realized. All the information about a download, including mirrors, cryptographic hashes, digital signatures, and more can be transferred in coordinated HTTP header fields, hereafter referred to as a "Metalink". This Metalink transfers the knowledge of the download server (and mirror database) to the client. Clients can fall back to other mirrors if the current one has an issue. With this knowledge,
本文档描述了一种机制，通过该机制可以自动更有效地实现镜像的好处。有关下载的所有信息，包括镜像、加密哈希、数字签名等，都可以在协调的HTTP头字段（以下称为“Metalink”）中传输。此Metalink将下载服务器（和镜像数据库）的知识传输到客户端。如果当前镜像出现问题，客户端可以退回到其他镜像。有了这些知识,，
the client is enabled to work its way to a successful download even under adverse circumstances. All this can be done without complicated user interaction, and the download can be much more reliable and efficient. In contrast, a traditional HTTP redirect to a mirror conveys only minimal information -- one link to one server -- and there is no provision in the HTTP protocol to handle failures. Furthermore, in order to provide better load distribution across servers and potentially faster downloads to users, Metalink/HTTP facilitates multi-source downloads, where portions of a file are downloaded from multiple mirrors (and, optionally, Peer-to-Peer) simultaneously.
即使在不利的情况下，客户机也能够以自己的方式成功下载。所有这些都可以在没有复杂用户交互的情况下完成，并且下载可以更加可靠和高效。相比之下，传统的HTTP重定向到镜像只传递最小的信息（一个链接到一台服务器），HTTP协议中没有处理故障的规定。此外，为了在服务器之间提供更好的负载分布并可能更快地下载给用户，Metalink/HTTP促进了多源下载，其中文件的一部分同时从多个镜像（以及，可选地，对等镜像）下载。
Upon connection to a Metalink/HTTP server, a client will receive information about other sources of the same resource and a cryptographic hash of the whole resource. The client will then be able to request chunks of the file from the various sources, scheduling appropriately in order to maximize the download rate.
连接到Metalink/HTTP服务器后，客户机将收到关于同一资源的其他源的信息以及整个资源的加密哈希。然后，客户机将能够从各种来源请求文件块，并进行适当的调度，以最大化下载速率。
This example shows a brief Metalink server response with ETag, mirrors, Peer-to-Peer information, Metalink/XML, OpenPGP signature, and a cryptographic hash of the whole file:
此示例显示了一个简短的Metalink服务器响应，其中包含ETag、镜像、对等信息、Metalink/XML、OpenPGP签名和整个文件的加密哈希：
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Link: <http://www2.example.com/example.ext>; rel=duplicate
Link: <ftp://ftp.example.com/example.ext>; rel=duplicate
Link: <http://example.com/example.ext.torrent>; rel=describedby;
type="application/x-bittorrent"
Link: <http://example.com/example.ext.meta4>; rel=describedby;
type="application/metalink4+xml"
Link: <http://example.com/example.ext.asc>; rel=describedby;
type="application/pgp-signature"
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Link: <http://www2.example.com/example.ext>; rel=duplicate
Link: <ftp://ftp.example.com/example.ext>; rel=duplicate
Link: <http://example.com/example.ext.torrent>; rel=describedby;
type="application/x-bittorrent"
Link: <http://example.com/example.ext.meta4>; rel=describedby;
type="application/metalink4+xml"
Link: <http://example.com/example.ext.asc>; rel=describedby;
type="application/pgp-signature"
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
This specification describes conformance of Metalink/HTTP.
本规范描述了Metalink/HTTP的一致性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119], as scoped to those conformance targets.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中的描述进行解释，并适用于这些合规性目标。
The following terms, as used in this document, are defined here:
本文件中使用的以下术语定义如下：
o Metalink server: HTTP server that provides a Metalink in HTTP response header fields.
o Metalink服务器：在HTTP响应头字段中提供Metalink的HTTP服务器。
o Metalink : A collection of HTTP response header fields from a Metalink server, which is the reply to a GET or HEAD request from a client and which includes Link header fields listing mirrors and Instance Digests listing a cryptographic hash.
o Metalink：来自Metalink服务器的HTTP响应头字段的集合，它是对来自客户端的GET或HEAD请求的响应，包括列出镜像的链接头字段和列出加密哈希的实例摘要。
o Link header field: HTTP response header field, defined in [RFC5988], that can list mirrors and, potentially, other download methods for obtaining a file, along with digital signatures.
o 链接头字段：HTTP响应头字段，在[RFC5988]中定义，它可以列出镜像，也可以列出获取文件的其他下载方法以及数字签名。
o Instance Digest: HTTP response header field, defined in [RFC3230], that contains the cryptographic hash of a file, which is used by the Metalink client to verify the integrity of the file once the download has completed.
o 实例摘要：HTTP响应头字段，在[RFC3230]中定义，其中包含文件的加密哈希，下载完成后，Metalink客户端将使用该哈希验证文件的完整性。
o Entity Tag or ETag: HTTP response header field, defined in [RFC2616], that, if synchronized between the Metalink server and mirror servers, allows Metalink clients to provide advanced features.
o [RFC2616]中定义的实体标记或ETag:HTTP响应头字段，如果在Metalink服务器和镜像服务器之间同步，则允许Metalink客户端提供高级功能。
o Mirror server: Typically, FTP or HTTP servers that "mirror" the Metalink server, i.e., provide identical copies of (at least some) files that are also on the mirrored server.
o 镜像服务器：通常是“镜像”Metalink服务器的FTP或HTTP服务器，即提供镜像服务器上的（至少某些）文件的相同副本。
o Metalink clients: Applications that process Metalinks and use them to provide an improved download experience. They support HTTP and could also support other download protocols like FTP or various Peer-to-Peer methods.
o Metalink客户端：处理Metalink并使用它们提供改进的下载体验的应用程序。它们支持HTTP，还可以支持其他下载协议，如FTP或各种对等方法。
o Metalink/XML: An XML file that can contain similar information to an HTTP response header Metalink, such as mirrors and cryptographic hashes.
o Metalink/XML：一个XML文件，可以包含与HTTP响应头Metalink类似的信息，例如镜像和加密哈希。
In this context, "Metalink" refers to Metalink/HTTP, which consists of mirrors and cryptographic hashes in HTTP header fields as described in this document. "Metalink/XML" refers to the XML format described in [RFC5854].
在此上下文中，“Metalink”指的是Metalink/HTTP，它由本文档中描述的HTTP头字段中的镜像和加密哈希组成。“Metalink/XML”是指[RFC5854]中描述的XML格式。
Metalink resources include Link header fields [RFC5988] to present a list of mirrors in the response to a client request for the resource. Metalink servers MUST include the cryptographic hash of a resource via Instance Digests in HTTP [RFC3230]. Algorithms used in the Instance Digest field are registered in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" at <http://www.iana.org/>. This document restricts the use of these algorithms. SHA-256 and SHA-512 were added to the registry by [RFC5843]. Metalinks contain whole file hashes as described in Section 6, and MUST include SHA-256, as specified in [FIPS-180-3]. It MAY also include other hashes.
Metalink资源包括链接头字段[RFC5988]，用于在响应客户端对资源的请求时显示镜像列表。Metalink服务器必须通过HTTP[RFC3230]中的实例摘要包含资源的加密哈希。实例摘要字段中使用的算法在IANA注册表中注册，该注册表名为“超文本传输协议（HTTP）摘要算法值”，位于<http://www.iana.org/>. 本文件限制了这些算法的使用。[RFC5843]将SHA-256和SHA-512添加到注册表中。metalink包含第6节所述的整个文件哈希，并且必须包含[FIPS-180-3]中规定的SHA-256。它还可能包括其他散列。
Metalink servers are HTTP servers with one or more Metalink resources. Metalink servers MUST support the Link header fields for listing mirrors and MUST support Instance Digests in HTTP [RFC3230]. Metalink servers MUST return the same Link header fields and Instance Digests on HEAD requests. Metalink servers and their associated preferred mirror servers MUST all share the same ETag policy. Metalink servers and their associated normal mirror servers SHOULD all share the same ETag policy. (See Section 3.3 for the definition of "preferred" and "normal" mirror servers.) It is up to the administrator of the Metalink server to communicate the details of the shared ETag policy to the administrators of the mirror servers so that the mirror servers can be configured with the same ETag policy. To have the same ETag policy means that ETags are synchronized across servers for resources that are mirrored; i.e., byte-for-byte identical files will have the same ETag on mirrors that they have on the Metalink server. For example, it would be better to derive an ETag from a cryptographic hash of the file contents than on server-unique filesystem metadata. Metalink servers SHOULD offer Metalink/ XML documents that contain cryptographic hashes of parts of the file (and other information) if error recovery is desirable.
Metalink服务器是具有一个或多个Metalink资源的HTTP服务器。Metalink服务器必须支持列出镜像的链接头字段，并且必须支持HTTP[RFC3230]中的实例摘要。Metalink服务器必须在HEAD请求上返回相同的链接头字段和实例摘要。Metalink服务器及其关联的首选镜像服务器必须共享相同的ETag策略。Metalink服务器及其关联的普通镜像服务器都应共享相同的ETag策略。（有关“首选”和“普通”镜像服务器的定义，请参见第3.3节。）由Metalink服务器的管理员向镜像服务器的管理员传达共享ETag策略的详细信息，以便可以使用相同的ETag策略配置镜像服务器。拥有相同的ETag策略意味着ETag在镜像资源的服务器之间同步；i、 例如，逐字节相同的文件在镜像上的ETag与在Metalink服务器上的ETag相同。例如，从文件内容的加密散列派生ETag比从服务器唯一的文件系统元数据派生ETag更好。如果需要错误恢复，Metalink服务器应该提供包含文件部分（和其他信息）加密哈希的Metalink/XML文档。
Mirror servers are typically FTP or HTTP servers that "mirror" another server. That is, they provide identical copies of (at least some) files that are also on the mirrored server. Mirror servers SHOULD support serving partial content. HTTP mirror servers SHOULD share the same ETag policy as the originating Metalink server. HTTP mirror servers SHOULD support Instance Digests in HTTP [RFC3230] using the same algorithm as the Metalink server. Optimally, HTTP mirror servers will share the same ETag policy and support Instance Digests in HTTP. Mirror servers that share the same ETag policy and/or support Instance Digests in HTTP using the same algorithm as a Metalink server are known as preferred mirror servers.
镜像服务器通常是“镜像”另一台服务器的FTP或HTTP服务器。也就是说，它们提供同样位于镜像服务器上的（至少某些）文件的相同副本。镜像服务器应支持服务部分内容。HTTP镜像服务器应与原始Metalink服务器共享相同的ETag策略。HTTP镜像服务器应使用与Metalink服务器相同的算法支持HTTP[RFC3230]中的实例摘要。最佳情况下，HTTP镜像服务器将共享相同的ETag策略，并支持HTTP中的实例摘要。使用与Metalink服务器相同的算法在HTTP中共享相同ETag策略和/或支持实例摘要的镜像服务器称为首选镜像服务器。
Metalink clients use the mirrors provided by a Metalink server in Link header fields [RFC5988] but these clients are restricted to using the mirrors provided by the initial Metalink server they
Metalink客户端使用链接头字段[RFC5988]中Metalink服务器提供的镜像，但这些客户端仅限于使用它们所使用的初始Metalink服务器提供的镜像
contacted. If Metalink clients find Link header fields [RFC5988] from mirrors that in turn list mirrors, or from a Metalink server listing itself as a mirror, they MUST discard such Link header fields [RFC5988] to prevent a possible infinite loop. Metalink clients MUST support HTTP and SHOULD support FTP [RFC0959]. Metalink clients MAY support BitTorrent [BITTORRENT] or other download methods. Metalink clients SHOULD switch downloads from one mirror to another if a mirror becomes unreachable. Metalink clients MAY support multi-source, or parallel, downloads, where portions of a file can be downloaded from multiple mirrors simultaneously (and, optionally, from Peer-to-Peer sources). Metalink clients MUST support Instance Digests in HTTP [RFC3230] by requesting and verifying cryptographic hashes. Metalink clients SHOULD support error recovery by using the cryptographic hashes of parts of the file listed in Metalink/XML files. Metalink clients SHOULD support checking digital signatures.
联络。如果Metalink客户端从依次列出镜像的镜像或从将自身列为镜像的Metalink服务器中找到链接头字段[RFC5988]，则它们必须放弃此类链接头字段[RFC5988]，以防止可能的无限循环。Metalink客户端必须支持HTTP，并应支持FTP[RFC0959]。Metalink客户端可能支持BitTorrent[BitTorrent]或其他下载方法。如果无法访问镜像，Metalink客户端应将下载从一个镜像切换到另一个镜像。Metalink客户端可能支持多源或并行下载，其中文件的一部分可以同时从多个镜像下载（也可以选择从对等源下载）。Metalink客户端必须通过请求和验证加密哈希来支持HTTP[RFC3230]中的实例摘要。Metalink客户端应该通过使用Metalink/XML文件中列出的文件部分的加密哈希来支持错误恢复。Metalink客户端应支持检查数字签名。
Mirrors are specified with the Link header fields [RFC5988] and a relation type of "duplicate" as defined in Section 8.
镜像由链接头字段[RFC5988]和第8节中定义的“复制”关系类型指定。
The following list contains OPTIONAL attributes, which are defined elsewhere in this document:
以下列表包含本文档其他地方定义的可选属性：
o "depth" : mirror depth (see Section 3.4).
o “深度”：镜像深度（见第3.4节）。
o "geo" : mirror geographical location (see Section 3.2).
o “地理”：反映地理位置（见第3.2节）。
o "pref" : a preferred mirror server (see Section 3.3).
o “pref”：首选镜像服务器（请参见第3.3节）。
o "pri" : mirror priority (see Section 3.1).
o “pri”：镜像优先级（见第3.1节）。
This example shows a brief Metalink server response with two mirrors only:
此示例显示仅具有两个镜像的简短Metalink服务器响应：
Link: <http://www2.example.com/example.ext>; rel=duplicate;
pri=1; pref
Link: <ftp://ftp.example.com/example.ext>; rel=duplicate;
pri=2; geo=gb; depth=1
Link: <http://www2.example.com/example.ext>; rel=duplicate;
pri=1; pref
Link: <ftp://ftp.example.com/example.ext>; rel=duplicate;
pri=2; geo=gb; depth=1
As some organizations can have many mirrors, it is up to the organization to configure the amount of Link header fields the Metalink server will provide. Such a decision could be a random selection or a hard-coded limit based on network proximity, file size, server load, or other factors.
由于某些组织可以有许多镜像，因此由该组织来配置Metalink服务器将提供的链接头字段的数量。这样的决定可能是随机选择，也可能是基于网络邻近性、文件大小、服务器负载或其他因素的硬编码限制。
Entries for mirror servers MAY have a "pri" value to designate the priority of a mirror. Valid ranges for the "pri" attribute are from 1 to 999999. Mirror servers with a lower value of the "pri" attribute have a higher priority, while mirrors with an undefined "pri" attribute are considered to have a value of 999999, which is the lowest priority. For example, a mirror with "pri=10" has higher priority than a mirror with "pri=20". Metalink clients SHOULD use mirrors with lower "pri" values first, but depending on other conditions, they MAY decide to use other mirrors.
镜像服务器的条目可能有一个“pri”值来指定镜像的优先级。“pri”属性的有效范围为1到999999。具有较低“pri”属性值的镜像服务器具有较高的优先级，而具有未定义“pri”属性的镜像被视为具有最低优先级的值999999。例如，“pri=10”的镜像比“pri=20”的镜像具有更高的优先级。Metalink客户端应首先使用“pri”值较低的镜像，但根据其他条件，它们可能会决定使用其他镜像。
This is purely an expression of the server's preferences; it is up to the client what it does with this information, particularly with reference to how many servers to use at any one time.
这纯粹是服务器偏好的表达；这取决于客户机如何处理这些信息，特别是一次要使用多少台服务器。
Entries for a mirror server MAY have a "geo" value, which is an [ISO3166-1] alpha-2 two-letter country code for the geographical location of the physical server the URI is used to access. A client MAY use this information to select a mirror, or set of mirrors, that is geographically near (if the client has access to such information), with the aim of reducing network load at inter-country bottlenecks.
镜像服务器的条目可能有一个“geo”值，这是一个[ISO3166-1]alpha-2两个字母的国家代码，表示URI用于访问的物理服务器的地理位置。客户机可以使用此信息选择地理位置附近的镜像或镜像集（如果客户机可以访问此类信息），以减少国家间瓶颈处的网络负载。
There are two types of mirror servers: preferred and normal. Entries for preferred HTTP mirror servers have a "pref" value and entries for normal mirrors don't. Preferred mirror servers are HTTP mirror servers that MUST share the same ETag policy as the originating Metalink server, or if the ETag is not used MUST provide an Instance Digest using the same algorithm as the Metalink server. Preferred mirrors make it possible for Metalink clients to detect early on, before data is transferred, if the file requested matches the desired file. This early file mismatch detection is described in Section 7.1.1. Normal mirrors do not necessarily share the same ETag policy or support Instance Digests using the same algorithm as the Metalink server. FTP mirrors are considered "normal", as they do not emit ETags or support Instance Digests.
镜像服务器有两种类型：首选和普通。首选HTTP镜像服务器的条目具有“pref”值，而普通镜像的条目则没有。首选镜像服务器是HTTP镜像服务器，它们必须与原始Metalink服务器共享相同的ETag策略，或者如果未使用ETag，则必须使用与Metalink服务器相同的算法提供实例摘要。首选镜像使Metalink客户端能够在传输数据之前尽早检测请求的文件是否与所需文件匹配。第7.1.1节介绍了早期文件不匹配检测。普通镜像不一定与Metalink服务器共享相同的ETag策略或支持使用相同算法的实例摘要。FTP镜像被认为是“正常的”，因为它们不发出ETag或支持实例摘要。
Some mirrors can mirror single files, whole directories, or multiple directories.
某些镜像可以镜像单个文件、整个目录或多个目录。
Entries for mirror servers can have a "depth" value, where "depth=0" is the default. A value of 0 means that only that file is mirrored and that other URI path segments are not. A value of 1 means that the file and all other files and URI path segments contained in the rightmost URI path segment are mirrored. For values of N, N-1 URI path segments closer to the Host are mirrored. A value of 2 means one URI path segment closer to the Host is mirrored, and all files and URI path segments contained are mirrored. For each higher value, another URI path segment closer to the Host is mirrored.
镜像服务器的条目可以有一个“depth”值，其中“depth=0”是默认值。值0表示只有该文件被镜像，而其他URI路径段不被镜像。值为1表示该文件以及包含在最右侧URI路径段中的所有其他文件和URI路径段都被镜像。对于N的值，将镜像靠近主机的N-1 URI路径段。值为2表示镜像靠近主机的一个URI路径段，并且镜像包含的所有文件和URI路径段。对于每一个更高的值，都会镜像靠近主机的另一个URI路径段。
This example shows a mirror with a depth value of 4:
此示例显示深度值为4的镜像：
Link: <http://www2.example.com/dir1/dir2/dir3/dir4/dir5/example.ext>;
rel=duplicate; pri=1; pref; depth=4
Link: <http://www2.example.com/dir1/dir2/dir3/dir4/dir5/example.ext>;
rel=duplicate; pri=1; pref; depth=4
In the above example, four URI path segments closer to the Host are mirrored, from /dir2/ and all files and directories included.
在上面的示例中，从/dir2/镜像靠近主机的四个URI路径段，并包括所有文件和目录。
Entries for metainfo files, which describe ways to download a file over Peer-to-Peer networks or otherwise, are specified with the Link header fields [RFC5988] and a relation type of "describedby" and a type parameter that indicates the MIME type of the metadata available at the URI. Since metainfo files can sometimes describe multiple files, or the filename MAY not be the same on the Metalink server and in the metainfo file but MAY still have the same content, an OPTIONAL "name" attribute can be used.
metainfo文件的条目描述了通过对等网络或其他方式下载文件的方法，通过链接头字段[RFC5988]和关系类型“describedby”以及表示URI上可用元数据MIME类型的类型参数指定。由于metainfo文件有时可以描述多个文件，或者Metalink服务器和metainfo文件中的文件名可能不同，但内容可能相同，因此可以使用可选的“名称”属性。
The following list contains an OPTIONAL attribute, which is defined in this document:
以下列表包含本文档中定义的可选属性：
o "name" : a file described within the metainfo file.
o “名称”：metainfo文件中描述的文件。
This example shows a brief Metalink server response with .torrent and .meta4:
此示例显示了带有.torrent和.meta4的简短Metalink服务器响应：
Link: <http://example.com/example.ext.torrent>; rel=describedby;
type="application/x-bittorrent"; name="differentname.ext"
Link: <http://example.com/example.ext.meta4>; rel=describedby;
type="application/metalink4+xml"
Link: <http://example.com/example.ext.torrent>; rel=describedby;
type="application/x-bittorrent"; name="differentname.ext"
Link: <http://example.com/example.ext.meta4>; rel=describedby;
type="application/metalink4+xml"
Metalink clients MAY support the use of metainfo files for downloading files.
Metalink客户端可能支持使用metainfo文件下载文件。
Metalink/XML files for a given resource MAY be provided in a Link header field as shown in the example in Section 4. Metalink/XML files are specified in [RFC5854], and they are particularly useful for providing metadata such as cryptographic hashes of parts of a file, allowing a client to recover from errors (see Section 7.1.2). Metalink servers SHOULD provide Metalink/XML files with partial file hashes in Link header fields, and Metalink clients SHOULD use them for error recovery.
给定资源的Metalink/XML文件可以在链接头字段中提供，如第4节中的示例所示。[RFC5854]中指定了Metalink/XML文件，它们对于提供元数据（如文件部分的加密哈希）特别有用，从而允许客户端从错误中恢复（请参阅第7.1.2节）。Metalink服务器应在链接头字段中提供包含部分文件哈希的Metalink/XML文件，Metalink客户端应使用它们进行错误恢复。
OpenPGP signatures [RFC3156] of requested files are specified with the Link header fields [RFC5988] and a relation type of "describedby" and a type parameter of "application/pgp-signature".
请求文件的OpenPGP签名[RFC3156]由链接头字段[RFC5988]和关系类型“describedby”以及类型参数“application/pgp signature”指定。
This example shows a brief Metalink server response with OpenPGP signature only:
此示例显示仅具有OpenPGP签名的简短Metalink服务器响应：
Link: <http://example.com/example.ext.asc>; rel=describedby;
type="application/pgp-signature"
Link: <http://example.com/example.ext.asc>; rel=describedby;
type="application/pgp-signature"
Metalink clients SHOULD support the use of OpenPGP signatures.
Metalink客户端应支持使用OpenPGP签名。
Secure/Multipurpose Internet Mail Extensions (S/MIME) signatures [RFC5751] of requested files are specified with the Link header fields [RFC5988] and a relation type of "describedby" and a type parameter of "application/pkcs7-mime".
请求文件的安全/多用途Internet Mail Extensions（S/MIME）签名[RFC5751]由链接头字段[RFC5988]和关系类型“describedby”以及类型参数“application/pkcs7 MIME”指定。
This example shows a brief Metalink server response with S/MIME signature only:
此示例显示仅具有S/MIME签名的简短Metalink服务器响应：
Link: <http://example.com/example.ext.p7m>; rel=describedby;
type="application/pkcs7-mime"
Link: <http://example.com/example.ext.p7m>; rel=describedby;
type="application/pkcs7-mime"
Metalink clients SHOULD support the use of S/MIME signatures.
Metalink客户端应支持使用S/MIME签名。
If Instance Digests are not provided by the Metalink servers, the Link header fields pertaining to this specification MUST be ignored.
如果Metalink服务器未提供实例摘要，则必须忽略与此规范相关的链接头字段。
This example shows a brief Metalink server response with ETag, mirror, and cryptographic hash:
此示例显示了带有ETag、镜像和加密哈希的简短Metalink服务器响应：
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Link: <http://www2.example.com/example.ext>; rel=duplicate
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Link: <http://www2.example.com/example.ext>; rel=duplicate
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
Metalink clients begin a download with a standard HTTP [RFC2616] GET request to the Metalink server. Metalink clients MAY use a range limit if desired.
Metalink客户端通过向Metalink服务器发出标准HTTP[RFC2616]GET请求开始下载。如果需要，Metalink客户端可以使用范围限制。
GET /distribution/example.ext HTTP/1.1
Host: www.example.com
GET /distribution/example.ext HTTP/1.1
Host: www.example.com
The Metalink server responds with the data and these header fields:
Metalink服务器将使用数据和以下标题字段进行响应：
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 14867603
Content-Type: application/x-cd-image
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Link: <http://www2.example.com/example.ext>; rel=duplicate; pref
Link: <ftp://ftp.example.com/example.ext>; rel=duplicate
Link: <http://example.com/example.ext.torrent>; rel=describedby;
type="application/x-bittorrent"
Link: <http://example.com/example.ext.meta4>; rel=describedby;
type="application/metalink4+xml"
Link: <http://example.com/example.ext.asc>; rel=describedby;
type="application/pgp-signature"
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 14867603
Content-Type: application/x-cd-image
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Link: <http://www2.example.com/example.ext>; rel=duplicate; pref
Link: <ftp://ftp.example.com/example.ext>; rel=duplicate
Link: <http://example.com/example.ext.torrent>; rel=describedby;
type="application/x-bittorrent"
Link: <http://example.com/example.ext.meta4>; rel=describedby;
type="application/metalink4+xml"
Link: <http://example.com/example.ext.asc>; rel=describedby;
type="application/pgp-signature"
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
Alternatively, Metalink clients can begin with a HEAD request to the Metalink server to discover mirrors via Link header fields and then skip to making the following decisions on every available mirror server found via the Link header fields.
或者，Metalink客户端可以先向Metalink服务器发出HEAD请求，通过链接头字段发现镜像，然后跳到对通过链接头字段找到的每个可用镜像服务器做出以下决定。
After that, the client follows with a GET request to the desired mirrors.
之后，客户机会向所需镜像发出GET请求。
From the Metalink server response, the client learns some or all of the following metadata about the requested object, in addition to starting to receive the object:
从Metalink服务器响应中，客户机除了开始接收对象外，还了解以下有关请求对象的部分或全部元数据：
o Mirror locations, with optional attributes describing the mirror's priority, whether it shares the ETag policy of the originating Metalink server, geographical location, and mirror depth.
o 镜像位置，具有描述镜像优先级的可选属性，包括镜像是否共享原始Metalink服务器的ETag策略、地理位置和镜像深度。
o Instance Digest, which is the whole file cryptographic hash.
o 实例摘要，它是整个文件加密哈希。
o ETag.
o 埃塔格。
o Object size from the Content-Length header field.
o “内容长度”标题字段中的对象大小。
o Metalink/XML, which can include partial file cryptographic hashes to repair a file.
o Metalink/XML，它可以包含用于修复文件的部分文件加密哈希。
o Peer-to-Peer information.
o 点对点信息。
o Digital signature.
o 数字签名。
Next, the Metalink client requests a range of the object from a preferred mirror server, so it can use If-Match conditions:
接下来，Metalink客户端从首选镜像服务器请求对象的范围，以便在符合以下条件时使用：
GET /example.ext HTTP/1.1
Host: www2.example.com
Range: bytes=7433802-
If-Match: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Referer: http://www.example.com/distribution/example.ext
GET /example.ext HTTP/1.1
Host: www2.example.com
Range: bytes=7433802-
If-Match: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Referer: http://www.example.com/distribution/example.ext
Metalink clients SHOULD use preferred mirrors, if possible, as they allow early file mismatch detection as described in Section 7.1.1. Preferred mirrors have coordinated ETags, as described in Section 3.3, and Metalink clients SHOULD use If-Match conditions based on the ETag to quickly detect out-of-date mirrors by using the ETag from the Metalink server response. Metalink clients SHOULD use partial file cryptographic hashes as described in Section 7.1.2, if available, to detect if the mirror server returned the correct data.
Metalink客户端应尽可能使用首选镜像，因为它们允许早期检测文件不匹配，如第7.1.1节所述。首选镜像具有协调的ETag，如第3.3节所述，Metalink客户端应使用基于ETag的If Match条件，通过使用Metalink服务器响应中的ETag快速检测过期镜像。Metalink客户端应使用第7.1.2节所述的部分文件加密哈希（如果可用）来检测镜像服务器是否返回了正确的数据。
Optimally, the mirror server also will include an Instance Digest in the mirror response to the client GET request, which the client can also use to detect a mismatch early. Metalink clients MUST reject individual downloads from mirrors that support Instance Digests if the Instance Digest from the mirror does not match the Instance Digest as reported by the Metalink server and the same algorithm is
最佳情况下，镜像服务器还将在对客户机GET请求的镜像响应中包含实例摘要，客户机也可以使用该摘要及早检测不匹配。如果镜像中的实例摘要与Metalink服务器报告的实例摘要不匹配，并且使用了相同的算法，则Metalink客户端必须拒绝从支持实例摘要的镜像中单独下载
used. If normal mirrors are used, then a mismatch cannot be detected until the completed object is verified. Errors in transmission and substitutions of incorrect data on mirrors, whether deliberate or accidental, can be detected with error correction as described in Section 7.1.2.
习惯于如果使用普通镜像，则在验证完成的对象之前无法检测到不匹配。通过第7.1.2节所述的纠错，可以检测到镜子上传输和替换错误数据的错误，无论是故意的还是意外的。
Here, the preferred mirror server has the correct file (the If-Match conditions match) and responds with a 206 Partial Content HTTP status code and appropriate "Content-Length", "Content-Range", ETag, and Instance Digest header fields. In this example, the mirror server responds, with data, to the above request:
这里，首选镜像服务器具有正确的文件（如果匹配条件匹配），并使用206部分内容HTTP状态代码和适当的“内容长度”、“内容范围”、ETag和实例摘要头字段进行响应。在此示例中，镜像服务器使用数据响应上述请求：
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 7433801
Content-Range: bytes 7433802-14867602/14867603
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 7433801
Content-Range: bytes 7433802-14867602/14867603
Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
Digest: SHA-256=MWVkMWQxYTRiMzk5MDQ0MzI3NGU5NDEyZTk5OWY1ZGFmNzgyZTJlO
DYzYjRjYzFhOTlmNTQwYzI2M2QwM2U2MQ==
Metalink clients MAY start a number of parallel range requests (one per selected mirror server other than the first) using mirrors provided by the Link header fields with "duplicate" relation type. Metalink clients MUST limit the number of parallel connections to mirror servers, ideally based on observing how the aggregate throughput changes as connections are opened. It would be pointless to blindly open connections once the path bottleneck is filled. After establishing a new connection, a Metalink client SHOULD monitor whether the aggregate throughput increases over all connections that are part of the download. The client SHOULD NOT open additional connections during this period. If the aggregate throughput has increased, the client MAY open an additional connection and repeat these steps. Otherwise, the client SHOULD NOT open a new connection until an established one closes. Metalink clients SHOULD use the location of the original GET request in the "Referer" header field for these range requests.
Metalink客户端可以使用链接头字段提供的镜像启动多个并行范围请求（每个选定的镜像服务器一个，而不是第一个镜像服务器），这些镜像具有“复制”关系类型。Metalink客户端必须限制到镜像服务器的并行连接数，理想情况下是根据观察连接打开时聚合吞吐量的变化。一旦路径瓶颈被填满，盲目打开连接是毫无意义的。建立新连接后，Metalink客户端应监视作为下载一部分的所有连接的聚合吞吐量是否增加。在此期间，客户端不应打开其他连接。如果聚合吞吐量增加，客户端可能会打开额外的连接并重复这些步骤。否则，在已建立的连接关闭之前，客户端不应打开新连接。Metalink客户端应该在这些范围请求的“Referer”头字段中使用原始GET请求的位置。
The Metalink client can determine the size and number of ranges requested from each server, based upon the type and number of mirrors and performance observed from each mirror. Note that range requests impose an overhead on servers, and clients need to be aware of that and not abuse them. When downloading a particular file, Metalink clients MUST NOT make more than one concurrent request to each mirror server from which it downloads.
Metalink客户端可以根据镜像的类型和数量以及从每个镜像观察到的性能，确定从每个服务器请求的范围的大小和数量。请注意，范围请求会给服务器带来开销，客户端需要意识到这一点，而不是滥用它们。下载特定文件时，Metalink客户端不得向从中下载的每个镜像服务器发出多个并发请求。
Metalink clients SHOULD close all but the fastest connection if any range requests generated after the first request end up with a complete response, instead of a partial response (as some mirrors
如果在第一个请求之后生成的任何范围请求最终得到完整响应，而不是部分响应（如某些镜像所示），则Metalink客户端应关闭除最快连接以外的所有连接
might not support HTTP ranges), if the goal is the fastest transfer. Metalink clients MAY monitor mirror conditions and dynamically switch between mirrors to achieve the fastest download possible. Similarly, Metalink clients SHOULD abort extremely slow or stalled range requests and finish the request on other mirrors. If all ranges have finished except for the final one, the Metalink client can split the final range into multiple range requests to other mirrors so the transfer finishes faster.
可能不支持HTTP范围），如果目标是最快的传输。Metalink客户端可以监视镜像条件并在镜像之间动态切换，以实现尽可能快的下载。类似地，Metalink客户端应该中止非常慢或暂停的范围请求，并在其他镜像上完成该请求。如果除最后一个范围外，所有范围都已完成，则Metalink客户端可以将最终范围拆分为多个到其他镜像的范围请求，以便传输更快完成。
If the first request was a GET, no Range header field was sent, and the client determines later that it will issue a range request, then the client SHOULD close the first connection when it catches up with the other parallel range requests of the same object. This means the first connection was sacrificed. Metalink clients can use a HEAD request first, if possible, so that the client can find out if there are any Link header fields, and then range-based requests are undertaken to the mirror servers without sacrificing a first connection.
如果第一个请求是GET，未发送任何范围标头字段，并且客户端稍后确定将发出范围请求，则客户端应在赶上同一对象的其他并行范围请求时关闭第一个连接。这意味着牺牲了第一个连接。如果可能的话，Metalink客户端可以首先使用HEAD请求，以便客户端可以查明是否存在任何链接头字段，然后在不牺牲第一次连接的情况下向镜像服务器执行基于范围的请求。
Metalink clients MUST reject individual downloads from mirrors where the file size does not match the file size as reported by the Metalink server.
如果文件大小与Metalink服务器报告的文件大小不匹配，Metalink客户端必须拒绝从镜像进行的个别下载。
If a Metalink client does not support certain download methods (such as FTP or BitTorrent) that a file is available from, and there are no available download methods that the client supports, then the download will have no way to complete.
如果Metalink客户端不支持文件可从中下载的某些下载方法（如FTP或BitTorrent），并且客户端不支持可用的下载方法，则下载将无法完成。
Metalink clients MUST verify the cryptographic hash of the file once the download has completed. If the cryptographic hash offered by the Metalink server with Instance Digests does not match the cryptographic hash of the downloaded file, see Section 7.1.2 for a possible way to repair errors.
下载完成后，Metalink客户端必须验证文件的加密哈希。如果Metalink服务器提供的带有实例摘要的加密哈希与下载文件的加密哈希不匹配，请参阅第7.1.2节，了解修复错误的可能方法。
If the download cannot be repaired, it is considered corrupt. The client can attempt to re-download the file.
如果无法修复下载，则认为它已损坏。客户端可以尝试重新下载该文件。
Metalink clients that support verifying digital signatures MUST verify digital signatures of requested files if they are included. Digital signatures MUST validate back to a trust anchor as described in the validation rules in [RFC3156] and [RFC5280].
支持验证数字签名的Metalink客户端必须验证所请求文件的数字签名（如果包括这些文件）。数字签名必须按照[RFC3156]和[RFC5280]中的验证规则验证回信任锚。
Error prevention, or early file mismatch detection, is possible before file transfers with the use of file sizes, ETags, and Instance Digests provided by Metalink servers. Error detection requires Instance Digests to detect errors in transfer after the transfers have completed. Error correction, or download repair, is possible with partial file cryptographic hashes.
通过使用Metalink服务器提供的文件大小、etag和实例摘要，可以在文件传输之前进行错误预防或早期文件不匹配检测。错误检测要求实例摘要在传输完成后检测传输中的错误。使用部分文件加密散列可以进行错误更正或下载修复。
Note that cryptographic hashes obtained from Instance Digests are in base64 encoding, while those from Metalink/XML are in hexadecimal.
请注意，从实例摘要中获得的加密哈希采用base64编码，而从Metalink/XML中获得的加密哈希采用十六进制。
In HTTP terms, the merging of ranges from multiple responses SHOULD be verified with a strong validator, which in this context is either an Instance Digest or a shared ETag from that Metalink server that matches with the Instance Digest or ETag provided by a preferred mirror server. In most cases, it is sufficient that the Metalink server provides mirrors and Instance Digest information, but operation will be more robust and efficient if the mirror servers do implement a shared ETag policy or Instance Digests as well. There is no need to specify how the ETag is generated, just that it needs to be shared between the Metalink server and the mirror servers. The benefit of having mirror servers return an Instance Digest is that the client then can detect mismatches early even if ETags are not used. Mirrors that support both a shared ETag and Instance Digests do provide value, but just one is sufficient for early detection of mismatches. If the mirror server provides neither shared ETag nor Instance Digest, then early detection of mismatches is not possible unless file length also differs. Finally, errors are still detectable after the download has completed, when the cryptographic hash of the merged response is verified.
在HTTP术语中，来自多个响应的范围的合并应使用强验证器进行验证，在本上下文中，强验证器是来自Metalink服务器的实例摘要或共享ETag，与首选镜像服务器提供的实例摘要或ETag相匹配。在大多数情况下，Metalink服务器提供镜像和实例摘要信息就足够了，但如果镜像服务器也实现共享ETag策略或实例摘要，则操作将更加健壮和高效。无需指定ETag的生成方式，只需在Metalink服务器和镜像服务器之间共享。让镜像服务器返回实例摘要的好处是，即使未使用ETag，客户端也可以及早检测到不匹配。同时支持共享ETag和实例摘要的镜像确实提供了价值，但只有一个镜像就足以早期检测不匹配。如果镜像服务器既不提供共享ETag也不提供实例摘要，则除非文件长度也不同，否则无法早期检测不匹配。最后，下载完成后，当验证合并响应的加密散列时，仍然可以检测到错误。
ETags cannot be used for verifying the integrity of the received content. If the ETag given by the mirror server matches the ETag given by the Metalink server, then the Metalink client assumes the responses are valid for that object.
ETag不能用于验证接收内容的完整性。如果镜像服务器提供的ETag与Metalink服务器提供的ETag匹配，则Metalink客户端将假定响应对该对象有效。
This guarantees that a mismatch will be detected by using only the shared ETag from a Metalink server and mirror server. Metalink clients will detect an error if ETags do not match, which will prevent accidental merges of ranges from different versions of files with the same name.
这保证了仅使用Metalink服务器和镜像服务器的共享ETag可以检测到不匹配。如果etag不匹配，Metalink客户端将检测到错误，这将防止来自同名文件的不同版本的范围意外合并。
A shared ETag or Instance Digest cannot strictly protect against malicious attacks or server or network errors replacing content. An attacker can make a mirror server seemingly respond with the expected
共享ETag或实例摘要无法严格防止恶意攻击或替换内容的服务器或网络错误。攻击者可以使镜像服务器看似以预期的方式响应
Instance Digest or ETags even if the file contents have been modified. The same goes for various system failures, which would also cause bad data (i.e., corrupted files) to be returned. The Metalink client has to rely on the Instance Digest returned by the Metalink server in the first response for the verification of the downloaded object as a whole. To verify the individual ranges, which might have been requested from different sources, see Section 7.1.2.
实例摘要或ETag，即使文件内容已被修改。各种系统故障也是如此，这也会导致返回坏数据（即损坏的文件）。Metalink客户端必须依赖Metalink服务器在第一个响应中返回的实例摘要来验证下载的对象作为一个整体。要验证可能从不同来源请求的各个范围，请参见第7.1.2节。
Partial file cryptographic hashes can be used to detect errors during the download. Metalink servers SHOULD provide Metalink/XML files with partial file hashes in Link header fields as specified in Section 4.1, and Metalink clients SHOULD use them for error correction.
部分文件加密哈希可用于在下载过程中检测错误。Metalink服务器应按照第4.1节的规定，在链接头字段中提供包含部分文件哈希的Metalink/XML文件，Metalink客户端应使用它们进行错误更正。
An error in transfer or a substitution attack will be detected by a cryptographic hash of the object not matching the Instance Digest from the Metalink server. If the cryptographic hash of the object does not match the Instance Digest from the Metalink server, then the client SHOULD fetch the Metalink/XML (if available). This may contain partial file cryptographic hashes, which will allow detection of which mirror server returned incorrect data. Metalink clients SHOULD use the Metalink/XML data to figure out what ranges of the downloaded data can be recovered and what needs to be fetched again.
传输错误或替换攻击将由与Metalink服务器的实例摘要不匹配的对象的加密哈希检测。如果对象的加密哈希与Metalink服务器的实例摘要不匹配，则客户端应获取Metalink/XML（如果可用）。这可能包含部分文件加密哈希，这将允许检测哪个镜像服务器返回了不正确的数据。Metalink客户端应该使用Metalink/XML数据来确定哪些范围的下载数据可以恢复，哪些需要再次获取。
Other methods can be used for error correction. For example, some other metainfo files also include partial file hashes that can be used to check for errors.
可以使用其他方法进行误差校正。例如，其他一些metainfo文件还包括可用于检查错误的部分文件哈希。
Accordingly, IANA has made the following registration to the "Link Relation Types" registry at <http://www.iana.org/>.
因此，IANA在“链接关系类型”注册中心进行了以下注册：<http://www.iana.org/>.
o Relation Name: duplicate
o 关系名称：重复
o Description: Refers to a resource whose available representations are byte-for-byte identical with the corresponding representations of the context IRI.
o 描述：指可用表示形式与上下文IRI的对应表示形式完全相同的资源。
o Reference: This specification.
o 参考：本规范。
o Notes: This relation is for static resources. That is, an HTTP GET request on any duplicate will return the same representation. It does not make sense for dynamic or POSTable resources and should not be used for them.
o 注意：此关系适用于静态资源。也就是说，对任何副本的HTTP GET请求都将返回相同的表示形式。它对于动态或可邮寄的资源没有意义，因此不应用于这些资源。
Metalink clients handle URIs and Internationalized Resource Identifiers (IRIs). See Section 7 of [RFC3986] and Section 8 of [RFC3987] for security considerations related to their handling and use.
Metalink客户端处理URI和国际化资源标识符（IRI）。有关其处理和使用的安全注意事项，请参见[RFC3986]第7节和[RFC3987]第8节。
There is potential for spoofing attacks where the attacker publishes Metalinks with false information. In that case, this could deceive unaware downloaders into downloading a malicious or worthless file. Metalink clients are advised to prevent loops, possibly from a mirror server to a Metalink server and back again, in Section 2. As with all downloads, users should only download from trusted sources. Also, malicious publishers could attempt a distributed denial-of-service attack by inserting unrelated URIs into Metalinks. [RFC4732] contains information on amplification attacks and denial-of-service attacks.
攻击者发布带有虚假信息的metalink时，可能会发生欺骗攻击。在这种情况下，这可能会欺骗不知情的下载者下载恶意或无价值的文件。在第2节中，建议Metalink客户端防止循环，可能是从镜像服务器到Metalink服务器，然后再返回。与所有下载一样，用户应仅从可信来源下载。此外，恶意发布者还可以通过在metalink中插入不相关的uri来尝试分布式拒绝服务攻击。[RFC4732]包含有关放大攻击和拒绝服务攻击的信息。
Currently, some of the digest values defined in Instance Digests in HTTP [RFC3230] are considered insecure. These include the whole Message Digest family of algorithms, which are not suitable for cryptographically strong verification. Malicious people could provide files that appear to be identical to another file because of a collision; i.e., the weak cryptographic hashes of the intended file and a substituted malicious file could match.
目前，HTTP[RFC3230]中的实例摘要中定义的一些摘要值被认为是不安全的。这些包括整个消息摘要算法家族，它们不适用于加密强验证。恶意用户可能会因为冲突而提供与另一个文件相同的文件；i、 例如，预期文件和替换恶意文件的弱加密哈希可能匹配。
Metalinks SHOULD include digital signatures, as described in Section 5.
金属油墨应包括数字签名，如第5节所述。
Digital signatures provide authentication and message integrity, and enable non-repudiation with proof of origin.
数字签名提供身份验证和消息完整性，并通过原产地证明实现不可否认性。
[BITTORRENT] Cohen, B., "The BitTorrent Protocol Specification", BITTORRENT 11031, February 2008, <http://www.bittorrent.org/beps/bep_0003.html>.
[BITTORRENT]Cohen，B.，“BITTORRENT协议规范”，BITTORRENT 110312008年2月<http://www.bittorrent.org/beps/bep_0003.html>.
[FIPS-180-3] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[FIPS-180-3]国家标准与技术研究所（NIST），“安全哈希标准（SHS）”，FIPS PUB 180-3，2008年10月。
[ISO3166-1] International Organization for Standardization, "ISO 3166-1:2006. Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", November 2006.
[ISO3166-1]国际标准化组织，“ISO 3166-1:2006.国家及其分支机构名称表示代码——第1部分：国家代码”，2006年11月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 0959, October 1985.
[RFC0959]Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 0959，1985年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156]Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 3230, January 2002.
[RFC3230]Mogul，J.和A.Van Hoff，“HTTP中的实例摘要”，RFC 3230，2002年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5854] Bryan, A., Tsujikawa, T., McNab, N., and P. Poeml, "The Metalink Download Description Format", RFC 5854, June 2010.
[RFC5854]Bryan，A.，Tsujikawa，T.，McNab，N.，和P.Poeml，“Metalink下载描述格式”，RFC 58542010年6月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]诺丁汉，M.，“网络链接”，RFC 5988，2010年10月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Ed.，Rescorla，E.，Ed.，和IAB，“互联网拒绝服务注意事项”，RFC 47322006年12月。
[RFC5843] Bryan, A., "Additional Hash Algorithms for HTTP Instance Digests", RFC 5843, April 2010.
[RFC5843]Bryan，A.，“HTTP实例摘要的附加哈希算法”，RFC 58432010年4月。
Thanks to the Metalink community, Alexey Melnikov, Julian Reschke, Mark Nottingham, Daniel Stenberg, Matt Domsch, Micah Cowan, David Morris, Yves Lafon, Juergen Schoenwaelder, Ben Campbell, Lars Eggert, Sean Turner, Robert Sparks, and the HTTPBIS Working Group.
感谢Metalink社区、Alexey Melnikov、Julian Reschke、Mark Nottingham、Daniel Stenberg、Matt Domsch、Micah Cowan、David Morris、Yves Lafon、Juergen Schoenwaeld、Ben Campbell、Lars Eggert、Sean Turner、Robert Sparks和HTTPBIS工作组。
Thanks to Alan Ford and Mark Handley for spurring us on to publish this document.
感谢艾伦·福特和马克·汉德利激励我们出版这份文件。
This document is dedicated to Zimmy Bryan, Juanita Anthony, and Janie Burnett.
本文件献给齐米•布莱恩、胡安妮塔•安东尼和珍妮•伯内特。
Authors' Addresses
作者地址
Anthony Bryan Pompano Beach, FL USA
安东尼·布莱恩·蓬帕诺海滩，美国佛罗里达州
EMail: anthonybryan@gmail.com
URI: http://www.metalinker.org
EMail: anthonybryan@gmail.com
URI: http://www.metalinker.org
Neil McNab
麦纳
EMail: neil@nabber.org
URI: http://www.nabber.org
EMail: neil@nabber.org
URI: http://www.nabber.org
Tatsuhiro Tsujikawa Shiga Japan
日本筑川志贺达广
EMail: tatsuhiro.t@gmail.com
URI: http://aria2.sourceforge.net
EMail: tatsuhiro.t@gmail.com
URI: http://aria2.sourceforge.net
Dr. med. Peter Poeml MirrorBrain Venloer Str. 317 Koeln 50823 DE
梅德博士。Peter Poeml Mirrorbain Venlore街317号Koeln 50823 DE
Phone: +49 221 6778 333 8
EMail: peter@poeml.de
URI: http://mirrorbrain.org/~poeml/
Phone: +49 221 6778 333 8
EMail: peter@poeml.de
URI: http://mirrorbrain.org/~poeml/
Henrik Nordstrom
亨里克·诺德斯特罗姆
EMail: henrik@henriknordstrom.net
URI: http://www.henriknordstrom.net/
EMail: henrik@henriknordstrom.net
URI: http://www.henriknordstrom.net/