Network Working Group A. Rousskov
Request for Comments: 4236 The Measurement Factory
Category: Standards Track M. Stecher
CyberGuard Corporation
November 2005
Network Working Group A. Rousskov
Request for Comments: 4236 The Measurement Factory
Category: Standards Track M. Stecher
CyberGuard Corporation
November 2005
HTTP Adaptation with Open Pluggable Edge Services (OPES)
使用开放式可插拔边缘服务（OPES）进行HTTP适配
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation. Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES.
开放可插拔边缘服务（OPES）框架记录了几种应用程序无关的机制，如OPES跟踪、OPES旁路和OPES调用协议。本文档扩展了超文本传输协议（HTTP）适配的通用机制。应用程序无关的OPES文档和此HTTP配置文件共同构成了一个完整的规范，用于使用OPES进行HTTP适配。
Table of Contents
目录
1. Scope ...........................................................3
2. OPES Document Map ...............................................3
3. Callout Protocol ................................................4
3.1. Application Message Parts ..................................5
3.2. Application Profile Features ...............................6
3.2.1. Profile Parts .......................................6
3.2.2. Profile Structure ...................................8
3.2.3. Aux-Parts ...........................................8
3.2.4. Pause-At-Body .......................................9
3.2.5. Stop-Receiving-Body ................................10
3.2.6. Preservation-Interest-Body .........................10
3.2.7. Content-Encodings ..................................11
3.2.8. Profile Negotiation Example ........................12
3.3. Application Message Start Message .........................13
3.4. DUM Message ...............................................13
3.5. Selective Adaptation ......................................14
3.6. Hop-by-hop Headers ........................................15
3.7. Transfer Encodings ........................................15
3.8. HTTP Header Correctness ...................................16
3.8.1. Message Size Recalculation .........................16
3.8.2. Content-MD5 Header .................................17
3.9. Examples ..................................................18
4. Tracing ........................................................22
5. Bypass .........................................................24
6. IAB Considerations .............................................24
7. Security Considerations ........................................24
8. IANA Considerations ............................................24
9. Compliance .....................................................25
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................25
1. Scope ...........................................................3
2. OPES Document Map ...............................................3
3. Callout Protocol ................................................4
3.1. Application Message Parts ..................................5
3.2. Application Profile Features ...............................6
3.2.1. Profile Parts .......................................6
3.2.2. Profile Structure ...................................8
3.2.3. Aux-Parts ...........................................8
3.2.4. Pause-At-Body .......................................9
3.2.5. Stop-Receiving-Body ................................10
3.2.6. Preservation-Interest-Body .........................10
3.2.7. Content-Encodings ..................................11
3.2.8. Profile Negotiation Example ........................12
3.3. Application Message Start Message .........................13
3.4. DUM Message ...............................................13
3.5. Selective Adaptation ......................................14
3.6. Hop-by-hop Headers ........................................15
3.7. Transfer Encodings ........................................15
3.8. HTTP Header Correctness ...................................16
3.8.1. Message Size Recalculation .........................16
3.8.2. Content-MD5 Header .................................17
3.9. Examples ..................................................18
4. Tracing ........................................................22
5. Bypass .........................................................24
6. IAB Considerations .............................................24
7. Security Considerations ........................................24
8. IANA Considerations ............................................24
9. Compliance .....................................................25
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................25
The Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES processor and endpoints communications [RFC3897] or OPES callout protocol [RFC4037]. This document extends those generic mechanisms for adaptation of a specific application protocol, HTTP [RFC2616]. Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES.
开放可插拔边缘服务（OPES）框架记录了几种应用程序无关机制，如OPES处理器和端点通信[RFC3897]或OPES调用协议[RFC4037]。本文档扩展了适用于特定应用程序协议HTTP[RFC2616]的通用机制。应用程序无关的OPES文档和此HTTP配置文件共同构成了一个完整的规范，用于使用OPES进行HTTP适配。
The primary sections of this document specify HTTP-specific extensions for the corresponding application-agnostic mechanisms documented elsewhere.
本文档的主要部分为其他地方记录的相应应用程序无关机制指定了特定于HTTP的扩展。
This document belongs to a large set of OPES specifications produced by the IETF OPES Working Group. Familiarity with the overall OPES approach and typical scenarios is often essential when trying to comprehend isolated OPES documents. This section provides an index of OPES documents to assist the reader with finding "missing" information.
本文件属于IETF OPES工作组编制的大量OPES规范。在试图理解单独的OPES文件时，熟悉总体OPES方法和典型场景通常是必不可少的。本节提供OPES文档索引，以帮助读者查找“缺失”信息。
o The document on "OPES Use Cases and Deployment Scenarios" [RFC3752] describes a set of services and applications that are considered in scope for OPES and have been used as a motivation and guidance in designing the OPES architecture.
o 关于“OPES用例和部署场景”的文档[RFC3752]描述了OPES范围内考虑的一组服务和应用程序，这些服务和应用程序已被用作设计OPES架构的动机和指导。
o The OPES architecture and common terminology are described in "An Architecture for Open Pluggable Edge Services (OPES)" [RFC3835].
o “开放式可插拔边缘服务（OPES）的体系结构”[RFC3835]中描述了OPES体系结构和通用术语。
o "Policy, Authorization and Enforcement Requirements of OPES" [RFC3838] outlines requirements and assumptions on the policy framework, without specifying concrete authorization and enforcement methods.
o “OPES的政策、授权和执行要求”[RFC3838]概述了政策框架的要求和假设，但未指定具体的授权和执行方法。
o "Security Threats and Risks for OPES" [RFC3837] provides OPES risk analysis, without recommending specific solutions.
o “运营商的安全威胁和风险”[RFC3837]提供运营商风险分析，但不推荐具体解决方案。
o "OPES Treatment of IAB Considerations" [RFC3914] addresses all architecture-level considerations expressed by the IETF Internet Architecture Board (IAB) when the OPES WG was chartered.
o “OPES对IAB考虑事项的处理”[RFC3914]解决了当OPES工作组获得特许时，IETF互联网体系结构委员会（IAB）表示的所有体系结构级考虑事项。
o At the core of the OPES architecture are the OPES processor and the callout server, two network elements that communicate with each other via an OPES Callout Protocol (OCP). The requirements for such protocol are discussed in "Requirements for OPES Callout Protocols" [RFC3836].
o OPES体系结构的核心是OPES处理器和调出服务器，这两个网络元素通过OPES调出协议（OCP）相互通信。“OPES标注协议要求”[RFC3836]中讨论了此类协议的要求。
o "OPES Callout Protocol Core" [RFC4037] specifies an application agnostic protocol core to be used for the communication between OPES processor and callout server.
o “OPES调用协议核心”[RFC4037]指定用于OPES处理器和调用服务器之间通信的应用程序无关协议核心。
o "OPES entities and end points communications" [RFC3897] specifies generic tracing and bypass mechanisms for OPES.
o “运营商实体和端点通信”[RFC3897]规定了运营商的通用跟踪和旁路机制。
o The OCP Core and Communications documents are independent from the application protocol being adapted by OPES entities. Their
o OCP核心文件和通信文件独立于OPES实体采用的应用协议。他们的
generic mechanisms have to be complemented by application-specific profiles. This document, HTTP adaptation with OPES, is such an application profile for HTTP. It specifies how application-agnostic OPES mechanisms are to be used and augmented in order to support adaptation of HTTP messages.
通用机制必须由特定于应用程序的配置文件来补充。本文档“HTTP Adaption with OPES”就是这样一个HTTP应用程序配置文件。它指定如何使用和扩展应用程序无关的OPES机制，以支持HTTP消息的自适应。
o Finally, "P: Message Processing Language" [rules-p] defines a language for specifying what OPES adaptations (e.g., translation) must be applied to what application messages (e.g., e-mail from bob@example.com). P language is meant for configuring application proxies (OPES processors).
o 最后，“P：消息处理语言”[rules-P]定义了一种语言，用于指定必须对哪些应用程序消息（例如，来自bob@example.com). P语言用于配置应用程序代理（OPES处理器）。
This section documents the HTTP profile for the OPES Callout Protocol (OCP) Core [RFC4037]. Familiarity with OCP Core is required to understand the HTTP profile. This section uses OCP Core conventions, terminology, and mechanisms.
本节记录了OPES调用协议（OCP）核心[RFC4037]的HTTP配置文件。需要熟悉OCP核心才能理解HTTP配置文件。本节使用OCP核心约定、术语和机制。
OPES processor communicates its desire to adapt HTTP messages via a Negotiation Offer (NO) message with HTTP-specific feature identifiers documented in Section 3.2. HTTP-specific OCP optimization mechanisms can be negotiated at the same time. A callout server that supports adaptation of HTTP messages has a chance to negotiate what HTTP message parts will participate in adaptation, including negotiation of HTTP request parts as metadata for HTTP response adaptation. Negotiable HTTP message parts are documented in Section 3.1.
OPES处理器通过第3.2节中记录的具有HTTP特定功能标识符的协商报价（NO）消息来传达其适应HTTP消息的愿望。可以同时协商特定于HTTP的OCP优化机制。支持HTTP消息自适应的调出服务器有机会协商哪些HTTP消息部分将参与自适应，包括协商HTTP请求部分作为HTTP响应自适应的元数据。第3.1节中记录了可协商HTTP消息部分。
HTTP profile introduces a new parameter for the Application Message Start (AMS) message to communicate known HTTP message length (HTTP headers often do not convey length information reliably or at all). This parameter is documented in Section 3.3. Section 3.4 documents a mechanism to report HTTP message parts with Data Use Mine (DUM) messages.
HTTP概要文件为应用程序消息开始（AMS）消息引入了一个新参数，用于传递已知的HTTP消息长度（HTTP头通常不可靠或根本不传递长度信息）。该参数记录在第3.3节中。第3.4节记录了使用数据使用挖掘（DUM）消息报告HTTP消息部分的机制。
The remaining OCP sections document various OCP marshaling corner cases such as handling of HTTP transfer encodings and 100 Continue responses.
其余的OCP部分记录了各种OCP封送转角情况，例如处理HTTP传输编码和100个连续响应。
An HTTP message may have several well-known parts: headers, body, and trailers. HTTP OPES processors are likely to have information about HTTP message parts because they have to isolate and interpret HTTP headers and find HTTP message boundaries. Callout servers may either not care about certain parts or may benefit from reusing HTTP OPES processor work on isolating and categorizing interesting parts.
HTTP消息可能有几个众所周知的部分：消息头、消息体和消息尾。HTTP OPES处理器可能具有有关HTTP消息部分的信息，因为它们必须隔离和解释HTTP头并查找HTTP消息边界。Callout服务器可能不关心某些部件，也可能从重用HTTP OPES处理器隔离和分类感兴趣部件的工作中获益。
The following is the declaration of am-part (application message part) type using OCP Core Protocol Element Type Declaration Mnemonic (PETDM):
以下是使用OCP核心协议元素类型声明助记符（PETDM）对am部件（应用程序消息部件）类型的声明：
am-part: extends atom;
am-parts: extends list of am-part;
am-part: extends atom;
am-parts: extends list of am-part;
Figure 1
图1
The following six "am-part" atoms are valid values:
以下六个“am部分”原子是有效值：
request-header: The start-line of an HTTP request message, all request message headers, and the CRLF separator at the end of HTTP headers (compare with section 4.1 of [RFC2616]).
请求标头：HTTP请求消息的起始行、所有请求消息标头和HTTP标头末尾的CRLF分隔符（与[RFC2616]第4.1节相比）。
request-body: The message body of an HTTP request message as defined in section 4.3 of [RFC2616] but not including the trailer.
请求正文：[RFC2616]第4.3节中定义的HTTP请求消息的消息正文，但不包括尾部。
request-trailer: The entity headers of the trailer of an HTTP request message in chunked transfer encoding. This part follows the same syntax as the trailer defined in section 3.6.1 of [RFC2616].
请求尾部：采用分块传输编码的HTTP请求消息尾部的实体头。本部分采用与[RFC2616]第3.6.1节中定义的拖车相同的语法。
response-header: The start-line of an HTTP response message, all response message headers, and the CRLF separator at the end of HTTP headers (compare with section 4.1 of [RFC2616]).
响应头：HTTP响应消息的起始行、所有响应消息头和HTTP头末尾的CRLF分隔符（与[RFC2616]第4.1节相比）。
response-body: The message body of an HTTP response message as defined in section 4.3 of [RFC2616] but not including the trailer.
响应正文：[RFC2616]第4.3节中定义的HTTP响应消息的消息正文，但不包括尾部。
response-trailer: The entity headers of the trailer of an HTTP response message in chunked transfer encoding. This part follows the same syntax as the trailer defined in section 3.6.1 of [RFC2616].
响应尾部：分块传输编码中HTTP响应消息尾部的实体头。本部分采用与[RFC2616]第3.6.1节中定义的拖车相同的语法。
This document defines two HTTP profiles for OCP: request and response profiles. These two profiles are described below. Each profile has a unique feature identifier, a list of original application message parts, and a list of adapted application message parts:
本文档为OCP定义了两个HTTP配置文件：请求和响应配置文件。下面介绍这两个配置文件。每个概要文件都有一个唯一的特征标识符、一个原始应用程序消息部分列表和一个经过调整的应用程序消息部分列表：
profile ID: http://www.iana.org/assignments/opes/ocp/http/request
profile ID: http://www.iana.org/assignments/opes/ocp/http/request
original request parts: request-header, request-body, request-trailer
原始请求部分：请求头、请求体、请求尾部
adapted request parts: request-header, request-body, request-trailer
适应的请求部分：请求头、请求体、请求尾部
adapted response parts: response-header, response-body, response-trailer
适应的响应部件：响应头、响应体、响应拖车
profile ID: http://www.iana.org/assignments/opes/ocp/http/response
profile ID: http://www.iana.org/assignments/opes/ocp/http/response
original transaction parts: request-header (aux), request-body (aux), request-trailer (aux), response-header, response-body, response-trailer
原始事务部分：请求头（aux）、请求正文（aux）、请求尾部（aux）、响应头、响应正文、响应尾部
adapted response parts: response-header, response-body, response-trailer
适应的响应部件：响应头、响应体、响应拖车
The request profile contains two variants of adapted part lists: HTTP request parts and HTTP response parts. Parts marked with an "(aux)" suffix are auxiliary parts that can only be used if explicitly negotiated for a profile. See Section 3.2.1 for specific rules governing negotiation and use of am-parts.
请求配置文件包含两个修改的部件列表变体：HTTP请求部件和HTTP响应部件。标有“（aux）”后缀的零件是辅助零件，只有在明确协商外形后才能使用。有关am部件协商和使用的具体规则，请参见第3.2.1节。
The scope of a negotiated profile is the OCP connection (default) or the service group specified via the SG parameter.
协商配置文件的范围是OCP连接（默认）或通过SG参数指定的服务组。
An OCP agent MUST send application message parts in the order implied by the profile parts lists above. An OCP agent receiving an out-of-order part MAY terminate the transaction with an error.
OCP代理必须按照上面的配置文件部件列表暗示的顺序发送应用程序消息部件。接收到故障部件的OCP代理可能会因错误而终止交易。
An OPES processor MUST NOT send parts that are not listed as "original" in the negotiated profile. A callout server MUST NOT send parts that are not listed as "adapted" in the negotiated profile. An OCP agent receiving an not-listed part MUST terminate the transaction with an error. The informal rationale for the last requirement is to reduce the number of subtle interoperability problems where an agent
OPES处理方不得发送协商配置文件中未列为“原始”的零件。详图索引服务器不得发送协商配置文件中未列为“已调整”的零件。接收未列出部件的OCP代理必须以错误终止交易。最后一个需求的非正式理由是减少代理出现的微妙互操作性问题的数量
thinks that the parts it is sending are understood/used by the other agent when, in fact, they are being ignored or skipped because they are not expected.
认为它正在发送的部分被其他代理理解/使用，而事实上，它们被忽略或跳过，因为它们不是预期的。
Some HTTP messages lack certain parts. For example, many HTTP requests do not have bodies, and most HTTP messages do not have trailers. An OCP agent MUST NOT send (i.e., must skip) absent application message parts.
有些HTTP消息缺少某些部分。例如，许多HTTP请求没有正文，大多数HTTP消息没有尾部。OCP代理不得发送（即，必须跳过）缺少的应用程序消息部分。
An OCP agent MUST send present non-auxiliary parts and it MUST send those present auxiliary parts that were negotiated via the Aux-Parts (Section 3.2.3) parameter. OCP agents MUST NOT send auxiliary parts that were not negotiated via the Aux-Parts (Section 3.2.3) parameter.
OCP代理必须发送当前非辅助部件，并且必须发送通过Aux parts（第3.2.3节）参数协商的当前辅助部件。OCP代理不得发送未通过Aux parts（第3.2.3节）参数协商的辅助零件。
An OCP agent receiving a message part in violation of the above requirements MAY terminate the corresponding transaction with an error.
违反上述要求接收消息部分的OCP代理可能会在出现错误时终止相应的事务。
By design, original parts not included in the adapted parts list cannot be adapted. In other words, a callout service can only adapt parts in the adapted parts list even though it may have access to other parts.
根据设计，不包括在改装零件列表中的原始零件无法改装。换句话说，调出服务只能调整调整调整的零件列表中的零件，即使它可以访问其他零件。
In the request profile, the callout server MUST send either adapted
在请求配置文件中，调出服务器必须发送
request parts or adapted response parts. An OPES processor receiving adapted flow with application message parts from both lists (in violation of the previous rule) MUST terminate the OCP transaction with an error. Informally, the callout server sends adapted response parts to "short-circuit" the HTTP transaction, forcing the OPES processor to return an HTTP response without forwarding an adapted HTTP request. This short-circuiting is useful for responding, for example, to an HTTP request that the callout service defines as forbidden.
请求部分或适应的响应部分。OPES处理器接收来自两个列表的带有应用程序消息部分的适配流（违反先前规则）时，必须以错误终止OCP事务。非正式地，callout服务器发送适应的响应部分以“短路”HTTP事务，迫使OPES处理器返回HTTP响应，而不转发适应的HTTP请求。这种短路对于响应调用服务定义为禁止的HTTP请求非常有用。
Unless explicitly configured to do otherwise, an OPES processor MUST offer all non-auxiliary original parts in Negotiation Offer (NO) messages. See Section 3.5 for this rule rationale and examples of harmful side-effects from selective adaptation.
除非明确配置为其他方式，否则OPES处理器必须在协商报价（NO）消息中提供所有非辅助原始零件。参见第3.5节，了解该规则的基本原理和选择性适应的有害副作用示例。
An HTTP application profile feature extends semantics of the feature type of OCP Core while adding the following named parameters to that type:
HTTP应用程序配置文件功能扩展了OCP Core功能类型的语义，同时向该类型添加了以下命名参数：
o Aux-Parts (Section 3.2.3)
o 辅助零件（第3.2.3节）
o Pause-At-Body (Section 3.2.4)
o 主体处暂停（第3.2.4节）
o Stop-Receiving-Body (Section 3.2.5)
o 停止接收体（第3.2.5节）
o Preservation-Interest-Body (Section 3.2.6)
o 保全权益机构（第3.2.6节）
o Content-Encodings (Section 3.2.7)
o 内容编码（第3.2.7节）
The definition of the HTTP profile feature structure using PETDM follows:
使用PETDM的HTTP配置文件功能结构的定义如下：
HTTP-Profile: extends Feature with {
[Aux-Parts: am-parts];
[Pause-At-Body: size];
[Stop-Receiving-Body: size];
[Preservation-Interest-Body: size];
[Content-Encodings: codings];
};
HTTP-Profile: extends Feature with {
[Aux-Parts: am-parts];
[Pause-At-Body: size];
[Stop-Receiving-Body: size];
[Preservation-Interest-Body: size];
[Content-Encodings: codings];
};
Figure 2
图2
An HTTP profile structure can be used in feature lists of Negotiation Offer (NO) messages and as an anonymous parameter of a Negotiation Response (NR) message. All profile parameters apply to any OCP transaction within profile scope.
HTTP配置文件结构可以用于协商提供（NO）消息的功能列表中，也可以用作协商响应（NR）消息的匿名参数。所有配置文件参数都适用于配置文件范围内的任何OCP事务。
The Aux-Parts parameter of an HTTP response profile can be used to negotiate the inclusion of auxiliary application message parts into the original data flow. The parameter is a possibly empty list of am-part tokens. An OPES processor MAY send an Aux-Parts parameter to advertise availability of auxiliary application message parts. A callout server MAY respond with a possibly empty subset of the parts it needs. The callout server response defines the subset of successfully negotiated auxiliary message parts.
HTTP响应配置文件的Aux Parts参数可用于协商将辅助应用程序消息部分包含到原始数据流中。该参数可能是am部件标记的空列表。OPES处理器可发送Aux Parts参数，以公布辅助应用程序消息部件的可用性。详图索引服务器可能会以其所需零件的一个可能为空的子集进行响应。callout server响应定义成功协商的辅助消息部分的子集。
When receiving a Negotiation Offer (NO) message, the callout server MUST ignore any non-auxiliary part listed in the Aux-Parts parameter. When sending a Negotiation Response (NR) message, the callout server
收到协商报价（否）消息时，callout server必须忽略Aux Parts参数中列出的任何非辅助零件。发送协商响应（NR）消息时，调出服务器
MUST NOT select any application message part that was not explicitly listed in the negotiation offer. In case of a violation of the last rule, the OPES processor MUST terminate the transaction.
不得选择谈判报价中未明确列出的任何应用程序消息部分。如果违反最后一条规则，OPES处理方必须终止交易。
An OPES processor MUST send each negotiated auxiliary part to the callout server, unless the part is absent.
除非零件不存在，否则OPES处理器必须将每个协商的辅助零件发送到callout server。
Example: Aux-Parts: (request-header,request-body)
示例：辅助部件：（请求标头、请求正文）
Figure 3
图3
A callout server MAY use the Pause-At-Body parameter to request a pause in original application message body transmission before original dataflow starts. The parameter's value is of type "offset". The parameter specifies the start of the non-auxiliary application message body suffix that the sender is temporarily not interested in seeing.
调出服务器可以使用Pause At Body参数在原始数据流开始之前请求暂停原始应用程序消息正文传输。参数值的类型为“偏移”。该参数指定发送方暂时不想看到的非辅助应用程序消息正文后缀的开头。
[headers][ body prefix | body suffix ][trailer]
<-- ? --><-- offset --><-- ? ---------------->
<-- equiv. DWP offset ->
[headers][ body prefix | body suffix ][trailer]
<-- ? --><-- offset --><-- ? ---------------->
<-- equiv. DWP offset ->
Figure 4
图4
When an OPES processor receives a Pause-At-Body parameter, it MUST behave as if it has received a Want Data Paused (DWP) message with the corresponding org-offset. Note that the latter offset is different from the Pause-At-Body offset and is unknown until the size of the HTTP message headers is known.
当OPES处理器接收到Pause At Body参数时，它的行为必须如同接收到具有相应组织偏移量的Want Data Paused（DWP）消息一样。请注意，后一个偏移量不同于主体处的暂停偏移量，并且在HTTP消息头的大小已知之前是未知的。
For example, if the Pause-At-Body value is zero, the OPES processor should send a Paused My Data (DPM) message just before it sends the first Data Use Mine (DUM) message with the response-body part in the HTTP response profile. If the Pause-At-Body value is 300, the OPES processor should send a DPM message after transmitting 300 OCTETs for that application message part.
例如，如果“在正文处暂停”值为零，则OPES处理器应在发送带有HTTP响应配置文件中的响应正文部分的第一条数据使用地雷（DUM）消息之前发送暂停的我的数据（DPM）消息。如果“在正文处暂停”值为300，则OPES处理器应在为该应用程序消息部分发送300个八位字节后发送DPM消息。
Example: Pause-At-Body: 0
示例：在正文处暂停：0
Figure 5
图5
A callout server MAY use the Stop-Receiving-Body parameter to imply a Want Stop Receiving Data (DWSR) message behavior before the original dataflow starts. The parameter's value is of type "offset". The parameter specifies an offset into the original, non-auxiliary message body part (request-body in request profile and response-body in response profile).
callout服务器可以使用Stop Receiving Body参数来暗示在原始数据流开始之前想要停止接收数据（DWSR）的消息行为。参数值的类型为“偏移”。该参数指定原始非辅助消息正文部分的偏移量（请求配置文件中的请求正文和响应配置文件中的响应正文）。
A callout service MAY send a Stop-Receiving-Body parameter with its negotiation response if there is a fixed offset into the message body for all transactions of a profile for which a Want Stop Receiving Data (DWSR) message would be sent. An OPES processor MUST behave as if it has received a DWSR message with the corresponding offset. Note that the latter offset is different from the Stop-Receiving-Body offset and is unknown until the size of the HTTP message headers is known.
如果发送想要停止接收数据（DWSR）消息的配置文件的所有事务的消息正文中存在固定偏移量，则调出服务可以发送停止接收正文参数及其协商响应。OPES处理器的行为必须与接收到具有相应偏移量的DWSR消息的行为相同。请注意，后一个偏移量不同于停止接收正文偏移量，并且在HTTP消息头的大小已知之前是未知的。
For example, if the Stop-Receiving-Body value is zero in an HTTP response profile, the OPES processor should send an Application Message End (AME) message with result code 206 immediately after sending the response-header message part and before starting with the response-body message part.
例如，如果HTTP响应概要文件中的停止接收正文值为零，则OPES处理器应在发送响应头消息部分之后和从响应正文消息部分开始之前立即发送结果代码为206的应用消息结束（AME）消息。
Example: Stop-Receiving-Body: 0
示例：停止接收主体：0
Figure 6
图6
The Preservation-Interest-Body parameter can be used to optimize data preservation at the OPES processor. The parameter's value is of type "size" and denominates a prefix size of the original, non-auxiliary message body part (request-body in HTTP request profile and response-body in response profile).
Preservation Interest Body参数可用于优化OPES处理器上的数据保存。该参数的值为“size”类型，并指定原始非辅助消息正文部分（HTTP请求配置文件中的请求正文和响应配置文件中的响应正文）的前缀大小。
A callout service MAY send a Preservation-Interest-Body parameter with its negotiation response if there is a fixed-size prefix of the application message body for which a Data Preservation Interest (DPI) message would be sent. An OPES processor MUST behave as if it receives a DPI message with org-offset zero and org-size equal to the value of the Preservation-Interest-Body parameter.
如果将为其发送数据保存兴趣（DPI）消息的应用程序消息体具有固定大小的前缀，则调出服务可以发送保存兴趣体参数及其协商响应。OPES处理器的行为必须与接收到组织偏移量为零且组织大小等于保留利益主体参数值的DPI消息的行为相同。
For example, if the Preservation-Interest-Body value is zero in an HTTP response profile, the callout server must not send any Data Use Yours (DUY) message for the response-body part; the OPES processor may use this information to optimize its data preservation behavior even before it makes the decision to preserve data.
例如，如果HTTP响应配置文件中的保留兴趣主体值为零，则调出服务器不得为响应主体部分发送任何数据使用（DUY）消息；OPES处理器甚至在决定保存数据之前，就可以使用此信息优化其数据保存行为。
Example: Preservation-Interest-Body: 0
示例：保留权益主体：0
Figure 7
图7
A callout server MAY send a Content-Encodings list to indicate its preferences in content encodings. Encodings listed first are preferred to other encodings. An OPES processor MAY use any content encoding when sending application messages to a callout server.
调出服务器可以发送内容编码列表，以指示其在内容编码中的首选项。首先列出的编码优先于其他编码。OPES处理器在向调出服务器发送应用程序消息时可以使用任何内容编码。
The list of preferred content encodings does not imply lack of support for other encodings. The OPES processor MUST NOT bypass a service just because the actual content encoding does not match the service's preferences.
首选内容编码列表并不意味着缺少对其他编码的支持。OPES处理器不能仅仅因为实际内容编码与服务的首选项不匹配而绕过服务。
If an OCP agent receives an application message that it cannot handle due to specific content encoding, the usual transaction termination rules apply.
如果OCP代理收到由于特定内容编码而无法处理的应用程序消息，则通常的事务终止规则适用。
content-coding: extends atom;
content-codings: extends list of content-coding;
content-coding: extends atom;
content-codings: extends list of content-coding;
Example: Content-Encodings: (gzip)
示例：内容编码：（gzip）
Figure 8
图8
The semantics of content-coding is defined in section 3.5 of [RFC2616].
[RFC2616]第3.5节定义了内容编码的语义。
Example:
P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header,request-body)
})
SG: 5
;
S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header)
Pause-At-Body: 30
Preservation-Interest-Body: 0
Content-Encodings: (gzip)
}
SG: 5
;
Example:
P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header,request-body)
})
SG: 5
;
S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header)
Pause-At-Body: 30
Preservation-Interest-Body: 0
Content-Encodings: (gzip)
}
SG: 5
;
Figure 9
图9
This example shows a negotiation offer made by an OPES processor for a service group (id 5) that has already been created; the callout server sends an adequate negotiation response.
此示例显示了OPES处理器为已创建的服务组（id 5）发出的协商报价；调出服务器发送适当的协商响应。
The OPES processor offers one profile feature for HTTP response messages. Besides the standard message parts, the OPES processor is able to add the header and body of the original HTTP request as auxiliary message parts.
OPES处理器为HTTP响应消息提供了一个配置文件功能。除了标准消息部分外，OPES处理器还可以添加原始HTTP请求的头和正文作为辅助消息部分。
The callout server requests the auxiliary request-header part, but is not interested in receiving the request-body part.
callout服务器请求辅助请求标头部分，但对接收请求正文部分不感兴趣。
The OPES processor sends at most the following message parts, in the specified order, for all transactions in service group 5: request-header, response-header, response-body, response-trailer. Note that the request-body part is not included (because it is an auxiliary part that was not explicitly requested). Some of the response parts may not be sent if the original message lacks them.
OPES处理器最多按指定顺序为服务组5中的所有事务发送以下消息部分：请求标头、响应标头、响应正文、响应尾部。请注意，不包括请求主体部分（因为它是未明确请求的辅助部分）。如果原始消息缺少某些响应部分，则可能不会发送它们。
The callout server indicates through the Preservation-Interest-Body parameter with size zero that it will not send any DUY messages. The OPES processor may therefore preserve no preservation for any transaction of this profile.
callout服务器通过大小为零的Preservation Interest Body参数指示它不会发送任何DUY消息。因此，OPES处理方可能不会保存此配置文件的任何交易。
By sending a Pause-At-Body value of 30, the callout server requests a data pause. The OPES processor sends a Paused My Data (DPM) message immediately after sending at least 30 OCTETs of the response-body part. Thereafter, the OPES processor waits for a Want More Data (DWM) message from the callout service.
通过以正文值30发送暂停，callout server请求数据暂停。OPES处理器在发送至少30个八位字节的响应正文部分后，立即发送暂停我的数据（DPM）消息。此后，OPES处理器等待来自调出服务的“需要更多数据”（DWM）消息。
A new named parameter for Application Message Start (AMS) messages is introduced.
引入了应用程序消息启动（AMS）消息的新命名参数。
AM-EL: size
AM-EL：尺寸
Figure 10
图10
AM-EL value is the size of the request-body part in the HTTP request profile, and is the size of the response-body part in the HTTP response profile, before any transfer codings have been applied (or after all transfer codings have been removed). This definition is consistent with the HTTP entity length definition.
AM-EL值是HTTP请求配置文件中请求正文部分的大小，是HTTP响应配置文件中在应用任何传输编码之前（或删除所有传输编码之后）的响应正文部分的大小。此定义与HTTP实体长度定义一致。
An OCP agent that knows the exact length of the HTTP message entity (see Section 7.2.2 "Entity Length" in [RFC2616]) at the time it sends the AMS message, SHOULD announce this length using the AM-EL named parameter of an AMS message. If the exact entity length is not known, an OCP agent MUST NOT send an AM-EL parameter. Relaying correct entity length can have significant performance advantages for the recipient, and implementations are strongly encouraged to relay known entity lengths. Similarly, relaying incorrect entity length can have drastic correctness consequences for the recipient, and implementations are urged to exercise great care when relaying entity length.
OCP代理在发送AMS消息时知道HTTP消息实体的确切长度（参见[RFC2616]中的第7.2.2节“实体长度”），应使用AMS消息的AM-EL命名参数宣布该长度。如果不知道确切的实体长度，OCP代理不得发送AM-EL参数。中继正确的实体长度对接收者具有显著的性能优势，强烈建议实现中继已知的实体长度。类似地，中继不正确的实体长度可能会对接收者造成严重的正确性后果，因此，在中继实体长度时，应敦促实现非常小心。
An OPES processor receiving an AM-EL parameter SHOULD use the parameter's value in a Content-Length HTTP entity header when constructing an HTTP message, provided a Content-Length HTTP entity header is allowed for the given application message by HTTP (see Section 3.8.1).
接收AM-EL参数的OPES处理器在构造HTTP消息时，应使用内容长度HTTP实体头中的参数值，前提是HTTP允许给定应用程序消息使用内容长度HTTP实体头（见第3.8.1节）。
A new named parameter for Data Use Mine (DUM) messages is introduced.
介绍了一种新的数据使用挖掘（DUM）消息命名参数。
AM-Part: am-part
AM部分：AM部分
Figure 11
图11
An OCP agent MUST send an AM-Part parameter with every DUM message that is a part of an OCP transaction with an HTTP profile. The AM-Part parameter value is a single am-part token. As implied by the syntax, a DUM message can only contain data of a single application message part. One message part can be fragmented into any number of DUM messages with the same AM-Part parameter.
OCP代理必须在作为HTTP配置文件OCP事务一部分的每个DUM消息中发送AM Part参数。AM部件参数值是单个AM部件标记。正如语法所暗示的，DUM消息只能包含单个应用程序消息部分的数据。一个消息部分可以分割成具有相同AM部分参数的任意数量的DUM消息。
The following example shows three DUM messages containing an abridged HTTP response message. The response-body part is fragmented and sent within two DUM messages.
下面的示例显示了三条包含简化HTTP响应消息的DUM消息。响应主体部分被分段，并在两条DUM消息中发送。
Example: P: DUM 88 1 0 Kept: 0 AM-Part: response-header
示例：P:DUM 88 1 0保持：0 AM部分：响应标题
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 51
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 51
; P: DUM 88 1 64 Kept: 64 AM-Part: response-body
; P:DUM 88 1 64保持：64 AM部分：响应体
19:<html><body>This is
;
P: DUM 88 1 83
Kept: 83
AM-Part: response-body
19:<html><body>This is
;
P: DUM 88 1 83
Kept: 83
AM-Part: response-body
32: a simple message.</body></html>
;
32: a simple message.</body></html>
;
Figure 12
图12
The HTTP profile for OCP applies to all HTTP messages. That scope includes HTTP messages such as 1xx (Informational) responses, POST, CONNECT, and OPTIONS requests, as well as responses with extension status codes and requests with extension methods. Unless specifically configured to do otherwise, an OPES processor MUST forward all HTTP messages for adaptation at callout servers. OPES bypass instructions, configured HTTP message handling rules, and OCP-negotiation with a callout server are all examples of an acceptable "specific configuration" that provides an exception to this rule.
OCP的HTTP配置文件适用于所有HTTP消息。该范围包括HTTP消息，如1xx（信息性）响应、POST、CONNECT和OPTIONS请求，以及带有扩展状态代码的响应和带有扩展方法的请求。除非专门配置为执行其他操作，否则OPES处理器必须转发所有HTTP消息，以便在callout服务器上进行自适应。OPE绕过指令、配置的HTTP消息处理规则以及与调用服务器的OCP协商都是可接受的“特定配置”的示例，该配置提供了该规则的例外情况。
While it may seem useless to attempt to adapt "control" messages such as a 100 (Continue) response, skipping such messages by default may lead to serious security flaws and interoperability problems. For example, sensitive company information might be relayed via a
虽然尝试调整“控制”消息（如100（Continue）响应）似乎是无用的，但默认情况下跳过此类消息可能会导致严重的安全缺陷和互操作性问题。例如，敏感的公司信息可能通过
carefully crafted 100 Continue response; or a malicious CONNECT request may not get logged if OPES processor does not forward these messages to a callout service that is supposed to handle them.
精心策划的100人继续回应；或者，如果OPES处理器没有将这些消息转发给应该处理这些消息的调出服务，则可能不会记录恶意连接请求。
By design, OPES processor implementation cannot unilaterally decide that an HTTP message is not worth adapting. It needs a callout server opinion, a configuration setting, or another external information to make the decision.
根据设计，OPES处理器实现不能单方面决定HTTP消息不值得修改。它需要调出服务器意见、配置设置或其他外部信息来做出决策。
HTTP defines several hop-by-hop headers (e.g., Connection) and allows for extension headers to be specified as hop-by-hop ones (via the Connection header mechanism). Depending on the environment and configuration, an OPES processor MAY forward hop-by-hop headers to callout servers and MAY use hop-by-hop headers returned by callout servers to build an HTTP message for the next application hop. However, see Section 3.7 for requirements specific to the Transfer-Encoding header.
HTTP定义了几个逐跳标头（例如，连接），并允许将扩展标头指定为逐跳标头（通过连接标头机制）。根据环境和配置，OPES处理器可能会将逐跳标头转发给callout服务器，并可能会使用callout服务器返回的逐跳标头为下一个应用程序跃点构建HTTP消息。但是，有关传输编码标题的特定要求，请参见第3.7节。
For example, a logging or statistics collection service may want to see hop-by-hop headers sent by the previous application hop to the OPES processor and/or hop-by-hop headers sent by the OPES processor to the next application hop. Another service may actually handle HTTP logic of removing and adding hop-by-hop headers. Many services will ignore hop-by-hop headers. This specification does not define a mechanism for distinguishing these use cases.
例如，日志记录或统计信息收集服务可能希望查看上一个应用程序跃点发送到OPES处理器的逐跃标头和/或OPES处理器发送到下一个应用程序跃点的逐跃标头。另一个服务实际上可以处理删除和添加逐跳标头的HTTP逻辑。许多服务将忽略逐跳标头。本规范没有定义区分这些用例的机制。
HTTP messages may use transfer encodings, a hop-by-hop encoding feature of HTTP. Adaptations that use HTTP transfer encodings have to be explicitly negotiated. This specification does not document such negotiations. In the absence of explicit transfer-encoding negotiations, an OCP agent MUST NOT send transfer-encoded application message bodies.
HTTP messages may use transfer encodings, a hop-by-hop encoding feature of HTTP. Adaptations that use HTTP transfer encodings have to be explicitly negotiated. This specification does not document such negotiations. In the absence of explicit transfer-encoding negotiations, an OCP agent MUST NOT send transfer-encoded application message bodies.translate error, please retry
Informally, the above rule means that the agent or its environment have to make sure that all transfer encodings are stripped from an HTTP message body before it enters OCP scope. An agent MUST terminate the OCP transaction if it has to send an application message body but cannot remove all transfer encodings. Violations of these rules lead to interoperability problems.
非正式地说，上述规则意味着代理或其环境必须确保在HTTP消息体进入OCP范围之前，所有传输编码都已从HTTP消息体中剥离。如果代理必须发送应用程序消息正文，但无法删除所有传输编码，则必须终止OCP事务。违反这些规则会导致互操作性问题。
If an OCP agent receives transfer-encoded application data in violation of the above requirement, the agent MAY terminate the corresponding OCP transaction.
如果OCP代理违反上述要求接收传输编码的应用程序数据，则该代理可以终止相应的OCP事务。
An OPES processor removing transfer encodings MUST remove the Transfer-Encoding header before sending the header part to the callout service. A callout server receiving a Transfer-Encoding header MAY assume that original application data is still transfer-encoded (and terminate the transaction). The OPES processor MUST send a correct Transfer-Encoding header to the next HTTP recipient, independent of what header (if any) the callout server returned.
移除传输编码的OPES处理器必须在将标题部分发送到callout服务之前移除传输编码标题。接收传输编码标头的调出服务器可能会假定原始应用程序数据仍然是传输编码的（并终止事务）。OPES处理器必须向下一个HTTP收件人发送正确的传输编码标头，与callout服务器返回的标头（如果有）无关。
Logging and wiretapping are the examples where negotiating acceptable transfer encodings may be worthwhile. While a callout server may not be able to strip an encoding, it may still want to log the entire message "as is". In most cases, however, the callout server would not be able to meaningfully handle unknown transfer encodings.
日志记录和窃听是值得协商可接受的传输编码的例子。尽管调出服务器可能无法剥离编码，但它可能仍希望“按原样”记录整个消息。然而，在大多数情况下，调用服务器将无法有意义地处理未知的传输编码。
When communicating with HTTP applications, OPES processors MUST ensure correctness of all computable HTTP headers documented in specifications that the processors intend to be compliant with. A computable header is defined as a header whose value can be computed based on the message body alone. For example, the correctness of Content-Length and Content-MD5 headers has to be ensured by processors claiming compliance with HTTP/1.1 ([RFC2616]).
当与HTTP应用程序通信时，OPES处理器必须确保处理器打算遵守的规范中记录的所有可计算HTTP头的正确性。可计算头定义为其值可以仅基于消息体计算的头。例如，必须由声称符合HTTP/1.1（[RFC2616]）的处理器确保内容长度和Content-MD5头的正确性。
Informally and by default, the OPES processor has to validate and eventually recalculate, add, or remove computable HTTP headers in order to build a compliant HTTP message from an adapted application message returned by the callout server. If a particular OPES processor trusts certain HTTP headers that a callout service sends, it can use those headers "as is".
默认情况下，OPES处理器必须非正式地验证并最终重新计算、添加或删除可计算的HTTP头，以便从调出服务器返回的经过调整的应用程序消息中生成符合要求的HTTP消息。如果特定OPES处理器信任callout服务发送的某些HTTP头，则可以“按原样”使用这些头。
An OPES processor MAY forward a partially adapted HTTP message from a callout server to the next callout server, without verifying HTTP header correctness. Consequently, a callout service cannot assume that the HTTP headers it receives are correct or final from an HTTP point of view.
OPES处理器可以将部分调整的HTTP消息从调出服务器转发到下一个调出服务器，而无需验证HTTP头的正确性。因此，调出服务不能从HTTP的角度假设它接收的HTTP头是正确的或最终的。
The following subsections present guidelines for the recalculation of some HTTP headers.
以下小节介绍了重新计算某些HTTP头的指导原则。
By default, an OCP agent MUST NOT trust the Content-Length header that is sent within an HTTP header message part. The message length could be modified by a callout service without adaptation of the HTTP message headers.
默认情况下，OCP代理不能信任HTTP头消息部分中发送的内容长度头。调用服务可以修改消息长度，而无需修改HTTP消息头。
Before sending the HTTP message to the HTTP peer, the OPES processor has to ensure correctness of the message length indication according to section 4.4 of [RFC2616].
在向HTTP对等方发送HTTP消息之前，OPES处理器必须根据[RFC2616]第4.4节确保消息长度指示的正确性。
Besides ensuring HTTP message correctness, good OPES processors set up the message to optimize performance, including minimizing delivery latency. Specifically, indicating the end of a message by closing the HTTP connection ought to be the last resort:
除了确保HTTP消息的正确性外，良好的OPES处理器还设置消息以优化性能，包括最小化传递延迟。具体来说，通过关闭HTTP连接来指示消息的结束应该是最后的手段：
o If the callout server sends an AM-EL parameter with its AMS message, the OPES processor SHOULD use this value to create a Content-Length header to be able to keep a persistent HTTP connection. Note that HTTP rules prohibit a Content-Length header to be used in transfer-encoded messages.
o 如果callout服务器发送AM-EL参数及其AMS消息，则OPES处理器应使用此值创建内容长度标头，以便能够保持持久HTTP连接。请注意，HTTP规则禁止在传输编码消息中使用内容长度头。
o If AM-EL parameter or equivalent entity length information is not available, and HTTP rules allow for chunked transfer encoding, the OPES processor SHOULD use chunked transfer encoding. Note that any Content-Length header has to be removed in this case.
o 如果AM-EL参数或等效实体长度信息不可用，且HTTP规则允许分块传输编码，则OPES处理器应使用分块传输编码。请注意，在这种情况下，必须删除任何内容长度标题。
o If the message size is not known a priori and chunked transfer coding cannot be used, but the OPES processor can wait for the OCP transaction to finish before forwarding the adapted HTTP message on a persistent HTTP connection, then the processor SHOULD compute and add a Content-Length header.
o 如果事先不知道消息大小，并且无法使用分块传输编码，但是OPES处理器可以等待OCP事务完成，然后在持久HTTP连接上转发经过调整的HTTP消息，那么处理器应该计算并添加一个内容长度头。
o Finally, if all optimizations are not applicable, the OPES processor SHOULD delete any Content-Length header and forward adapted data immediately, while indicating the message end by closing the HTTP connection.
o 最后，如果所有优化都不适用，OPES处理器应立即删除任何内容长度头并转发自适应数据，同时通过关闭HTTP连接指示消息结束。
By default, the OPES processor MUST assume that the callout service modifies the content in a way that the MD5 checksum of the message body becomes invalid.
默认情况下，OPES处理器必须假定callout服务修改内容的方式使消息正文的MD5校验和无效。
According to section 14.15 of [RFC2616], HTTP intermediaries must not generate Content-MD5 headers. A recalculation is therefore possible only if the OPES processor is considered authoritative for the entity being adapted. An un-authoritative OPES processor MUST remove the Content-MD5 header unless it detects that the HTTP message was not modified; in this case, it MAY leave the Content-MD5 header in the message. When such detection significantly increases message latency, deleting the Content-MD5 header may be a better option.
根据[RFC2616]第14.15节，HTTP中介机构不得生成Content-MD5标头。因此，只有当OPES处理器被认为是被调整实体的权威时，才有可能重新计算。非权威OPES处理器必须删除Content-MD5头，除非它检测到HTTP消息未被修改；在这种情况下，它可能会在消息中保留Content-MD5头。当这种检测显著增加消息延迟时，删除Content-MD5报头可能是更好的选择。
This is a possible OCP message flow using an HTTP request profile. An end-user wants to access the home page of www.restricted.example.com, through the proxy, but access is denied by a URL blocking service running on the callout server used by the proxy.
这是一个可能的使用HTTP请求配置文件的OCP消息流。最终用户希望通过代理访问www.restricted.example.com的主页，但代理使用的调出服务器上运行的URL阻止服务拒绝访问。
OCP messages from the OPES processor are marked with "P:" and OCP messages from the callout server are marked with "S:". The OCP connection is not closed at the end but kept open for the next OCP transaction.
来自OPES处理器的OCP消息标记为“P:”，来自callout server的OCP消息标记为“S:”。OCP连接在结束时未关闭，但在下一个OCP事务中保持打开状态。
Example:
P: CS;
S: CS;
P: SGC 11 ({"31:ocp-test.example.com/url-filter"});
P: NO ({"53:http://www.iana.org/assignments/opes/ocp/http/request"})
SG: 11
;
S: NR {"53:http://www.iana.org/assignments/opes/ocp/http/request"}
SG: 11
;
P: TS 55 11;
P: AMS 55
AM-EL: 0
;
P: DUM 55 0
Kept: 0
AM-Part: request-header
235:GET http://www.restricted.example.com/ HTTP/1.1
Accept: */*
Accept-Language: de
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; Windows NT 5.0)
Host: www.restricted.example.com
Proxy-Connection: Keep-Alive
Example:
P: CS;
S: CS;
P: SGC 11 ({"31:ocp-test.example.com/url-filter"});
P: NO ({"53:http://www.iana.org/assignments/opes/ocp/http/request"})
SG: 11
;
S: NR {"53:http://www.iana.org/assignments/opes/ocp/http/request"}
SG: 11
;
P: TS 55 11;
P: AMS 55
AM-EL: 0
;
P: DUM 55 0
Kept: 0
AM-Part: request-header
235:GET http://www.restricted.example.com/ HTTP/1.1
Accept: */*
Accept-Language: de
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; Windows NT 5.0)
Host: www.restricted.example.com
Proxy-Connection: Keep-Alive
;
P: AME 55;
S: AMS 55;
S: DUM 55 0
AM-Part: response-header
;
P: AME 55;
S: AMS 55;
S: DUM 55 0
AM-Part: response-header
76:HTTP/1.1 403 Forbidden
Content-Type: text/html
Proxy-Connection: close
76:HTTP/1.1 403 Forbidden
Content-Type: text/html
Proxy-Connection: close
; S: DUM 55 0 AM-Part: response-body
; S:DUM 55上午0时部分：响应体
67:<html><body>You are not allowed to
access this page.</body></html>
;
S: AME 55;
P: TE 55;
S: TE 55;
67:<html><body>You are not allowed to
access this page.</body></html>
;
S: AME 55;
P: TE 55;
S: TE 55;
Figure 13
图13
The next example is a language translation of a small plain text file that gets transferred in an HTTP response. In this example, OCP agents negotiate a profile for the whole OCP connection. The OCP connection remains open in the end of the OCP transaction. (Note that NO and NR messages were rendered with an extra new line to satisfy RFC formatting requirements.)
下一个示例是在HTTP响应中传输的小纯文本文件的语言翻译。在本例中，OCP代理协商整个OCP连接的配置文件。OCP连接在OCP事务结束时保持打开状态。（请注意，没有和NR消息使用额外的新行呈现，以满足RFC格式要求。）
Example:
P: CS;
S: CS;
P: NO
({"54:http://www.iana.org/assignments/opes/ocp/http/response"});
S: NR
{"54:http://www.iana.org/assignments/opes/ocp/http/response"};
P: SGC 12 ({"44:ocp-test.example.com/translate?from=EN&to=DE"});
P: TS 89 12;
P: AMS 89
AM-EL: 86
;
P: DUM 89 0
AM-Part: response-header
Example:
P: CS;
S: CS;
P: NO
({"54:http://www.iana.org/assignments/opes/ocp/http/response"});
S: NR
{"54:http://www.iana.org/assignments/opes/ocp/http/response"};
P: SGC 12 ({"44:ocp-test.example.com/translate?from=EN&to=DE"});
P: TS 89 12;
P: AMS 89
AM-EL: 86
;
P: DUM 89 0
AM-Part: response-header
65:HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 86
65:HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 86
; P: DUM 89 65 AM-Part: response-body
; P:DUM 89 65 AM部分：响应体
86:Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune
;
P: AME 89;
S: AMS 89
AM-EL: 78
;
P: TE 89;
S: DUM 89 0
AM-Part: response-header
86:Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune
;
P: AME 89;
S: AMS 89
AM-EL: 78
;
P: TE 89;
S: DUM 89 0
AM-Part: response-header
65:HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 78
65:HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 78
; S: DUM 89 63 AM-Part: response-body
; S:DUM 89 63 AM部分：响应体
80:Ob's edler im Gemuet, die Pfeil und Schleudern
des wuetenden Geschicks erdulden
;
S: AME 89;
S: TE 89;
80:Ob's edler im Gemuet, die Pfeil und Schleudern
des wuetenden Geschicks erdulden
;
S: AME 89;
S: TE 89;
Figure 14
图14
The following example shows modification of an HTML resource and demonstrates data preservation optimization. The callout server uses a DUY message to send back an unchanged response header part, but because it does not know the size of the altered HTML resource at the time it sends the AMS message, the callout server omits the AM-EL parameter; the OPES processor is responsible for adjusting the Content-Length header.
下面的示例显示了对HTML资源的修改，并演示了数据保存优化。调出服务器使用DUY消息发回未更改的响应头部分，但由于在发送AMS消息时不知道更改的HTML资源的大小，调出服务器省略了AM-EL参数；OPES处理器负责调整内容长度标题。
Example:
P: CS;
S: CS;
P: SGC 10 ({"30:ocp-test.example.com/ad-filter"});
P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header,request-body)
},{"45:http://www.iana.org/assignments/opes/ocp/MIME"})
SG: 10
;
S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header)
Content-Encodings: (gzip)
}
Example:
P: CS;
S: CS;
P: SGC 10 ({"30:ocp-test.example.com/ad-filter"});
P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header,request-body)
},{"45:http://www.iana.org/assignments/opes/ocp/MIME"})
SG: 10
;
S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header)
Content-Encodings: (gzip)
}
SG: 10
;
P: TS 88 10;
P: AMS 88
AM-EL: 95
;
P: DUM 88 0
AM-Part: request-header
SG: 10
;
P: TS 88 10;
P: AMS 88
AM-EL: 95
;
P: DUM 88 0
AM-Part: request-header
65:GET /opes/adsample.html HTTP/1.1
Host: www.martin-stecher.de
65:GET /opes/adsample.html HTTP/1.1
Host: www.martin-stecher.de
; P: DUM 88 65
; P:DUM 88 65
Kept: 65 64 AM-Part: response-header
保留：65 64 AM部分：响应标题
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 95
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 95
; P: DUM 88 129 Kept: 65 90 AM-Part: response-body
; P:DUM 88 129保持：65 90 AM部分：响应体
26:<html>
<body>
This is my
;
S: AMS 88;
P: DUM 88 155
Kept: 65 158
AM-Part: response-body
26:<html>
<body>
This is my
;
S: AMS 88;
P: DUM 88 155
Kept: 65 158
AM-Part: response-body
68: new ad: <img src="my_ad.gif"
width=88 height=31>
</body>
</html>
;
S: DUY 88 65 64
S: DPI 88 129 2147483647;
P: AME 88;
S: DUM 88 0
AM-Part: response-body
68: new ad: <img src="my_ad.gif"
width=88 height=31>
</body>
</html>
;
S: DUY 88 65 64
S: DPI 88 129 2147483647;
P: AME 88;
S: DUM 88 0
AM-Part: response-body
52:<html>
<body>
This is my new ad:
</body>
</html>
;
S: DPI 88 129 0;
P: TE 88;
S: AME 88;
S: TE 88;
52:<html>
<body>
This is my new ad:
</body>
</html>
;
S: DPI 88 129 0;
P: TE 88;
S: AME 88;
S: TE 88;
Figure 15
图15
[RFC3897] defines application-agnostic tracing facilities in OPES. Compliance with this specification requires compliance with [RFC3897]. When adapting HTTP, trace entries are supplied using HTTP message headers. The following HTTP extension headers are defined to carry trace entries. Their definitions are given using BNF notation and elements defined in [RFC2616].
[RFC3897]定义了OPE中的应用程序无关跟踪设施。符合本规范要求符合[RFC3897]。在适应HTTP时，使用HTTP消息头提供跟踪条目。以下HTTP扩展头被定义为携带跟踪条目。它们的定义使用BNF符号和[RFC2616]中定义的元素给出。
OPES-System = "OPES-System" ":" #trace-entry
OPES-Via = "OPES-Via" ":" #trace-entry
OPES-System = "OPES-System" ":" #trace-entry
OPES-Via = "OPES-Via" ":" #trace-entry
trace-entry = opes-agent-id *( ";" parameter )
opes-agent-id = absoluteURI
trace-entry = opes-agent-id *( ";" parameter )
opes-agent-id = absoluteURI
Figure 16
图16
An OPES System MUST add its trace entry to the OPES-System header. Other OPES agents MUST use the OPES-Via header if they add their tracing entries. All OPES agents MUST append their entries. Informally, OPES-System is the only required OPES tracing header while OPES-Via provides optional tracing details; both headers reflect the order of trace entry additions.
OPES系统必须将其跟踪条目添加到OPES系统标题中。其他OPES代理如果添加跟踪条目，则必须通过标题使用OPES。所有OPE代理必须附加其条目。非正式地说，OPES系统是唯一需要的OPES跟踪头，而OPES Via提供可选的跟踪细节；两个标题都反映了跟踪条目添加的顺序。
If an OPES-Via header is used in the original application message, an OPES System MUST append its entry to the OPES-Via header. Otherwise, an OPES System MAY append its entry to the OPES-Via header. If an OPES System is using both headers, it MUST add identical trace entries except it MAY omit some or all trace-entry parameters from the OPES-Via header. Informally, the OPES System entries in the OPES-Via header are used to delimit and group OPES-Via entries from different OPES Systems without having a priory knowledge about OPES System identifiers.
如果原始应用程序消息中使用了OPES Via标头，则OPES系统必须将其条目附加到OPES Via标头。否则，OPES系统可能会通过标题将其条目附加到OPES。如果OPES系统同时使用两个标头，它必须添加相同的跟踪条目，除非它可能通过标头从OPES中省略一些或所有跟踪条目参数。非正式地说，OPES Via标题中的OPES系统条目用于通过来自不同OPES系统的条目对OPES进行划分和分组，而无需事先了解OPES系统标识符。
Note that all of these headers are defined using #list constructs and, hence, a valid HTTP message may contain multiple trace entries per header. OPES agents SHOULD use a single header-field rather than using multiple equally-named fields to record a long trace. Using multiple equally-named extension header-fields is illegal from HTTP's point of view and may not work with some of the OPES-unaware HTTP proxies.
请注意，所有这些头都是使用#列表结构定义的，因此，有效的HTTP消息可能包含每个头的多个跟踪条目。OPES代理应使用单个标题字段，而不是使用多个同名字段来记录长跟踪。从HTTP的角度来看，使用多个同名的扩展头字段是非法的，并且可能无法与一些OPE不知道的HTTP代理一起工作。
For example, here is an HTTP response message header after OPES adaptations have been applied by a single OPES processor executing 10 OPES services:
例如，以下是执行10个OPES服务的单个OPES处理器应用OPES自适应后的HTTP响应消息头：
Example:
HTTP/1.1 200 OK
Date: Thu, 18 Sep 2003 06:25:24 GMT
Last-Modified: Wed, 17 Sep 2003 18:24:25 GMT
Content-type: application/octet-stream
OPES-System: http://www.cdn.example.com/opes?session=ac79a749f56
OPES-Via: http://www.cdn.example.com/opes?session=ac79a749f56,
http://www.srvcs-4u.example.com/cat/?sid=123,
http://www.srvcs-4u.example.com/cat/?sid=124,
http://www.srvcs-4u.example.com/cat/?sid=125 ; mode=A
Example:
HTTP/1.1 200 OK
Date: Thu, 18 Sep 2003 06:25:24 GMT
Last-Modified: Wed, 17 Sep 2003 18:24:25 GMT
Content-type: application/octet-stream
OPES-System: http://www.cdn.example.com/opes?session=ac79a749f56
OPES-Via: http://www.cdn.example.com/opes?session=ac79a749f56,
http://www.srvcs-4u.example.com/cat/?sid=123,
http://www.srvcs-4u.example.com/cat/?sid=124,
http://www.srvcs-4u.example.com/cat/?sid=125 ; mode=A
Figure 17
图17
In the above example, the OPES processor has not included its trace entry or its trace entry was replaced by an OPES system trace entry. Only 3 out of 10 services are traced. The remaining services did not include their entries or their entries were removed by OPES system or processor. The last traced service included a "mode" parameter. Various identifiers in trace entries will probably have no meaning to the recipient of the message, but may be decoded by OPES System software.
在上述示例中，OPES处理器未包含其跟踪条目，或者其跟踪条目已被OPES系统跟踪条目替换。10项服务中只有3项被追踪。其余服务不包括其条目，或其条目已被OPES系统或处理器删除。上次跟踪的服务包含一个“mode”参数。跟踪条目中的各种标识符可能对消息接收者没有意义，但可由OPES系统软件解码。
OPES entities MAY place optional tracing entries in a message trailer (i.e., entity-headers at the end of a Chunked-Body of a chunked-encoded message), provided trailer presence does not violate HTTP protocol. See [RFC3897] for a definition of what tracing entries are optional. OPES entities MUST NOT place required tracing entries in a message trailer.
OPES实体可以将可选的跟踪条目放在消息尾部（即，实体头位于分块编码消息的分块体的末尾），前提是尾部的存在不违反HTTP协议。有关哪些跟踪条目是可选的定义，请参见[RFC3897]。OPES实体不得将所需的跟踪条目放在消息尾部。
An HTTP extension header is introduced to allow for OPES system bypass as defined in [RFC3897].
引入HTTP扩展头以允许[RFC3897]中定义的OPES系统旁路。
OPES-Bypass = "OPES-Bypass" ":" ( "*" | 1#bypass-entry )
bypass-entry = opes-agent-id
OPES-Bypass = "OPES-Bypass" ":" ( "*" | 1#bypass-entry )
bypass-entry = opes-agent-id
Figure 18
图18
This header can be added to HTTP requests to request OPES system bypass for the listed OPES agents. The asterisk "*" character is used to represent all possible OPES agents.
此标头可以添加到HTTP请求中，以请求列出的OPES代理的OPES系统旁路。星号“*”字符用于表示所有可能的OPES代理。
See [RFC3897] for what can be bypassed and for bypass requirements.
请参阅[RFC3897]了解可以绕过的内容和旁路要求。
OPES treatment of IETF Internet Architecture Board (IAB) considerations [RFC3238] are documented in "OPES Treatment of IAB Considerations" [RFC3914].
IETF互联网体系结构委员会（IAB）考虑因素的OPES处理[RFC3238]记录在“IAB考虑因素的OPES处理”[RFC3914]中。
Application-independent security considerations are documented in application-agnostic OPES specifications. HTTP profiles do not introduce any HTTP-specific security considerations. However, that does not imply that HTTP adaptations are immune from security threats.
独立于应用程序的安全注意事项记录在应用程序无关的OPES规范中。HTTP配置文件不引入任何特定于HTTP的安全注意事项。然而，这并不意味着HTTP适应可以免受安全威胁。
Specific threat examples include such adaptations as rewriting the Request-URI of an HTTP CONNECT request or removing an HTTP hop-by-hop Upgrade header before the HTTP proxy can act on it. As with any adaptation, the OPES agents MUST NOT perform such actions without HTTP client or server consent.
具体的威胁示例包括改写HTTP CONNECT请求的请求URI，或在HTTP代理对其进行操作之前删除HTTP逐跳升级头。与任何自适应一样，未经HTTP客户端或服务器同意，OPES代理不得执行此类操作。
The IANA registers request and response profile features (Section 3.2) using the registration procedure outlined in the "IANA Considerations" Section of OCP Core [RFC4037]. The corresponding "uri" parameters for the two features are:
IANA使用OCP核心[RFC4037]中“IANA注意事项”一节中概述的注册程序注册请求和响应配置文件功能（第3.2节）。这两个功能对应的“uri”参数为：
o http://www.iana.org/assignments/opes/ocp/http/request
o http://www.iana.org/assignments/opes/ocp/http/request
o http://www.iana.org/assignments/opes/ocp/http/response
o http://www.iana.org/assignments/opes/ocp/http/response
Compliance with OPES mechanisms is defined in corresponding application-agnostic specifications. HTTP profiles for these mechanisms use corresponding compliance definitions from these specifications, as if each profile were incorporated into the application-agnostic specification it profiles.
与OPES机制的符合性在相应的应用不可知规范中定义。这些机制的HTTP配置文件使用这些规范中相应的符合性定义，就好像每个配置文件都被合并到应用程序无关的规范it配置文件中一样。
[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月。
[RFC3897] Barbir, A., "Open Pluggable Edge Services (OPES) Entities and End Points Communication", RFC 3897, September 2004.
[RFC3897]Barbir，A.，“开放可插拔边缘服务（OPES）实体和端点通信”，RFC 3877，2004年9月。
[RFC4037] Rousskov, A., "Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core", RFC 4037, March 2005.
[RFC4037]Rousskov，A.，“开放可插拔边缘服务（OPES）呼叫协议（OCP）核心”，RFC 4037，2005年3月。
[RFC3835] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[RFC3835]Barbir，A.，Penno，R.，Chen，R.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的体系结构”，RFC 3835，2004年8月。
[RFC3836] Beck, A., Hofmann, M., Orman, H., Penno, R., and A. Terzis, "Requirements for Open Pluggable Edge Services (OPES) Callout Protocols", RFC 3836, August 2004.
[RFC3836]Beck，A.，Hofmann，M.，Orman，H.，Penno，R.，和A.Terzis，“开放式可插拔边缘服务（OPES）调用协议的要求”，RFC 38362004年8月。
[RFC3837] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. Orman, "Security Threats and Risks for Open Pluggable Edge Services (OPES)", RFC 3837, August 2004.
[RFC3837]Barbir，A.，Batuner，O.，Srinivas，B.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的安全威胁和风险”，RFC 3837，2004年8月。
[RFC3752] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R. Penno, "Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios", RFC 3752, April 2004.
[RFC3752]Barbir，A.，Burger，E.，Chen，R.，McHenry，S.，Orman，H.，和R.Penno，“开放可插拔边缘服务（OPES）用例和部署场景”，RFC 37522004年4月。
[RFC3838] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman, "Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)", RFC 3838, August 2004.
[RFC3838]Barbir，A.，Batuner，O.，Beck，A.，Chan，T.，和H.Orman，“开放式可插拔边缘服务（OPES）的政策、授权和实施要求”，RFC 3838，2004年8月。
[rules-p] Beck, A. and A. Rousskov, "P: Message Processing Language", work in progress, October 2003.
[rules-p]Beck，A.和A.Rousskov，“p:消息处理语言”，正在进行的工作，2003年10月。
[RFC3914] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) Treatment of IAB Considerations", RFC 3914, October 2004.
[RFC3914]Barbir，A.和A.Rousskov，“开放可插拔边缘服务（OPES）对IAB考虑因素的处理”，RFC 3914，2004年10月。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238]Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB体系结构和政策考虑”，RFC 3238，2002年1月。
Acknowledgements
致谢
The authors gratefully acknowledge the contributions of Robert Collins (Syncretize) and Larry Masinter (Adobe). Larry Masinter provided an early review of this document.
作者衷心感谢Robert Collins（Syncretize）和Larry Masinter（Adobe）的贡献。Larry Masinter对该文件进行了早期审查。
Authors' Addresses
作者地址
Alex Rousskov The Measurement Factory
亚历克斯·罗斯科夫测量工厂
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
Martin Stecher CyberGuard Corporation Vattmannstr. 3 Paderborn 33100 DE
马丁·斯蒂彻·赛博卫士公司Vattmannstr。3帕德伯恩33100德
EMail: martin.stecher@webwasher.com
URI: http://www.webwasher.com/
EMail: martin.stecher@webwasher.com
URI: http://www.webwasher.com/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。