Network Working Group P. Vixie
Request for Comments: 2756 ISC
Category: Experimental D. Wessels
NLANR
January 2000
Network Working Group P. Vixie
Request for Comments: 2756 ISC
Category: Experimental D. Wessels
NLANR
January 2000
Hyper Text Caching Protocol (HTCP/0.0)
超文本缓存协议（HTCP/0.0）
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions.
本文档描述了HTCP，一种用于发现HTTP缓存和缓存数据、管理HTTP缓存集和监视缓存活动的协议。这是一个实验协议，是执行这些功能的几个方案之一。
1.1. HTTP/1.1 (see [RFC2616]) permits the transfer of web objects from "origin servers," possibly via "proxies" (which are allowed under some circumstances to "cache" such objects for subsequent reuse) to "clients" which consume the object in some way, usually by displaying it as part of a "web page." HTTP/1.0 and later permit "headers" to be included in a request and/or a response, thus expanding upon the HTTP/0.9 (and earlier) behaviour of specifying only a URI in the request and offering only a body in the response.
1.1. HTTP/1.1（参见[RFC2616]）允许将web对象从“原始服务器”转移到“客户端”，可能通过“代理”（在某些情况下允许“缓存”此类对象以备后续重用）以某种方式使用对象，通常通过将其显示为“网页”的一部分。HTTP/1.0和更高版本允许使用“标题”包含在请求和/或响应中，从而扩展HTTP/0.9（及更早版本）的行为，即在请求中仅指定URI，在响应中仅提供正文。
1.2. ICP (see [RFC2186]) permits caches to be queried as to their content, usually by other caches who are hoping to avoid an expensive fetch from a distant origin server. ICP was designed with HTTP/0.9 in mind, such that only the URI (without any headers) is used when describing cached content, and the possibility of multiple compatible bodies for the same URI had not yet been imagined.
1.2. ICP（参见[RFC2186]）允许对缓存的内容进行查询，通常由希望避免从远程源服务器获取昂贵数据的其他缓存进行查询。ICP的设计考虑到了HTTP/0.9，因此在描述缓存内容时只使用URI（不带任何头），而且还没有设想过为同一URI提供多个兼容实体的可能性。
1.3. This document specifies a Hyper Text Caching Protocol (HTCP) which permits full request and response headers to be used in cache management, and expands the domain of cache management to include monitoring a remote cache's additions and deletions, requesting immediate deletions, and sending hints about web objects such as the third party locations of cacheable objects or the measured uncacheability or unavailability of web objects.
1.3. 本文档指定了一种超文本缓存协议（HTCP），该协议允许在缓存管理中使用完整的请求和响应头，并扩展了缓存管理的领域，包括监控远程缓存的添加和删除、请求立即删除、，以及发送有关web对象的提示，例如可缓存对象的第三方位置或web对象的测量不可缓存性或不可用性。
2.1. All multi-octet HTCP protocol elements are transmitted in network byte order. All RESERVED fields should be set to binary zero by senders and left unexamined by receivers. Headers must be presented with the CRLF line termination, as in HTTP.
2.1. 所有多八位组HTCP协议元素均以网络字节顺序传输。发送方应将所有保留字段设置为二进制零，接收方则不进行检查。标头必须与CRLF行终止一起显示，如在HTTP中。
2.2. Any hostnames specified should be compatible between sender and receiver, such that if a private naming scheme (such as HOSTS.TXT or NIS) is in use, names depending on such schemes will only be sent to HTCP neighbors who are known to participate in said schemes. Raw addresses (dotted quad IPv4, or colon-format IPv6) are universal, as are public DNS names. Use of private names or addresses will require special operational care.
2.2. 指定的任何主机名应在发送方和接收方之间兼容，以便在使用私有命名方案（如HOSTS.TXT或NIS）时，依赖于此类方案的名称将仅发送给已知参与所述方案的HTCP邻居。原始地址（虚线四元组IPv4或冒号格式IPv6）是通用的，公共DNS名称也是通用的。使用私人姓名或地址需要特别小心操作。
2.3. HTCP messages may be sent as UDP datagrams, or over TCP connections. UDP must be supported. HTCP agents must not be isolated from NETWORK failures and delays. An HTCP agent should be prepared to act in useful ways when no response is forthcoming, or when responses are delayed or reordered or damaged. TCP is optional and is expected to be used only for protocol debugging. The IANA has assigned port 4827 as the standard TCP and UDP port number for HTCP.
2.3. HTCP消息可以作为UDP数据报发送，也可以通过TCP连接发送。必须支持UDP。HTCP代理不得与网络故障和延迟隔离。HTCP代理应做好准备，在没有响应时或响应延迟、重新排序或损坏时，以有用的方式采取行动。TCP是可选的，预期仅用于协议调试。IANA已将端口4827指定为HTCP的标准TCP和UDP端口号。
2.4. A set of configuration variables concerning transport characteristics should be maintained for each agent which is capable of initiating HTCP transactions, perhaps with a set of per-agent global defaults. These variables are:
2.4. 应为能够启动HTCP事务的每个代理维护一组与传输特性有关的配置变量，可能使用一组每个代理的全局默认值。这些变量是：
Maximum number of unacknowledged transactions before a "failure" is imputed.
在插补“失败”之前未确认的最大事务数。
Maximum interval without a response to some transaction before a "failure" is imputed.
在估算“失败”之前，没有对某个事务响应的最大间隔。
Minimum interval before trying a new transaction after a failure.
失败后尝试新事务之前的最小间隔。
2.5. An HTCP Message has the following general format:
2.5. HTCP消息具有以下通用格式：
+---------------------+
| HEADER | tells message length and protocol versions
+---------------------+
| DATA | HTCP message (varies per major version number)
+---------------------+
| AUTH | optional authentication for transaction
+---------------------+
+---------------------+
| HEADER | tells message length and protocol versions
+---------------------+
| DATA | HTCP message (varies per major version number)
+---------------------+
| AUTH | optional authentication for transaction
+---------------------+
2.6. An HTCP/*.* HEADER has the following format:
2.6. HTCP/*.*头具有以下格式：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+ + + + + + + + + + + + + + + + +
2: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | MAJOR | MINOR |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+ + + + + + + + + + + + + + + + +
2: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | MAJOR | MINOR |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH is the message length, inclusive of all header and data octets, including the LENGTH field itself. This field will be equal to the datagram payload size ("record length") if a datagram protocol is in use, and can include padding, i.e., not all octets of the message need be used in the DATA and AUTH sections.
LENGTH是消息长度，包括所有头和数据八位字节，包括长度字段本身。如果数据报协议正在使用，则该字段将等于数据报有效负载大小（“记录长度”），并且可以包括填充，即数据和身份验证部分中不需要使用消息的所有八位字节。
MAJOR is the major version number (0 for this specification). The DATA section of an HTCP message need not be upward or downward compatible between different major version numbers.
MAJOR是主要版本号（本规范为0）。HTCP消息的数据部分不需要在不同的主要版本号之间向上或向下兼容。
MINOR is the minor version number (0 for this specification). Feature levels and interpretation rules can vary depending on this field, in particular RESERVED fields can take on new (though optional) meaning in successive minor version numbers within the same major version number.
次要版本号是次要版本号（本规范为0）。功能级别和解释规则可能因该字段而异，特别是保留字段可能在同一主版本号内的后续次要版本号中具有新的（尽管是可选的）含义。
2.6.1. It is expected that an HTCP initiator will know the version number of a prospective HTCP responder, or that the initiator will probe using declining values for MINOR and MAJOR (beginning with the highest locally supported value) and locally cache the probed version number of the responder.
2.6.1. 预计HTCP启动器将知道预期HTCP响应程序的版本号，或者启动器将使用次要和主要的递减值（从本地支持的最高值开始）进行探测，并在本地缓存响应程序的探测版本号。
2.6.2. Higher MAJOR numbers are to be preferred, as are higher MINOR numbers within a particular MAJOR number.
2.6.2. 优先选择较大的主数字，以及特定主数字中较高的副数字。
2.7. An HTCP/0.* DATA has the following structure:
2.7. HTCP/0.*数据具有以下结构：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPCODE | RESPONSE | RESERVED |F1 |RR |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | TRANS-ID |
+ + + + + + + + + + + + + + + + +
6: | TRANS-ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: | |
/ OP-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPCODE | RESPONSE | RESERVED |F1 |RR |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | TRANS-ID |
+ + + + + + + + + + + + + + + + +
6: | TRANS-ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
8: | |
/ OP-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH is the number of octets of the message which are reserved for the DATA section, including the LENGTH field itself. This number can include padding, i.e., not all octets reserved by LENGTH need be used in OP-DATA.
LENGTH是为数据段保留的消息的八位字节数，包括长度字段本身。这个数字可以包括填充，也就是说，并非所有按长度保留的八位字节都需要在OP-DATA中使用。
OPCODE is the operation code of an HTCP transaction. An HTCP transaction can consist of multiple HTCP messages, e.g., a request (sent by the initiator), or a response (sent by the responder).
操作码是HTCP事务的操作码。HTCP事务可以由多个HTCP消息组成，例如，请求（由发起方发送）或响应（由响应方发送）。
RESPONSE is a numeric code indicating the success or failure of a transaction. It should be set to zero (0) by requestors and ignored by responders. Each operation has its own set of response codes, which are described later. The overall message has a set of response codes which are as follows:
RESPONSE is a numeric code indicating the success or failure of a transaction. It should be set to zero (0) by requestors and ignored by responders. Each operation has its own set of response codes, which are described later. The overall message has a set of response codes which are as follows:translate error, please retry
0 authentication wasn't used but is required 1 authentication was used but unsatisfactorily 2 opcode not implemented 3 major version not supported 4 minor version not supported (major version is ok) 5 inappropriate, disallowed, or undesirable opcode
未使用0身份验证，但需要1身份验证，但未令人满意2操作码未实现3主要版本不受支持4次要版本不受支持（主要版本正常）5不适当、不允许或不需要的操作码
The above response codes all indicate errors and all depend for their visibility on MO=1 (as specified below).
上述响应代码均表示错误，且均取决于MO=1（如下所述）的可见性。
RR is a flag indicating whether this message is a request (0) or response (1).
RR是一个标志，指示此消息是请求（0）还是响应（1）。
F1 is overloaded such that it is used differently by requestors than by responders. If RR=0, then F1 is defined as RD. If RR=1, then F1 is defined as MO.
F1被重载，因此请求者使用它的方式与响应者不同。如果RR=0，则F1定义为RD。如果RR=1，则F1定义为MO。
RD is a flag which if set to 1 means that a response is desired. Some OPCODEs require RD to be set to 1 to be meaningful.
RD是一个标志，如果设置为1，则表示需要响应。某些操作码要求RD设置为1才有意义。
MO (em-oh) is a flag which indicates whether the RESPONSE code is to be interpreted as a response to the overall message (fixed fields in DATA or any field of AUTH) [MO=1] or as a response to fields in the OP-DATA [MO=0].
MO（em oh）是一个标志，指示响应代码是被解释为对整个消息的响应（数据中的固定字段或AUTH的任何字段）[MO=1]还是对OP-DATA中的字段的响应[MO=0]。
TRANS-ID is a 32-bit value which when combined with the initiator's network address, uniquely identifies this HTCP transaction. Care should be taken not to reuse TRANS-ID's within the life-time of a UDP datagram.
TRANS-ID是一个32位的值，当与启动器的网络地址结合时，它唯一地标识此HTCP事务。应注意不要在UDP数据报的生命周期内重用TRANS-ID。
OP-DATA is opcode-dependent and is defined below, per opcode.
OP-DATA取决于操作码，下面根据操作码定义。
2.8. An HTCP/0.0 AUTH has the following structure:
2.8. HTCP/0.0身份验证具有以下结构：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | SIG-TIME |
+ + + + + + + + + + + + + + + + +
4: | SIG-TIME |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | SIG-EXPIRE |
+ + + + + + + + + + + + + + + + +
8: | SIG-EXPIRE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
10: | |
/ KEY-NAME /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
n: | |
/ SIGNATURE /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | SIG-TIME |
+ + + + + + + + + + + + + + + + +
4: | SIG-TIME |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | SIG-EXPIRE |
+ + + + + + + + + + + + + + + + +
8: | SIG-EXPIRE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
10: | |
/ KEY-NAME /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
n: | |
/ SIGNATURE /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH is the number of octets used by the AUTH, including the LENGTH field itself. If the optional AUTH is not being transmitted, this field should be set to 2 (two). LENGTH can include padding, which means that not all octets reserved by LENGTH will necessarily be consumed by SIGNATURE.
LENGTH是身份验证使用的八位字节数，包括长度字段本身。如果未传输可选身份验证，则此字段应设置为2（两个）。长度可以包括填充，这意味着并非所有由长度保留的八位字节都必须由签名使用。
SIG-TIME is an unsigned binary count of the number of seconds since 00:00:00 1-Jan-70 UTC at the time the SIGNATURE is generated.
SIG-TIME是自UTC 1-Jan-70 00:00生成签名时起的秒数的无符号二进制计数。
SIG-EXPIRE is an unsigned binary count of the number of seconds since 00:00:00 1-Jan-70 UTC at the time the SIGNATURE is considered to have expired.
SIG-EXPIRE是自UTC 1-Jan-70 00:00:00起的秒数的无符号二进制计数，此时签名被视为已过期。
KEY-NAME is a COUNTSTR [3.1] which specifies the name of a shared secret. (Each HTCP implementation is expected to allow configuration of several shared secrets, each of which will have a name.)
KEY-NAME是一个COUNTSTR[3.1]，它指定共享秘密的名称。（每个HTCP实现都应该允许配置多个共享机密，每个共享机密都有一个名称。）
SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 digest (see [RFC 2104]), with a B value of 64, of the following elements, each of which is digested in its "on the wire" format, including transmitted padding if any is covered by a field's associated LENGTH:
签名是一个COUNTSTR[3.1]，它保存以下元素的HMAC-MD5摘要（见[RFC 2104]），B值为64，每个元素都以其“在线”格式进行摘要，包括传输的填充（如果字段的相关长度包含任何填充）：
IP SRC ADDR [4 octets]
IP SRC PORT [2 octets]
IP DST ADDR [4 octets]
IP DST PORT [2 octets]
HTCP MAJOR version number [1 octet]
HTCP MINOR version number [1 octet]
SIG-TIME [4 octets]
SIG-EXPIRE [4 octets]
HTCP DATA [variable]
KEY-NAME (the whole COUNTSTR [3.1]) [variable]
IP SRC ADDR [4 octets]
IP SRC PORT [2 octets]
IP DST ADDR [4 octets]
IP DST PORT [2 octets]
HTCP MAJOR version number [1 octet]
HTCP MINOR version number [1 octet]
SIG-TIME [4 octets]
SIG-EXPIRE [4 octets]
HTCP DATA [variable]
KEY-NAME (the whole COUNTSTR [3.1]) [variable]
2.8.1. Shared secrets should be cryptorandomly generated and should be at least a few hundred octets in size.
2.8.1. 共享秘密应该是随机加密生成的，大小至少应该是几百个八位字节。
HTCP/0.* data types are defined as follows:
HTCP/0.*数据类型定义如下：
3.1. COUNTSTR is a counted string whose format is:
3.1. COUNTSTR是一个计数字符串，其格式为：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | |
/ TEXT /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | |
/ TEXT /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
LENGTH is the number of octets which will follow in TEXT. This field is *not* self-inclusive as is the case with other HTCP LENGTH fields.
长度是文本后面的八位字节数。与其他HTCP长度字段一样，此字段*不*自包含。
TEXT is a stream of uninterpreted octets, usually ISO8859-1 "characters".
文本是一组未解释的八位字节，通常是ISO8859-1“字符”。
3.2. SPECIFIER is used with the TST and CLR request messages, defined below. Its format is:
3.2. 说明符用于下面定义的TST和CLR请求消息。其格式为：
+---------------------+
| METHOD | : COUNTSTR
+---------------------+
| URI | : COUNTSTR
+---------------------+
| VERSION | : COUNTSTR
+---------------------+
| REQ-HDRS | : COUNTSTR
+---------------------+
+---------------------+
| METHOD | : COUNTSTR
+---------------------+
| URI | : COUNTSTR
+---------------------+
| VERSION | : COUNTSTR
+---------------------+
| REQ-HDRS | : COUNTSTR
+---------------------+
METHOD (Since HTCP only returns headers, methods GET and HEAD are equivalent.)
方法（因为HTCP只返回头，所以GET和HEAD方法是等效的。）
URI (If the URI is a URL, it should always include a ":"<port> specifier, but in its absense, port 80 should be imputed by a receiver.)
URI（如果URI是一个URL，它应该始终包含“：”<port>说明符，但是如果没有它，端口80应该由接收方输入。）
VERSION is an entire HTTP version string such as" HTTP/1.1". VERSION strings with prefixes other than "HTTP/" or with version numbers less than "1.1" are outside the domain of this specification.
VERSION是一个完整的HTTP版本字符串，如“HTTP/1.1”。前缀不是“HTTP/”或版本号小于“1.1”的版本字符串不在本规范的范围内。
REQ-HDRS are those presented by an HTTP initiator. These headers should include end-to-end but NOT hop-by-hop headers, and they can be canonicalized (aggregation of "Accept:" is permitted, for example.)
REQ-HDR是由HTTP启动器提供的。这些头应该包括端到端的头，而不是逐跳的头，并且它们可以被规范化（例如，允许聚合“Accept:”
3.3. DETAIL is used with the TST response message, defined below. Its format is:
3.3. 详细信息与TST响应消息一起使用，定义如下。其格式为：
+---------------------+
| RESP-HDRS | : COUNTSTR
+---------------------+
| ENTITY-HDRS | : COUNTSTR
+---------------------+
| CACHE-HDRS | : COUNTSTR
+---------------------+
+---------------------+
| RESP-HDRS | : COUNTSTR
+---------------------+
| ENTITY-HDRS | : COUNTSTR
+---------------------+
| CACHE-HDRS | : COUNTSTR
+---------------------+
3.4. IDENTITY is used with the MON request and SET response message, defined below. Its format is:
3.4. 标识与下面定义的MON请求和SET响应消息一起使用。其格式为：
+---------------------+
| SPECIFIER |
+---------------------+
| DETAIL |
+---------------------+
+---------------------+
| SPECIFIER |
+---------------------+
| DETAIL |
+---------------------+
HTCP/0.0 CACHE-HDRS consist of zero or more of the following headers:
HTCP/0.0 CACHE-HDR由零个或多个以下标头组成：
Cache-Vary: <header-name> ... The sender of this header has learned that content varies on a set of headers different from the set given in the object's Vary: header. Cache-Vary:, if present, overrides the object's Vary: header.
缓存不同：<header name>。。。此标头的发件人已了解到，一组标头上的内容不同于对象的Vary:header中给定的集合。缓存变量：如果存在，将覆盖对象的变量：标头。
Cache-Location: <cache-hostname>:<port> ... The sender of this header has learned of one or more proxy caches who are holding a copy of this object. Probing these caches with HTCP may result in discovery of new, close-by (preferrable to current) HTCP neighbors.
缓存位置：<Cache hostname>：<port>。。。此标头的发件人已了解到一个或多个代理缓存正在保存此对象的副本。使用HTCP探测这些缓存可能会发现新的、靠近（比当前的）HTCP邻居。
Cache-Policy: [no-cache] [no-share] [no-cache-cookie] The sender of this header has learned that the object's caching policy has more detail than is given in its response headers.
缓存策略：[无缓存][无共享][无缓存cookie]此标头的发件人已了解到对象的缓存策略比其响应标头中给出的更详细。
no-cache means that it is uncacheable (no reason given), but may be shareable between simultaneous requestors.
无缓存意味着它是不可缓存的（没有给出原因），但可以在同时请求者之间共享。
no-share means that it is unshareable (no reason given), and per-requestor tunnelling is always required).
没有共享意味着它是不可共享的（没有给出任何理由），并且始终需要每个请求者的隧道（perrequestor tunnelling）。
no-cache-cookie means that the content could change as a result of different, missing, or even random cookies being included in the request headers, and that caching is inadvisable.
无缓存cookie意味着内容可能会因为请求头中包含不同、丢失甚至随机的cookie而发生更改，并且缓存是不可取的。
Cache-Flags: [incomplete] The sender of this header has modified the object's caching policy locally, such that requesters may need to treat this response specially, i.e., not necessarily in accordance with the object's actual policy.
缓存标志：[不完整]此标头的发送方已在本地修改了对象的缓存策略，因此请求方可能需要专门处理此响应，即，不一定符合对象的实际策略。
incomplete means that the response headers and/or entity headers given in this response are not known to be complete, and may not be suitable for use as a cache key.
不完整表示此响应中给出的响应头和/或实体头不完整，可能不适合用作缓存键。
Cache-Expiry: <date> The sender of this header has learned that this object should be considered to have expired at a time different than that indicated by its response headers. The format is the same as HTTP/1.1 Expires:.
缓存过期：<date>此标头的发件人已获悉此对象应被视为已在与其响应标头指示的时间不同的时间过期。格式与HTTP/1.1 Expires相同：。
Cache-MD5: <discovered content MD5> The sender of this header has computed an MD5 checksum for this object which is either different from that given in the object's Content-MD5: header, or is being supplied since the object has no Content-MD5 header. The format is the same as HTTP/1.1 Content-MD5:.
Cache-MD5:<discovered content MD5>此标头的发送方已为此对象计算了一个MD5校验和，该校验和与对象的content-MD5:标头中给出的校验和不同，或者由于该对象没有content-MD5标头而提供。格式与HTTP/1.1 Content-MD5:相同。
Cache-to-Origin: <origin> <rtt> <samples> <hops> The sender of this header has measured the round trip time to an origin server (given as a hostname or literal address). The <rtt> is the average number of seconds, expressed as decimal ASCII with arbitrary precision and no exponent. <Samples> is the number of RTT samples which have had input to this average. <Hops> is the number of routers between the cache and the origin, expressed as decimal ASCII with arbitrary precision and no exponent, or 0 if the cache doesn't know.
缓存到源服务器：<Origin><rtt><samples><hops>此标头的发送方已测量到到源服务器的往返时间（以主机名或文本地址形式给出）。<rtt>是秒的平均数，用十进制ASCII表示，具有任意精度且无指数<Samples>是已输入此平均值的RTT样本数<Hops>是缓存和原点之间的路由器数，表示为十进制ASCII，具有任意精度且无指数，如果缓存不知道，则表示为0。
HTCP/0.* opcodes and their respective OP-DATA are defined below:
HTCP/0.*操作码及其各自的操作数据定义如下：
6.1. NOP (OPCODE 0):
6.1. NOP（操作码0）：
This is an HTCP-level "ping." Responders are encouraged to process NOP's with minimum delay since the requestor may be using the NOP RTT (round trip time) for configuration or mapping purposes. The RESPONSE code for a NOP is always zero (0). There is no OP-DATA for a NOP. NOP requests with RD=0 cause no processing to occur at all.
这是HTCP级别的“ping”。鼓励响应者以最小延迟处理NOP，因为请求者可能使用NOP RTT（往返时间）进行配置或映射。NOP的响应代码始终为零（0）。没有NOP的OP-DATA。RD=0的NOP请求导致根本不进行任何处理。
6.2. TST (OPCODE 1):
6.2. TST（操作码1）：
Test for the presence of a specified content entity in a proxy cache. TST requests with RD=0 cause no processing to occur at all.
测试代理缓存中是否存在指定的内容实体。RD=0的TST请求根本不进行任何处理。
TST requests have the following OP-DATA:
TST请求具有以下OP-DATA：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ SPECIFIER /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ SPECIFIER /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RESPONSE codes for TST are as follows:
TST的响应代码如下所示：
0 entity is present in responder's cache 1 entity is not present in responder's cache
0实体存在于响应程序的缓存中1实体不存在于响应程序的缓存中
TST responses have the following OP-DATA, if RESPONSE is zero (0):
如果响应为零（0），则TST响应具有以下OP-DATA：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ DETAIL /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ DETAIL /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Note: The response headers returned by a positive TST can be of a stale object. Requestors should be prepared to cope with this condition, either by using the responder as a source for this object (which could cause the responder to simply refresh it) or by choosing a different responder.
注意：正TST返回的响应头可以是陈旧对象。请求者应该准备好处理这种情况，或者使用响应者作为该对象的源（这可能导致响应者简单地刷新它），或者选择不同的响应者。
TST responses have the following OP-DATA, if RESPONSE is one (1):
如果响应为一（1），则TST响应具有以下OP-DATA：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ CACHE-HDRS /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ CACHE-HDRS /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6.3. MON (OPCODE 2):
6.3. MON（操作码2）：
Monitor activity in a proxy cache's local object store (adds, deletes, replacements, etc). Since interleaving of HTCP transactions over a single pair of UDP endpoints is not supported, it is recommended that a unique UDP endpoint be allocated by the requestor for each concurrent MON request. MON requests with RD=0 are equivalent to those with RD=1 and TIME=0; that is, they will cancel any outstanding MON transaction.
监视代理缓存的本地对象存储中的活动（添加、删除、替换等）。由于不支持在一对UDP端点上交错HTCP事务，因此建议请求者为每个并发MON请求分配唯一的UDP端点。RD=0的MON请求与RD=1、TIME=0的MON请求等价；也就是说，他们将取消任何未完成的MON事务。
MON requests have the following OP-DATA structure:
MON请求具有以下OP-DATA结构：
+0 (MSB)
+---+---+---+---+---+---+---+---+
0: | TIME |
+---+---+---+---+---+---+---+---+
+0 (MSB)
+---+---+---+---+---+---+---+---+
0: | TIME |
+---+---+---+---+---+---+---+---+
TIME is the number of seconds of monitoring output desired by the initiator. Subsequent MON requests from the same initiator with the same TRANS-ID should update the time on a ongoing MON transaction. This is called "overlapping renew."
TIME是启动器所需的监控输出的秒数。来自具有相同事务ID的同一启动器的后续MON请求应更新正在进行的MON事务的时间。这被称为“重叠更新”
RESPONSE codes for MON are as follows:
MON的响应代码如下所示：
0 accepted, OP-DATA is present and valid 1 refused (quota error -- too many MON's are active)
0已接受，OP-DATA存在且有效1被拒绝（配额错误--活动的MON太多）
MON responses have the following OP-DATA structure, if RESPONSE is zero (0):
如果响应为零（0），则MON响应具有以下OP-DATA结构：
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | TIME | ACTION | REASON |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | |
/ IDENTITY /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | TIME | ACTION | REASON |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | |
/ IDENTITY /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TIME is the number of seconds remaining for this MON transaction.
TIME是此MON事务剩余的秒数。
ACTION is a numeric code indicating a cache population action. Codes are:
ACTION是一个数字代码，指示缓存填充操作。代码为：
0 an entity has been added to the cache 1 an entity in the cache has been refreshed 2 an entity in the cache has been replaced 3 an entity in the cache has been deleted
0已将实体添加到缓存1已刷新缓存中的实体2已替换缓存中的实体3已删除缓存中的实体
REASON is a numeric code indicating the reason for an ACTION. Codes are:
原因是指示操作原因的数字代码。代码为：
0 some reason not covered by the other REASON codes 1 a proxy client fetched this entity 2 a proxy client fetched with caching disallowed 3 the proxy server prefetched this entity 4 the entity expired, per its headers 5 the entity was purged due to caching storage limits
0其他原因代码未涵盖的某些原因1代理客户端获取此实体2代理客户端获取时不允许缓存3代理服务器预取此实体4该实体已过期，根据其标头5该实体因缓存存储限制而被清除
6.4. SET (OPCODE 3):
6.4. 集合（操作码3）：
Inform a cache of the identity of an object. This is a "push" transaction, whereby cooperating caches can share information such as updated Age/Date/Expires headers (which might result from an origin "304 Not modified" HTTP response) or updated cache headers (which might result from the discovery of non-authoritative "vary" conditions or from learning of second or third party cache locations for this entity. RD is honoured.
将对象的标识通知缓存。这是一个“推送”事务，协作缓存可以共享信息，例如更新的年龄/日期/到期头（可能来自于源“304未修改”HTTP响应）或更新的缓存头（可能来自于发现非权威“vary”此实体的第二方或第三方缓存位置的条件或学习。RD是荣幸的。
SET requests have the following OP-DATA structure:
SET请求具有以下OP-DATA结构：
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ IDENTITY /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | |
/ IDENTITY /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RESPONSE codes are as follows:
响应代码如下：
0 identity accepted, thank you 1 identity ignored, no reason given, thank you
0身份已接受，谢谢1身份已忽略，未给出任何原因，谢谢
SET responses have no OP-DATA.
集合响应没有OP-DATA。
6.5. CLR (OPCODE 4):
6.5. CLR（操作码4）：
Tell a cache to completely forget about an entity. RD is honoured.
告诉缓存完全忘记实体。这是我的荣幸。
CLR requests have the following OP-DATA structure:
CLR请求具有以下OP-DATA结构：
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | RESERVED | REASON |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | |
/ SPECIFIER /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | RESERVED | REASON |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | |
/ SPECIFIER /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
REASON is a numeric code indicating the reason why the requestor is asking that this entity be removed. The codes are as follows:
REASON是一个数字代码，指示请求者请求删除此实体的原因。代码如下：
0 some reason not better specified by another code 1 the origin server told me that this entity does not exist
0某些原因不是由另一个代码1更好地指定的源服务器告诉我此实体不存在
RESPONSE codes are as follows:
响应代码如下：
0 i had it, it's gone now 1 i had it, i'm keeping it, no reason given. 2 i didn't have it
0我拥有它，现在它消失了1我拥有它，我保留它，没有给出任何理由。我没有
CLR responses have no OP-DATA.
CLR响应没有OP-DATA。
Clearing a URI without specifying response, entity, or cache headers means to clear all entities using that URI.
清除URI而不指定响应、实体或缓存头意味着清除使用该URI的所有实体。
If the optional AUTH element is not used, it is possible for unauthorized third parties to both view and modify a cache using the HTCP protocol.
如果未使用可选的AUTH元素，则未经授权的第三方可以使用HTCP协议查看和修改缓存。
Mattias Wingstedt of Idonex brought key insights to the development of this protocol. David Hankins helped clarify this document.
Idonex的Mattias Wingstedt为该协议的制定带来了关键的见解。大卫·汉金斯帮助澄清了这份文件。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[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月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February, 1997.
[RFC2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), version 2", RFC 2186, September 1997.
[RFC2186]Wessels，D.和K.Claffy，“互联网缓存协议（ICP），版本2”，RFC2186，1997年9月。
Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063
Paul Vixie互联网软件联合体950 Charter Street Redwood City，加利福尼亚州94063
Phone: +1 650 779 7001
EMail: vixie@isc.org
Phone: +1 650 779 7001
EMail: vixie@isc.org
Duane Wessels National Lab for Applied Network Research USCD, 9500 Gilman Drive La Jolla, CA 92093
Duane Wessels美国加州大学应用网络研究国家实验室，加利福尼亚州拉荷亚吉尔曼大道9500号，邮编92093
Phone: +1 303 497 1822
EMail: wessels@nlanr.net
Phone: +1 303 497 1822
EMail: wessels@nlanr.net
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。