Network Working Group H. Nielsen
Request for Comments: 2774 P. Leach
Category: Experimental Microsoft
S. Lawrence
Agranat Systems
February 2000
Network Working Group H. Nielsen
Request for Comments: 2774 P. Leach
Category: Experimental Microsoft
S. Lawrence
Agranat Systems
February 2000
An HTTP Extension Framework
HTTP扩展框架
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年）。版权所有。
IESG Note
IESG注释
This document was originally requested for Proposed Standard status. However, due to mixed reviews during Last Call and within the HTTP working group, it is being published as an Experimental document. This is not necessarily an indication of technical flaws in the document; rather, there is a more general concern about whether this document actually represents community consensus regarding the evolution of HTTP. Additional study and discussion are needed before this can be determined.
本文件最初是为拟议标准状态而要求的。然而，由于上一次调用期间和HTTP工作组内部的评论不一，所以它将作为实验性文档发布。这不一定表示文件中存在技术缺陷；相反，对于本文档是否真正代表了社区对HTTP发展的共识，存在着更普遍的关注。在确定这一点之前，还需要进行额外的研究和讨论。
Note also that when HTTP is used as a substrate for other protocols, it may be necessary or appropriate to use other extension mechanisms in addition to, or instead of, those defined here. This document should therefore not be taken as a blueprint for adding extensions to HTTP, but it defines mechanisms that might be useful in such circumstances.
还请注意，当HTTP用作其他协议的基础时，除了此处定义的扩展机制之外，还可能需要或适合使用其他扩展机制。因此，本文档不应被视为向HTTP添加扩展的蓝图，但它定义了在这种情况下可能有用的机制。
Abstract
摘要
A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.
广泛的应用程序提出了HTTP协议的各种扩展。当前的工作范围非常广泛，包括分布式创作、协作、打印和远程过程调用机制。这些HTTP扩展是不协调的，因为没有定义扩展的标准框架，因此也没有关注点分离。本文档描述了HTTP的通用扩展机制，旨在解决私有协议和公共规范之间的紧张关系，并适应使用HTTP客户端、服务器和代理的应用程序扩展。提案将每个扩展与一个全局唯一标识符相关联，并使用HTTP头字段在扩展通信涉及的各方之间携带扩展标识符和相关信息。
Table of Contents
目录
1. Introduction ...............................................3
2. Notational Conventions .....................................3
3. Extension Declarations .....................................4
3.1 Header Field Prefixes ...................................5
4. Extension Header Fields ....................................6
4.1 End-to-End Extensions ...................................7
4.2 Hop-by-Hop Extensions ...................................7
4.3 Extension Response Header Fields ........................8
5. Mandatory HTTP Requests ....................................8
5.1 Fulfilling a Mandatory Request .........................10
6. Mandatory HTTP Responses ..................................11
7. 510 Not Extended ..........................................11
8. Publishing an Extension ...................................11
9. Caching Considerations ....................................12
10. Security Considerations ...................................13
11. References ................................................13
12. Acknowledgements ..........................................14
13. Authors' Addresses ........................................14
14. Summary of Protocol Interactions ..........................15
15. Examples ..................................................16
15.1 User Agent to Origin Server ............................16
15.2 User Agent to Origin Server via HTTP/1.1 Proxy .........17
15.3 User Agent to Origin Server via HTTP/1.0 Proxy .........18
Full Copyright Statement ......................................20
1. Introduction ...............................................3
2. Notational Conventions .....................................3
3. Extension Declarations .....................................4
3.1 Header Field Prefixes ...................................5
4. Extension Header Fields ....................................6
4.1 End-to-End Extensions ...................................7
4.2 Hop-by-Hop Extensions ...................................7
4.3 Extension Response Header Fields ........................8
5. Mandatory HTTP Requests ....................................8
5.1 Fulfilling a Mandatory Request .........................10
6. Mandatory HTTP Responses ..................................11
7. 510 Not Extended ..........................................11
8. Publishing an Extension ...................................11
9. Caching Considerations ....................................12
10. Security Considerations ...................................13
11. References ................................................13
12. Acknowledgements ..........................................14
13. Authors' Addresses ........................................14
14. Summary of Protocol Interactions ..........................15
15. Examples ..................................................16
15.1 User Agent to Origin Server ............................16
15.2 User Agent to Origin Server via HTTP/1.1 Proxy .........17
15.3 User Agent to Origin Server via HTTP/1.0 Proxy .........18
Full Copyright Statement ......................................20
This proposal is designed to address the tension between private agreement and public specification; and to accommodate dynamic extension of HTTP clients and servers by software components. The kind of extensions capable of being introduced range from:
该提案旨在解决私人协议和公共规范之间的紧张关系；并通过软件组件适应HTTP客户端和服务器的动态扩展。能够引入的扩展类型包括：
o extending a single HTTP message;
o 扩展单个HTTP消息；
o introducing new encodings;
o 引入新编码；
o initiating HTTP-derived protocols for new applications; to...
o 为新的应用程序启动HTTP派生协议；到
o switching to protocols which, once initiated, run independent of the original protocol stack.
o 切换到启动后独立于原始协议栈运行的协议。
The proposal is intended to be used as follows:
本提案拟用于以下用途：
o Some party designs and specifies an extension; the party assigns the extension a globally unique URI, and makes one or more representations of the extension available at that address (see section 8).
o 一些缔约方设计并指定了一个扩展；该方为扩展分配一个全局唯一的URI，并在该地址提供扩展的一个或多个表示（见第8节）。
o An HTTP client or server that implements this extension mechanism (hereafter called an agent) declares the use of the extension by referencing its URI in an extension declaration in an HTTP message (see section 3).
o 实现此扩展机制的HTTP客户端或服务器（以下称为代理）通过在HTTP消息的扩展声明中引用其URI来声明扩展的使用（请参见第3节）。
o The HTTP application which the extension declaration is intended for (hereafter called the ultimate recipient) can deduce how to properly interpret the extended message based on the extension declaration.
o 扩展声明所针对的HTTP应用程序（以下称为最终接收者）可以根据扩展声明推断如何正确解释扩展消息。
The proposal uses features in HTTP/1.1 but is compatible with HTTP/1.0 applications in such a way that extended applications can coexist with existing HTTP applications. Applications implementing this proposal MUST be based on HTTP/1.1 (or later versions of HTTP).
该方案使用HTTP/1.1中的功能，但与HTTP/1.0应用程序兼容，扩展应用程序可以与现有HTTP应用程序共存。实现此方案的应用程序必须基于HTTP/1.1（或更高版本的HTTP）。
This specification uses the same notational conventions and basic parsing constructs as RFC 2068 [5]. In particular the BNF constructs "token", "quoted-string", "Request-Line", "field-name", and "absoluteURI" in this document are to be interpreted as described in RFC 2068 [5].
本规范使用与RFC 2068[5]相同的符号约定和基本解析结构。特别是，本文档中的BNF结构“令牌”、“引用字符串”、“请求行”、“字段名”和“绝对URI”将按照RFC 2068[5]中的描述进行解释。
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 RFC 2119 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释。
This proposal does not rely on particular features defined in URLs [8] that cannot potentially be expressed using URNs (see section 8). Therefore, the more generic term URI [8] is used throughout the specification.
本提案不依赖URL[8]中定义的特定功能，这些功能可能无法使用URN表达（见第8节）。因此，在整个规范中使用了更通用的术语URI[8]。
An extension declaration can be used to indicate that an extension has been applied to a message and possibly to reserve a part of the header namespace identified by a header field prefix (see 3.1). This section defines the extension declaration itself; section 4 defines a set of header fields using the extension declaration.
扩展声明可用于指示扩展已应用于消息，并可能保留由标头字段前缀标识的标头命名空间的一部分（请参见3.1）。本节定义了扩展声明本身；第4节使用扩展声明定义了一组头字段。
This specification does not define any ramifications of applying an extension to a message nor whether two extensions can or cannot logically coexist within the same message. It is simply a framework for describing which extensions have been applied and what the ultimate recipient either must or may do in order to properly interpret any extension declarations within that message.
本规范未定义将扩展应用于消息的任何后果，也未定义两个扩展是否可以在同一消息中逻辑共存。它只是一个框架，用于描述应用了哪些扩展，以及最终接收者为了正确解释该消息中的任何扩展声明必须或可能做什么。
The grammar for an extension declaration is as follows:
扩展声明的语法如下所示：
ext-decl = <"> ( absoluteURI | field-name ) <">
[ namespace ] [ decl-extensions ]
ext-decl = <"> ( absoluteURI | field-name ) <">
[ namespace ] [ decl-extensions ]
namespace = ";" "ns" "=" header-prefix
header-prefix = 2*DIGIT
namespace = ";" "ns" "=" header-prefix
header-prefix = 2*DIGIT
decl-extensions = *( decl-ext )
decl-ext = ";" token [ "=" ( token | quoted-string ) ]
decl-extensions = *( decl-ext )
decl-ext = ";" token [ "=" ( token | quoted-string ) ]
An extension is identified by an absolute, globally unique URI or a field-name. A field-name MUST specify a header field uniquely defined in an IETF Standards Track RFC [3]. A URI can unambiguously be distinguished from a field-name by the presence of a colon (":").
扩展由绝对的、全局唯一的URI或字段名标识。字段名必须指定IETF标准跟踪RFC[3]中唯一定义的标题字段。URI可以通过冒号（“：”）与字段名明确区分。
The support for header field names as extension identifiers provides a transition strategy from decentralized extensions to extensions defined by IETF Standards Track RFCs until a mapping between the globally unique URI space and features defined in IETF Standards Track RFCs has been defined according to the guidelines described in section 8.
对标题字段名称作为扩展标识符的支持提供了从分散扩展到IETF标准跟踪RFC定义的扩展的过渡策略，直到根据第8节中描述的指南定义了全局唯一URI空间和IETF标准跟踪RFC中定义的功能之间的映射。
Examples of extension declarations are
扩展声明的示例包括
"http://www.company.com/extension"; ns=11
"Range"
"http://www.company.com/extension"; ns=11
"Range"
An agent MAY use the decl-extensions mechanism to include optional extension declaration parameters but cannot assume these parameters to be recognized by the recipient. An agent MUST NOT use decl-extensions to pass extension instance data, which MAY be passed using header field prefix values (see section 3.1). Unrecognized decl-ext parameters SHOULD be ignored and MUST NOT be removed by proxies when forwarding the extension declaration.
代理可以使用decl扩展机制包括可选的扩展声明参数，但不能假定收件人可以识别这些参数。代理不得使用decl扩展传递扩展实例数据，扩展实例数据可以使用头字段前缀值传递（请参阅第3.1节）。转发扩展声明时，应忽略无法识别的decl ext参数，且代理不得删除这些参数。
The header-prefix is a dynamically generated string. All header fields in the message that match this string, using string prefix-matching, belong to that extension declaration. Header field prefixes allow an extension declaration to dynamically reserve a subspace of the header space in a protocol message in order to prevent header field name clashes and to allow multiple declarations using the same extension to be applied to the same message without conflicting.
标题前缀是动态生成的字符串。消息中与此字符串匹配的所有头字段（使用字符串前缀匹配）都属于该扩展声明。标头字段前缀允许扩展声明在协议消息中动态保留标头空间的子空间，以防止标头字段名称冲突，并允许使用同一扩展名的多个声明应用于同一消息而不发生冲突。
Header fields using a header-prefix are of the form:
使用标题前缀的标题字段的格式如下：
prefixed-header = prefix-match field-name prefix-match = header-prefix "-"
前缀标头=前缀匹配字段名称前缀匹配=标头前缀“-”
Linear white space (LWS) MUST NOT be used between the header-prefix and the dash ("-") or between the prefix-match and the field-name. The string prefix matching algorithm is applied to the prefix-match string.
标题前缀和破折号（“-”）之间或前缀匹配和字段名之间不得使用线性空格（LWS）。字符串前缀匹配算法应用于前缀匹配字符串。
The format of the prefix using a combination of digits and the dash ("-") guarantees that no extension declaration can reserve the whole header field name space. The header-prefix mechanism was preferred over other solutions for exchanging extension instance parameters because it is header based and therefore allows for easy integration of new extensions with existing HTTP features.
使用数字和破折号（“-”）组合的前缀格式保证没有扩展声明可以保留整个标头字段名称空间。与其他交换扩展实例参数的解决方案相比，头前缀机制更受欢迎，因为它基于头，因此允许将新扩展与现有HTTP功能轻松集成。
Agents MUST NOT reuse header-prefix values in the same message unless explicitly allowed by the extension (see section 4.1 for a discussion of the ultimate recipient of an extension declaration).
除非扩展明确允许，否则代理不得在同一消息中重用头前缀值（有关扩展声明的最终收件人的讨论，请参阅第4.1节）。
Clients SHOULD be as consistent as possible when generating header-prefix values as this facilitates use of the Vary header field in responses that vary as a function of the request extension declaration(s) (see [5], section 13.6).
在生成头前缀值时，客户端应尽可能保持一致，因为这有助于在响应中使用Vary header字段，响应随请求扩展声明的变化而变化（参见[5]，第13.6节）。
Servers including prefixed-header header fields in a Vary header field value MUST also include the corresponding extension declaration field-name as part of that value. For example, if a response depends on the value of the 16-use-transform header field defined by an optional extension declaration in the request, the Vary header field in the response could look like this:
在Vary header字段值中包含前缀header字段的服务器还必须包含相应的扩展声明字段名作为该值的一部分。例如，如果响应取决于由请求中的可选扩展声明定义的16 use transform header字段的值，则响应中的Vary header字段可能如下所示：
Vary: Opt, 16-use-transform
变化：选择，16使用变换
Note, that header-prefix consistency is no substitute for including an extension declaration in the message: header fields with header-prefix values not defined by an extension declaration in the same message are not defined by this specification.
请注意，标头前缀一致性不能替代在消息中包含扩展声明：具有标头前缀值的标头字段（未由同一消息中的扩展声明定义）不由本规范定义。
Examples of header-prefix values are
标题前缀值的示例包括
12 15 23
12 15 23
Old applications may introduce header fields independent of this extension mechanism, potentially conflicting with header fields introduced by the prefix mechanism. In order to minimize this risk, prefixes MUST contain at least 2 digits.
旧应用程序可能引入独立于此扩展机制的头字段，这可能与前缀机制引入的头字段冲突。为了将此风险降至最低，前缀必须至少包含2位数字。
This proposal introduces two types of extension declaration strength: mandatory and optional, and two types of extension declaration scope: hop-by-hop and end-to-end (see section 4.1 and 4.2).
本提案引入了两种类型的扩展声明强度：强制和可选，以及两种类型的扩展声明范围：逐跳和端到端（见第4.1和4.2节）。
A mandatory extension declaration indicates that the ultimate recipient MUST consult and adhere to the rules given by the extension when processing the message or reporting an error (see section 5 and 7).
强制扩展声明表明，最终收件人在处理邮件或报告错误时必须参考并遵守扩展给出的规则（参见第5节和第7节）。
An optional extension declaration indicates that the ultimate recipient of the extension MAY consult and adhere to the rules given by the extension when processing the message, or ignore the extension declaration completely. An agent may not be able to distinguish whether the ultimate recipient does not understand an extension referred to by an optional extension or simply ignores the extension declaration.
可选的扩展声明表示扩展的最终接收者在处理消息时可以参考并遵守扩展给出的规则，或者完全忽略扩展声明。代理可能无法区分最终收件人是否不理解可选扩展所引用的扩展，或者只是忽略扩展声明。
The combination of the declaration strength and scope defines a 2x2 matrix which is distinguished by four new general HTTP header fields: Man, Opt, C-Man, and C-Opt. (See sections 4.1 and 4.2; also see appendix 14, which has a table of interactions with origin servers and proxies.)
声明强度和范围的组合定义了一个2x2矩阵，该矩阵由四个新的通用HTTP头字段区分：Man、Opt、C-Man和C-Opt。（参见第4.1节和第4.2节；另请参见附录14，其中列出了与源服务器和代理的交互表。）
The header fields are general header fields as they describe which extensions actually are applied to an HTTP message. Optional declarations MAY be applied to any HTTP message if appropriate (see section 5 for how to apply mandatory extension declarations to requests and section 6 for how to apply them to responses).
标头字段是一般标头字段，因为它们描述了实际应用于HTTP消息的扩展。如果合适，可选声明可以应用于任何HTTP消息（参见第5节了解如何将强制扩展声明应用于请求，以及第6节了解如何将它们应用于响应）。
End-to-end declarations MUST be transmitted to the ultimate recipient of the declaration. The Man and the Opt general header fields are end- to-end header fields and are defined as follows:
端到端声明必须发送给声明的最终接收者。Man和Opt general标头字段是端到端标头字段，定义如下：
mandatory = "Man" ":" 1#ext-decl
optional = "Opt" ":" 1#ext-decl
mandatory = "Man" ":" 1#ext-decl
optional = "Opt" ":" 1#ext-decl
For example
例如
HTTP/1.1 200 OK Content-Length: 421 Opt: "http://www.digest.org/Digest"; ns=15 15-digest: "snfksjgor2tsajkt52" ...
HTTP/1.1 200 OK内容长度：421 Opt:“http://www.digest.org/Digest"; ns=15摘要：“snfksjgor2tsajkt52”。。。
The ultimate recipient of a mandatory end-to-end extension declaration MUST handle that extension declaration as described in section 5 and 6.
强制性端到端延期声明的最终接收人必须按照第5节和第6节的规定处理该延期声明。
Hop-by-hop extension declarations are meaningful only for a single HTTP connection. In HTTP/1.1, C-Man, C-Opt, and all header fields with matching header-prefix values defined by C-Man and C-Opt MUST be protected by a Connection header field. That is, these header fields are to be included as Connection header field directives (see [5], section 14.10). The two header fields have the following grammar:
逐跳扩展声明仅对单个HTTP连接有意义。在HTTP/1.1中，C-Man、C-Opt以及所有具有由C-Man和C-Opt定义的匹配头前缀值的头字段都必须受到连接头字段的保护。也就是说，这些标头字段将作为连接标头字段指令包含（请参见[5]，第14.10节）。两个标题字段具有以下语法：
c-mandatory = "C-Man" ":" 1#ext-decl
c-optional = "C-Opt" ":" 1#ext-decl
c-mandatory = "C-Man" ":" 1#ext-decl
c-optional = "C-Opt" ":" 1#ext-decl
For example
例如
M-GET / HTTP/1.1
Host: some.host
C-Man: "http://www.digest.org/ProxyAuth"; ns=14
14-Credentials="g5gj262jdw@4df"
Connection: C-Man, 14-Credentials
M-GET / HTTP/1.1
Host: some.host
C-Man: "http://www.digest.org/ProxyAuth"; ns=14
14-Credentials="g5gj262jdw@4df"
Connection: C-Man, 14-Credentials
The ultimate recipient of a mandatory hop-by-hop extension declaration MUST handle that extension declaration as described in section 5 and 6.
强制逐跳扩展声明的最终接收者必须按照第5节和第6节所述处理该扩展声明。
Two extension response header fields are used to indicate that a request containing mandatory extension declarations has been fulfilled by the ultimate recipient as described in section 5.1. The extension response header fields are exclusively intended to serve as extension acknowledgements, and can not carry any other information.
两个扩展响应头字段用于指示包含强制性扩展声明的请求已由最终收件人完成，如第5.1节所述。扩展响应头字段专门用作扩展确认，不能携带任何其他信息。
The Ext header field is used to indicate that all end-to-end mandatory extension declarations in the request were fulfilled:
Ext header字段用于指示已满足请求中的所有端到端强制扩展声明：
ext = "Ext" ":"
ext=“ext”：
The C-Ext response header field is used to indicate that all hop-by-hop mandatory extension declarations in the request were fulfilled.
C-Ext响应头字段用于指示请求中的所有逐跳强制扩展声明都已完成。
c-ext = "C-Ext" ":"
c-ext=“c-ext”：
In HTTP/1.1, the C-Ext header fields MUST be protected by a Connection header (see [5], section 14.10).
在HTTP/1.1中，C-Ext头字段必须受到连接头的保护（见[5]，第14.10节）。
The Ext and the C-Ext header fields are not mutually exclusive; they can both occur within the same message as described in section 5.1.
Ext和C-Ext标题字段不是互斥的；它们都可能出现在第5.1节所述的相同消息中。
An HTTP request is called a mandatory request if it includes at least one mandatory extension declaration (using the Man or the C-Man header fields). The method name of a mandatory request MUST be prefixed by "M-". For example, a client might express the binding rights- management constraints in an HTTP PUT request as follows:
如果HTTP请求至少包含一个强制扩展声明（使用Man或C-Man头字段），则称为强制请求。强制请求的方法名称必须以“M-”作为前缀。例如，客户端可能在HTTP PUT请求中表达绑定权限管理约束，如下所示：
M-PUT /a-resource HTTP/1.1
Man: "http://www.copyright.org/rights-management"; ns=16
16-copyright: http://www.copyright.org/COPYRIGHT.html
16-contributions: http://www.copyright.org/PATCHES.html
Host: www.w3.org
Content-Length: 1203
Content-Type: text/html
M-PUT /a-resource HTTP/1.1
Man: "http://www.copyright.org/rights-management"; ns=16
16-copyright: http://www.copyright.org/COPYRIGHT.html
16-contributions: http://www.copyright.org/PATCHES.html
Host: www.w3.org
Content-Length: 1203
Content-Type: text/html
<!doctype html ...
<!doctype html。。。
An ultimate recipient conforming to this specification receiving a mandatory request MUST process the request by performing the following actions in the order listed below:
符合本规范的最终接收人收到强制请求时，必须按照下列顺序执行以下操作，以处理该请求：
1. Identify all mandatory extension declarations (both hop-by-hop and end-to-end); the server MAY ignore optional declarations without affecting the result of processing the HTTP message;
1. 识别所有强制性扩展声明（逐跳和端到端）；服务器可以忽略可选声明，而不影响HTTP消息的处理结果；
2. Examine all extensions identified in 1) and determine if they are supported for this message. If not, respond with a 510 (Not Extended) status-code (see section 7);
2. 检查1）中标识的所有扩展，并确定此消息是否支持这些扩展。如果没有，则使用510（未扩展）状态代码进行响应（见第7节）；
3. If 2) did not result in a 510 (Not Extended) status code, then process the request according to the semantics of the extensions and of the existing HTTP method name as defined in HTTP/1.1 [5] or later versions of HTTP. The HTTP method name can be obtained by ignoring the "M-" method name prefix.
3. 如果2）未生成510（未扩展）状态代码，则根据HTTP/1.1[5]或更高版本的HTTP中定义的扩展和现有HTTP方法名称的语义处理请求。可以通过忽略“M-”方法名称前缀来获取HTTP方法名称。
4. If the evaluation in 3) was successful and the mandatory request fulfilled, the server MUST respond as defined in section 5.1. A server MUST NOT fulfill a request without understanding and obeying all mandatory extension declaration(s) in a request.
4. 如果3）中的评估成功且强制请求得到满足，则服务器必须按照第5.1节中的定义进行响应。如果不理解并遵守请求中的所有强制扩展声明，服务器就不能完成请求。
A proxy that does not act as the ultimate recipient of a mandatory extension declaration MUST NOT remove the extension declaration or the "M-" method name prefix when forwarding the message (see section 5.1 for how to detect when a mandatory extension has been fulfilled).
不作为强制扩展声明最终接收者的代理在转发消息时不得删除扩展声明或“M-”方法名称前缀（有关如何检测强制扩展何时完成的信息，请参见第5.1节）。
A server receiving an HTTP/1.0 (or earlier versions of HTTP) message that includes a Connection header MUST, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the connection-token.
接收包含连接头的HTTP/1.0（或更早版本的HTTP）消息的服务器，对于此字段中的每个连接令牌，必须从消息中删除并忽略与连接令牌同名的任何头字段。
A server receiving a mandatory request including the "M-" method name prefix without any mandatory extension declarations to follow MUST return a 510 (Not Extended) response.
如果服务器接收到包含“M-”方法名称前缀的强制请求，且随后没有任何强制扩展声明，则必须返回510（非扩展）响应。
The "M-" prefix is reserved by this proposal and MUST NOT be used by other HTTP extensions.
“M-”前缀由本提案保留，不得由其他HTTP扩展使用。
A server MUST NOT claim to have fulfilled any mandatory request unless it understood and obeyed all the mandatory extension declarations in the request. This section defines a mechanism for conveying this information to the client in such a way that it interoperates with existing HTTP applications and prevents broken servers from giving the false impression that an extended request was fulfilled by responding with a 200 (Ok) response without understanding the method.
除非服务器理解并遵守请求中的所有强制扩展声明，否则服务器不得声称已满足任何强制请求。本节定义了一种机制，用于将此信息传递给客户端，使其能够与现有HTTP应用程序互操作，并防止损坏的服务器给人一种错误印象，即扩展请求是在不了解方法的情况下通过响应200（Ok）响应来完成的。
If any end-to-end mandatory extension declarations were among the fulfilled extensions then the server MUST include an Ext response header field in the response. In order to avoid that the Ext header field inadvertently is cached in an HTTP/1.1 cache, the response MUST contain a no-cache cache-control directive. If the response is otherwise cachable, the no-cache cache-control directive SHOULD be limited to only affect the Ext header field:
如果在已完成的扩展中包含任何端到端的强制扩展声明，则服务器必须在响应中包含Ext响应头字段。为了避免意外地将Ext header字段缓存在HTTP/1.1缓存中，响应必须包含no cache cache control指令。如果响应是可缓存的，则no cache control指令应限制为仅影响Ext header字段：
HTTP/1.1 200 OK Ext: Cache-Control: no-cache="Ext" ...
HTTP/1.1 200 OK Ext:Cache Control:no Cache=“Ext”。。。
If the mandatory request has been forwarded by an HTTP/1.0 intermediary proxy then this is indicated either directly in the Request-Line or by the presence of an HTTP/1.1 Via header field. In this case, the server MUST include an Expires header field with a date equal to or earlier than the value of the Date header field (see section 9 for a discussion on caching considerations):
如果强制请求已由HTTP/1.0中间代理转发，则直接在请求行中或通过存在HTTP/1.1 Via标头字段来指示。在这种情况下，服务器必须包含日期等于或早于日期头字段值的Expires头字段（有关缓存注意事项的讨论，请参阅第9节）：
HTTP/1.1 200 OK Date: Sun, 25 Oct 1998 08:12:31 GMT Expires: Sun, 25 Oct 1998 08:12:31 GMT Ext: Cache-Control: no-cache="Ext", max-age=3600 ...
HTTP/1.1 200确定日期：Sun，1998年10月25日08:12:31 GMT到期时间：Sun，1998年10月25日08:12:31 GMT外部：缓存控制：no Cache=“Ext”，最大年龄=3600。。。
If any hop-by-hop mandatory extension declarations were among the fulfilled extensions then the server MUST include a C-Ext response header field in the response. The C-Ext header field MUST be protected by a Connection header field (see [5], section 14.10).
如果已完成的扩展中包含任何逐跳强制扩展声明，则服务器必须在响应中包含C-Ext响应头字段。C-Ext头字段必须由连接头字段保护（见[5]，第14.10节）。
HTTP/1.1 200 OK C-Ext: Connection: C-Ext
HTTP/1.1 200正常C-Ext:连接：C-Ext
Note, that the Ext and C-Ext header fields are not mutually exclusive; they can be both be present in a response when fulfilling mandatory request containing both hop-by-hop as well as end-to-end mandatory extension declarations.
请注意，Ext和C-Ext标题字段不是互斥的；当满足包含逐跳和端到端强制扩展声明的强制请求时，它们都可以出现在响应中。
A server MUST NOT include mandatory extension declarations in an HTTP response unless it is responding to a mandatory HTTP request whose definition allowed for the mandatory response or the server has some a priori knowledge that the recipient can handle the extended response. A server MAY include optional extension declarations in any HTTP response (see section 4).
服务器不得在HTTP响应中包含强制扩展声明，除非它响应的是强制HTTP请求，该请求的定义允许强制响应，或者服务器事先知道收件人可以处理扩展响应。服务器可以在任何HTTP响应中包含可选的扩展声明（参见第4节）。
If a client is the ultimate recipient of a mandatory HTTP response containing mandatory extension declarations that either the client does not understand or does not want to use, then it SHOULD discard the complete response as if it were a 500 (Internal Server Error) response.
如果客户机是包含客户机不理解或不想使用的强制扩展声明的强制HTTP响应的最终接收者，那么它应该放弃完整响应，就像它是500（内部服务器错误）响应一样。
The policy for accessing the resource has not been met in the request. The server should send back all the information necessary for the client to issue an extended request. It is outside the scope of this specification to specify how the extensions inform the client.
请求中未满足访问资源的策略。服务器应该发回客户端发出扩展请求所需的所有信息。指定扩展如何通知客户机超出了本规范的范围。
If the 510 response contains information about extensions that were not present in the initial request then the client MAY repeat the request if it has reason to believe it can fulfill the extension policy by modifying the request according to the information provided in the 510 response. Otherwise the client MAY present any entity included in the 510 response to the user, since that entity may include relevant diagnostic information.
如果510响应包含关于初始请求中不存在的扩展的信息，则如果客户端有理由相信它可以通过根据510响应中提供的信息修改请求来实现扩展策略，则客户端可以重复该请求。否则，客户端可以向用户呈现510响应中包括的任何实体，因为该实体可以包括相关的诊断信息。
While the protocol extension definition should be published at the address of the extension identifier, this specification does not require it. The only absolute requirement is that extension identifiers MUST be globally unique identifiers, and that distinct names be used for distinct semantics.
虽然协议扩展定义应该在扩展标识符的地址发布，但本规范不需要它。唯一的绝对要求是扩展标识符必须是全局唯一的标识符，并且不同的名称用于不同的语义。
Likewise, applications are not required to attempt resolving extension identifiers included in an extension declaration. The only absolute requirement is that an application MUST NOT claim conformance with an extension that it does not recognize (regardless of whether it has tried to resolve the extension identifier or not). This document does not provide any policy for how long or how often an application may attempt to resolve an extension identifier.
同样，应用程序也不需要尝试解析扩展声明中包含的扩展标识符。唯一的绝对要求是，应用程序不得声明与它无法识别的扩展一致（无论它是否尝试解析扩展标识符）。对于应用程序尝试解析扩展标识符的时间或频率，本文档不提供任何策略。
The association between the extension identifier and the specification might be made by distributing a specification, which references the extension identifier.
扩展标识符和规范之间的关联可以通过分发引用扩展标识符的规范来实现。
It is strongly recommended that the integrity and persistence of the extension identifier be maintained and kept unquestioned throughout the lifetime of the extension. Care should be taken not to distribute conflicting specifications that reference the same name. Even when an extension specification is made available at the address of the URI, care must be taken that the specification made available at that address does not change over time. One agent may associate the identifier with the old semantics, while another might associate it with the new semantics.
强烈建议在扩展的整个生命周期内保持扩展标识符的完整性和持久性，并使其不受质疑。应注意不要分发引用相同名称的冲突规范。即使在URI地址提供了扩展规范，也必须注意在该地址提供的规范不会随时间而改变。一个代理可以将标识符与旧语义相关联，而另一个代理可以将其与新语义相关联。
The extension definition may be made available in different representations ranging from
扩展定义可以在以下不同的表示形式中提供：
o a human-readable specification defining the extension semantics (see for example [7]),
o 定义扩展语义的人类可读规范（参见示例[7]），
o downloadable code which implements the semantics defined by the extension,
o 实现扩展定义的语义的可下载代码，
o a formal interface description provided by the extension, to
o 扩展提供的正式接口描述，用于
o a machine-readable specification defining the extension semantics.
o 定义扩展语义的机器可读规范。
For example, a software component that implements the specification may reside at the same address as a human-readable specification (distinguished by content negotiation). The human-readable representation serves to document the extension and encourage deployment, while the software component would allow clients and servers to be dynamically extended.
例如，实现该规范的软件组件可以驻留在与人类可读规范相同的地址（通过内容协商来区分）。人类可读的表示用于记录扩展并鼓励部署，而软件组件将允许动态扩展客户端和服务器。
Use of extensions using the syntax defined by this document may have additional implications on the cachability of HTTP response messages other than the ones described in section 5.1.
使用本文档定义的语法的扩展可能会对HTTP响应消息的可访问性产生额外影响，而不是第5.1节中所述的影响。
The originator of an extended message should be able to determine from the semantics of the extension whether or not the extension's presence impacts the caching constraints of the response message. If an extension does require tighter constraints on the cachebility of the response, the originator MUST include the appropriate combination of cache header fields (Cache-Control, Vary, Expires) corresponding to the required level of constraints of the extended semantics.
扩展消息的发起人应该能够根据扩展的语义确定扩展的存在是否会影响响应消息的缓存约束。如果扩展确实需要对响应的可缓存性进行更严格的约束，则发起人必须包括与扩展语义所需约束级别相对应的缓存头字段（缓存控制、更改、过期）的适当组合。
Dynamic installation of extension facilities as described in the introduction involves software written by one party (the provider of the implementation) to be executed under the authority of another (the party operating the host software). This opens the host party to a variety of "Trojan horse" attacks by the provider, or a malicious third party that forges implementations under a provider's name. See, for example RFC2046 [4], section 4.5.2 for a discussion of these risks.
引言中所述的扩展设施的动态安装涉及一方（实施方）编写的软件，该软件将在另一方（运行主机软件的一方）的授权下执行。这会使主机方遭受提供商或恶意第三方的各种“特洛伊木马”攻击，这些恶意第三方伪造提供商名称下的实现。有关这些风险的讨论，请参见RFC2046[4]第4.5.2节。
[1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[1] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[2] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[2] Berners Lee，T.，Fielding，R.和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[3] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[4] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[5] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998.
[7] Masinter，L.，“超文本咖啡壶控制协议（HTCPCP/1.0）”，RFC 23241998年4月1日。
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[8] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[9] Nielsen, H., Connolly, D. and R. Khare, "PEP - an extension mechanism for HTTP", Work in Progress.
[9] Nielsen，H.，Connolly，D.和R.Khare，“PEP-HTTP的扩展机制”，正在进行中。
Roy Fielding, Rohit Khare, Yaron Y. Goland, and Koen Holtman, deserve special recognition for their efforts in commenting in all phases of this specification. Also thanks to Josh Cohen, Ross Patterson, Jim Gettys, Larry Masinter, and to the people involved in PEP [9].
Roy Fielding、Rohit Khare、Yaron Y.Goland和Koen Holtman在本规范所有阶段的评论工作值得特别认可。还要感谢Josh Cohen、Ross Patterson、Jim Gettys、Larry Masinter以及参与政治公众人物计划的人员[9]。
The contribution of World Wide Web Consortium (W3C) staff is part of the W3C HTTP Activity (see "http://www.w3.org/Protocols/Activity").
万维网联盟（W3C）工作人员的贡献是W3C HTTP活动的一部分（请参阅“http://www.w3.org/Protocols/Activity").
Henrik Frystyk Nielsen Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
美国华盛顿州微软路雷德蒙1号亨里克·弗莱斯蒂克·尼尔森微软公司，邮编：98052
EMail: frystyk@microsoft.com
EMail: frystyk@microsoft.com
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
Paul J.Leach微软公司美国华盛顿州微软路雷德蒙1号，邮编：98052
EMail: paulle@microsoft.com
EMail: paulle@microsoft.com
Scott Lawrence Agranat Systems, Inc. 5 Clocktower Place, Suite 400 Maynard, MA 01754, USA
Scott Lawrence Agranat Systems，Inc.美国马萨诸塞州梅纳德市钟塔广场5号400室01754
EMail: lawrence@agranat.com
EMail: lawrence@agranat.com
Appendices
附录
The following tables summarize the outcome of strength and scope rules of the mandatory proposal of compliant and non-compliant HTTP proxies and origin servers. The summary is intended as a guide and index to the text, but is necessarily cryptic and incomplete. This summary should never be used or referenced separately from the complete specification.
下表总结了符合和不符合HTTP代理和源服务器的强制性提案的强度和范围规则的结果。摘要的目的是作为文本的指南和索引，但必须是含糊不清和不完整的。本摘要不得与完整规范分开使用或引用。
Table 1: Origin Server
表1：源服务器
Scope Hop-by-hop End-to-end
范围逐跳端到端
Strength Optional Required Optional Required (may) (must) (may) (must)
强度可选要求可选要求（可能）（必须）（可能）（必须）
Mandatory Standard 501 (Not Standard 501 (Not unsupported processing Implemented) processing Implemented)
强制性标准501（非标准501（未实施不支持的处理）已实施的处理）
Extension Standard 510 (Not Standard 510 (Not unsupported processing Extended) processing Extended) Extension Extended Extended Extended Extended supported processing processing processing processing
扩展标准510（非标准510（非不支持的扩展处理）扩展支持的扩展处理
Table 2: Proxy Server
表2：代理服务器
Scope Hop-by-hop End-to-end
范围逐跳端到端
Strength Optional Required Optional Required (may) (must) (may) (must)
强度可选要求可选要求（可能）（必须）（可能）（必须）
Mandatory Strip 501 (Not Forward 501 (Not unsupported extension Implemented) extension Implemented) or tunnel or tunnel
强制剥离501（未向前501（未实施不受支持的扩展）或隧道或隧道
Extension Strip 510 (Not Forward Forward unsupported extension Extended) extension extension
扩展条510（不向前不支持扩展）扩展
Extension Extended Extended Extended Extended supported processing processing processing, processing, and strip and strip may strip may strip
扩展支持的处理、处理和剥离以及剥离可能剥离可能剥离
The following examples show various scenarios using mandatory in HTTP/1.1 requests and responses. Information not essential for illustrating the examples is left out (referred to as "...")
以下示例显示了在HTTP/1.1请求和响应中使用强制命令的各种场景。没有说明示例所需的信息（称为“…”）
Table 3: User Agent directly to origin server
表3：直接连接到源服务器的用户代理
Client issues a request M-GET /some-document HTTP/1.1 with one optional and Opt: "http://www.my.com/tracking" one mandatory extension Man: "http://www.foo.com/privacy" ...
客户端发出一个请求M-GET/some document HTTP/1.1，其中包含一个可选选项和一个Opt:“http://www.my.com/tracking“一名强制分机员：”http://www.foo.com/privacy" ...
Origin server accepts HTTP/1.1 200 OK the mandatory extension Ext: but ignores the Cache-Control: max-age=120, no-cache="Ext" optional one. The ... client can not see in this case that the optional extension was ignored.
源服务器接受HTTP/1.1 200 OK强制扩展名Ext:但忽略缓存控制：max age=120，no Cache=“Ext”可选。这个在这种情况下，客户端无法看到可选扩展被忽略。
Table 4: Origin server with Vary header field
表4：具有不同标头字段的源服务器
Client issues a request M-GET /p/q HTTP/1.1 with one mandatory Man: "http://www.x.y/transform"; ns=16 extension 16-use-transform: xyzzy ...
客户机发出一个请求M-GET/p/q HTTP/1.1，其中必须有一个Man:“http://www.x.y/transform"; ns=16扩展16使用转换：xyzzy。。。
Origin server accepts HTTP/1.1 200 OK the mandatory but Ext: indicates that the Vary: Man, 16-use-transform response varies on the Date: Sun, 25 Oct 1998 08:12:31 GMT request extension Expires: Sun, 25 Oct 1998 08:12:31 GMT declaration Cache-Control: no-cache="Ext", max-age=1000 ...
Origin server接受HTTP/1.1 200 OK强制但Ext:表示Vary:Man，16 use transform响应在以下日期变化：Sun，1998年10月25日08:12:31 GMT请求扩展到期：Sun，1998年10月25日08:12:31 GMT声明缓存控制：no Cache=“Ext”，max age=1000。。。
These two examples show how an extended request interacts with an HTTP/1.1 proxy.
这两个示例显示了扩展请求如何与HTTP/1.1代理交互。
Table 5: HTTP/1.1 Proxy forwards extended request
表5:HTTP/1.1代理转发扩展请求
Client issues a request M-GET /some-document HTTP/1.1 with one optional and C-Opt: "http://www.meter.org/hits" one mandatory hop-by- C-Man: "http://www.copy.org/rights" hop extension Connection: C-Opt, C-Man ...
客户机发出请求M-GET/some document HTTP/1.1，其中包含一个可选选项和C-Opt:“http://www.meter.org/hits“一个强制的跳跃-C-Man：”http://www.copy.org/rights“跃点扩展连接：C-Opt、C-Man。。。
HTTP/1.1 proxy forwards M-GET /some-document HTTP/1.1 the request and takes Via: 1.1 new out the connection ... headers
HTTP/1.1代理转发M-GET/some document HTTP/1.1请求，并通过：1.1新建连接。。。标题
Origin server fails as HTTP/1.1 510 Not Extended the request does not ... contain any information belonging to the M-GET method
源服务器失败，因为HTTP/1.1 510未扩展请求未。。。包含属于M-GET方法的任何信息
Table 6: HTTP/1.1 Proxy does not forward extended request
表6:HTTP/1.1代理不转发扩展请求
Client issues a request M-GET /some-document HTTP/1.1 with one optional and C-Opt: "http://www.meter.org/hits" one mandatory hop-by- C-Man: "http://www.copy.org/rights" hop extension Connection: C-Opt, C-Man ...
客户机发出请求M-GET/some document HTTP/1.1，其中包含一个可选选项和C-Opt:“http://www.meter.org/hits“一个强制的跳跃-C-Man：”http://www.copy.org/rights“跃点扩展连接：C-Opt、C-Man。。。
HTTP/1.1 proxy refuses HTTP/1.1 501 Not Implemented to forward the M-GET ... method and returns an error
HTTP/1.1代理拒绝未实现HTTP/1.1 501以转发M-GET。。。方法并返回一个错误
Origin server never sees the extended request
源服务器从未看到扩展请求
These two examples show how an extended request interacts with an HTTP/1.0 proxy in the message path
这两个示例显示了扩展请求如何与消息路径中的HTTP/1.0代理交互
Table 7: HTTP/1.0 Proxy forwards extended request
表7:HTTP/1.0代理转发扩展请求
Client issues a request M-GET /some-document HTTP/1.1 with one mandatory Man: "http://www.price.com/sale" extension ...
客户端发出一个请求M-GET/some document HTTP/1.1，其中必须有一个Man:“http://www.price.com/sale“扩展。。。
HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
the request as a Man: "http://www.price.com/sale"
HTTP/1.0 request ...
without changing the
method
HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
the request as a Man: "http://www.price.com/sale"
HTTP/1.0 request ...
without changing the
method
Origin server accepts HTTP/1.1 200 OK declaration and returns Ext: a 200 response and an Date: Sun, 25 Oct 1998 08:12:31 GMT extension Expires: Sun, 25 Oct 1998 08:12:31 GMT acknowledgement. The Cache-Control: no-cache="Ext", max-age=600 response can be cached ... by HTTP/1.1 caches for 10 minutes.
源服务器接受HTTP/1.1 200 OK声明并返回Ext:200响应和日期：Sun，1998年10月25日08:12:31 GMT扩展到期：Sun，1998年10月25日08:12:31 GMT确认。缓存控件：no Cache=“Ext”，可以缓存最大年龄=600的响应。。。通过HTTP/1.1缓存10分钟。
Table 8: HTTP/1.0 and HTTP/1.1 Proxy Chain
Table 8: HTTP/1.0 and HTTP/1.1 Proxy Chain
Client issues request M-GET /some-document HTTP/1.1 with one mandatory and Man: "http://www.copy.org/rights" one hop-by-hop optional C-Opt: "http://www.ads.org/noads" extension Connection: C-Opt ...
客户端发出请求M-GET/some document HTTP/1.1，其中一个为必填项，另一个为Man:“http://www.copy.org/rights“一跳一跳可选C-Opt：”http://www.ads.org/noads“扩展连接：C-Opt。。。
HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
request as HTTP/1.0 Man: "http://www.copy.org/rights"
request without C-Opt: "http://www.ads.org/noads"
changing the method and Connection: C-Man
without honoring the ...
Connection directives
HTTP/1.0 proxy forwards M-GET /some-document HTTP/1.0
request as HTTP/1.0 Man: "http://www.copy.org/rights"
request without C-Opt: "http://www.ads.org/noads"
changing the method and Connection: C-Man
without honoring the ...
Connection directives
HTTP/1.1 proxy deletes M-GET /some-document HTTP/1.1
(and ignores) optional Man: "http://www.copy.org/rights"
extension and forwards C-Man: "http://www.ads.org/givemeads"
the rest including a Connection: C-Man
via header field. It Via: 1.0 new
also add a hop-by-hop ...
mandatory extension
HTTP/1.1 proxy deletes M-GET /some-document HTTP/1.1
(and ignores) optional Man: "http://www.copy.org/rights"
extension and forwards C-Man: "http://www.ads.org/givemeads"
the rest including a Connection: C-Man
via header field. It Via: 1.0 new
also add a hop-by-hop ...
mandatory extension
Origin server accepts HTTP/1.1 200 OK both mandatory Ext: extensions. The C-Ext response is not Connection: C-Ext cachable by the Date: Sun, 25 Oct 1998 08:12:31 GMT HTTP/1.0 cache but can Expires: Sun, 25 Oct 1998 08:12:31 GMT be cached for 1 hour by Cache-Control: no-cache="Ext", max-age=3600 HTTP/1.1 caches. ...
源服务器接受HTTP/1.1 200 OK这两个必需的Ext:扩展。C-Ext响应未连接：C-Ext可在以下日期缓存：Sun，1998年10月25日08:12:31 GMT HTTP/1.0缓存，但可以过期：Sun，1998年10月25日08:12:31 GMT通过缓存控制缓存1小时：no cache=“Ext”，max age=3600 HTTP/1.1缓存。。。
HTTP/1.1 proxy removes HTTP/1.1 200 OK the hop-by-hop Ext: extension Date: Sun, 25 Oct 1998 08:12:31 GMT acknowledgement and Expires: Sun, 25 Oct 1998 08:12:31 GMT forwards the remainder Cache-Control: no-cache="Ext", max-age=3600 of the response. ...
HTTP/1.1代理删除HTTP/1.1 200 OK逐跳扩展：扩展日期：Sun，1998年10月25日08:12:31 GMT确认和过期：Sun，1998年10月25日08:12:31 GMT转发剩余的缓存控制：no Cache=“Ext”，响应的最大年龄=3600。。。
Full Copyright Statement
完整版权声明
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编辑功能的资金目前由互联网协会提供。