RFC4236 日本語訳
4236 HTTP Adaptation with Open Pluggable Edge Services (OPES). A.Rousskov, M. Stecher. November 2005. (Format: TXT=53512 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Rousskov
Request for Comments: 4236 The Measurement Factory
Category: Standards Track M. Stecher
CyberGuard Corporation
November 2005
Rousskovがコメントのために要求するワーキンググループA.をネットワークでつないでください: 4236 測定工場のカテゴリ: 標準化過程M.ステッチャーCyberGuard社の2005年11月
HTTP Adaptation with Open Pluggable Edge Services (OPES)
開いているPluggable縁のサービスとの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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
作品のたどるのや、作品迂回や、作品calloutなどの数個のアプリケーション不可知論者メカニズムが議定書の中で述べるPluggable Edge Services(作品)フレームワークドキュメントを開いてください。 このドキュメントはハイパーテキストTransferプロトコル(HTTP)適合のためにそれらのジェネリックメカニズムを広げています。 アプリケーション不可知論者作品ドキュメントとこのHTTPプロフィールは作品とのHTTP適合のための完全な仕様を一緒に、成立させます。
Rousskov & Stecher Standards Track [Page 1] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[1ページ]。
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. 範囲…3 2. 作品は地図を記録します…3 3. Calloutは議定書を作ります…4 3.1. アプリケーションメッセージの部品…5 3.2. アプリケーションプロフィール機能…6 3.2.1. 部品の輪郭を描いてください…6 3.2.2. 構造の輪郭を描いてください…8 3.2.3. 補助の部分…8 3.2.4. ボディーに止まってください…9 3.2.5. ボディーを受ける停止…10 3.2.6. 保存関心本体…10 3.2.7. 満足しているEncodings…11 3.2.8. 交渉の例の輪郭を描いてください…12 3.3. アプリケーションメッセージ開始メッセージ…13 3.4. DUMメッセージ…13 3.5. 選択している適合…14 3.6. ホップごとのヘッダー…15 3.7. Encodingsを移してください…15 3.8. HTTPヘッダの正当性…16 3.8.1. メッセージサイズ再計算…16 3.8.2. 内容-MD5ヘッダー…17 3.9. 例…18 4. たどります。22 5. 迂回します。24 6. IAB問題…24 7. セキュリティ問題…24 8. IANA問題…24 9. 承諾…25 10. 参照…25 10.1. 標準の参照…25 10.2. 有益な参照…25
Rousskov & Stecher Standards Track [Page 2] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[2ページ]。
1. Scope
1. 範囲
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.
オープンPluggable Edge Services(作品)フレームワークは作品プロセッサと終点コミュニケーション[RFC3897]か作品calloutプロトコル[RFC4037]などの数個のアプリケーション不可知論者メカニズムを記録します。 このドキュメントは特定のアプリケーション・プロトコル、HTTP[RFC2616]の適合のためにそれらのジェネリックメカニズムを広げています。 アプリケーション不可知論者作品ドキュメントとこのHTTPプロフィールは作品とのHTTP適合のための完全な仕様を一緒に、成立させます。
The primary sections of this document specify HTTP-specific extensions for the corresponding application-agnostic mechanisms documented elsewhere.
このドキュメントのプライマリセクションはほかの場所に記録された対応するアプリケーション不可知論者メカニズムのためのHTTP特有の拡大を指定します。
2. OPES Document Map
2. 作品ドキュメント地図
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作業部会によって作り出された大きい作品仕様に属します。 孤立している作品ドキュメントを理解しようとするとき、総合的な作品アプローチと典型的なシナリオへの親しみはしばしば不可欠です。 このセクションは、「なくなった」情報を見つけるのに読者を補助するために作品ドキュメントのインデックスを提供します。
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 「作品はケースと展開シナリオを使用するところ」の[RFC3752]ドキュメントは作品アーキテクチャを設計する際に作品のために範囲で考えられて、動機と指導として利用された1セットのサービスとアプリケーションについて説明します。
o The OPES architecture and common terminology are described in "An
Architecture for Open Pluggable Edge Services (OPES)" [RFC3835].
o 「開いているPluggable縁のサービス(作品)のためのアーキテクチャ」[RFC3835]で作品アーキテクチャと一般的な用語は説明されます。
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 「作品の方針、Authorization、およびEnforcement Requirements」[RFC3838]は方針フレームワークに要件と仮定について概説します、具体的な承認と実施メソッドを指定しないで。
o "Security Threats and Risks for OPES" [RFC3837] provides OPES risk
analysis, without recommending specific solutions.
o 特定のソリューションを推薦しないで、「作品のためのセキュリティThreatsとRisks」[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 「IAB Considerationsの作品Treatment」[RFC3914]はOPES WGがチャーターされたとき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 作品アーキテクチャのコアに、作品プロセッサとcalloutサーバがあります、作品Calloutプロトコル(OCP)で互いにコミュニケートする2つのネットワーク要素。 「作品Calloutプロトコルのための要件」[RFC3836]でそのようなプロトコルのための要件について議論します。
Rousskov & Stecher Standards Track [Page 3] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[3ページ]。
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 「作品CalloutプロトコルCore」[RFC4037]は、作品プロセッサとcalloutサーバとのコミュニケーションに使用されるためにアプリケーション不可知論者プロトコルコアを指定します。
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 CoreとCommunicationsドキュメントは作品実体によって適合させられるアプリケーション・プロトコルから独立しています。 それら
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適合)はHTTPのためのそのようなアプリケーションプロフィールです。 それは、アプリケーション不可知論者作品メカニズムが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:」 「メッセージProcessing Language」[pを統治している]は、どんな作品適合(例えば、翻訳)をどんなアプリケーションメッセージに適用しなければならないかを指定するために言語を定義します(例えば、 bob@example.com から、メールしてください)。 P言語は、アプリケーションプロキシ(作品プロセッサ)を構成するために意味されます。
3. Callout Protocol
3. Calloutプロトコル
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.
このセクションは作品Calloutプロトコル(OCP)コア[RFC4037]のためのHTTPプロフィールを記録します。 OCP Coreへの親しみが、HTTPプロフィールを理解するのに必要です。 このセクションはOCP Coreコンベンション、用語、およびメカニズムを使用します。
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.
作品プロセッサはHTTP特有の特徴識別子がセクション3.2に記録されているNegotiation Offer(いいえ)メッセージでHTTPメッセージを適合させる願望を伝えます。 同時に、HTTP特有のOCP最適化メカニズムを交渉できます。 HTTPメッセージの適合をサポートするcalloutサーバはHTTP応答適合のためのメタデータとして適合に参加して、HTTP要求の部品の交渉を含んでいて、HTTPメッセージの部品が交渉することを交渉する機会を持っています。 交渉可能なHTTPメッセージの部品はセクション3.1に記録されます。
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プロフィールは知られているHTTPメッセージ長を伝えるApplication Message Start(AMS)メッセージのための新しいパラメタを紹介します(HTTPヘッダは全くしばしば長さの情報を確かに伝えるというわけではありません)。 このパラメタはセクション3.3に記録されます。 セクション3.4は、Data Use Mine(DUM)メッセージでHTTPメッセージの部品を報告するためにメカニズムを記録します。
The remaining OCP sections document various OCP marshaling corner cases such as handling of HTTP transfer encodings and 100 Continue responses.
残っているOCP部はHTTP転送encodingsと100のContinue応答の取り扱いの様々なOCP整理している角のケースを記録します。
Rousskov & Stecher Standards Track [Page 4] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[4ページ]。
3.1. Application Message Parts
3.1. アプリケーションメッセージの部品
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ヘッダを解釈して、HTTPメッセージ限界を見つけるので、HTTP作品プロセッサはHTTPメッセージの部品の情報を持っていそうです。 Calloutサーバは、ある部分を心配しないか、またはおもしろい部分を隔離して、分類するとのHTTP作品プロセッサ取り組みを再利用するのから利益を得るかもしれません。
The following is the declaration of am-part (application message part) type using OCP Core Protocol Element Type Declaration Mnemonic (PETDM):
↓これが宣言である、午前、-離れてください、(アプリケーションメッセージ部分) OCP CoreプロトコルElement Type Declaration Mnemonic(PETDM)を使用することで、タイプしてください:
am-part: extends atom; am-parts: extends list of am-part;
午前、-離れてください、: 原子を広げています。 午前、-、部品、: リストを広げている、午前、-離れてください、。
Figure 1
図1
The following six "am-part" atoms are valid values:
以下の6、「午前、-離れてください、」 原子は有効値です:
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のトレーラの実体ヘッダーはchunked転送コード化におけるメッセージを要求します。 この部分は.1セクション3.6[RFC2616]で定義されたトレーラと同じ構文に従います。
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ヘッダ([RFC2616]のセクション4.1と、比較する)の終わりのHTTP応答メッセージ、すべての応答メッセージヘッダー、およびCRLF分離符のスタート系列。
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].
応答トレーラ: chunked転送コード化におけるHTTP応答メッセージのトレーラの実体ヘッダー。 この部分は.1セクション3.6[RFC2616]で定義されたトレーラと同じ構文に従います。
Rousskov & Stecher Standards Track [Page 5] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[5ページ]。
3.2. Application Profile Features
3.2. アプリケーションプロフィール機能
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のための2個のHTTPプロフィールを定義します: 要求と応答プロフィール。 これらの2個のプロフィールが以下で説明されます。 各プロフィールには、ユニークな特徴識別子、原出願メッセージの部品のリスト、および適合しているアプリケーションメッセージ部分のリストがあります:
profile ID: http://www.iana.org/assignments/opes/ocp/http/request
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
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
元のトランザクション部分: 要求ヘッダー(補助の)、(補助)の、そして、トレーラを要求している(補助の)要求本体応答ヘッダ、応答本体、応答トレーラ
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.
要求プロフィールは適合している部分リストの2つの異形を含んでいます: HTTP要求の部品とHTTP応答の部品。 「(補助の)」接尾語で示される部品はプロフィールのために明らかに交渉される場合にだけ使用できる補足編です。 特定の規則のためのセクション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パラメタで指定されたサービスグループです。
3.2.1. Profile Parts
3.2.1. プロフィールの部品
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
作品プロセッサは「オリジナル」として交渉されたプロフィールに記載されていない部品を送ってはいけません。 calloutサーバは交渉されたプロフィールで「適合させられる」ように記載されなかった部分を送ってはいけません。 記載されなかった部分を受け取るOCPエージェントは誤りでトランザクションを終えなければなりません。 最後の要件のための非公式の原理が微妙な相互運用性問題の数を減少させることである、どこ、エージェント
Rousskov & Stecher Standards Track [Page 6] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[6ページ]。
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-部品(セクション3.2.3)パラメタで交渉されたそれらの現在の補足編を送らなければなりません。 OCPエージェントはAux-部品(セクション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.
故意に、適合しているパーツ・リストに含まれていなかったオリジナル分冊は適合させることができません。 言い換えれば、他の部品に近づく手段を持っているかもしれませんが、calloutサービスは適合しているパーツ・リストで部品を適合させることができるだけです。
In the request profile, the callout server MUST send either adapted
要求プロフィールでは、calloutサーバは適合させられた状態で発信しなければなりません。
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.
部分か適合している応答部分を要求してください。 アプリケーションメッセージの部品で両方のリスト(前の規則を違反した)から適合している流れを受ける作品プロセッサは誤りでOCPトランザクションを終えなければなりません。 非公式に、calloutサーバは「短絡」へのHTTPトランザクションを適合している応答部分に送ります、作品プロセッサに適合しているHTTP要求を転送しないでHTTP応答を返させて。 この短絡は例えば、calloutサービスが禁じられるように定義する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.
別の方法でするために明らかに構成されない場合、作品プロセッサはNegotiation Offerのすべての非補助のオリジナル分冊にどんなメッセージも提供してはいけません。 選択している適合からの有害な副作用のこの規則原理と例に関してセクション3.5を見てください。
Rousskov & Stecher Standards Track [Page 7] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[7ページ]。
3.2.2. Profile Structure
3.2.2. プロフィール構造
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 内容-Encodings(セクション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プロフィール: Featureを広げている、[補助の部分:、午前、-、部品、]、; [ボディーのくぎり: サイズ]; [停止受信本体: サイズ]; [保存関心本体: サイズ]; [内容-Encodings: コーディング];、。
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.
Negotiation Offer(いいえ)メッセージの特徴リストと、そして、Negotiation Response(NR)メッセージの匿名のパラメタとしてHTTPプロフィール構造を使用できます。 すべてのプロフィールパラメタがプロフィール範囲の中のどんなOCPトランザクションにも適用されます。
3.2.3. Aux-Parts
3.2.3. 補助の部分
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-部品パラメタを使用できます。 パラメタがことによると空のリストである、午前、-離れてください、トークン。 作品プロセッサは、補助のアプリケーションメッセージ部分の有用性の広告を出すためにAux-部品パラメタを送るかもしれません。 calloutサーバはそれが必要とする部品のことによると空の部分集合で反応するかもしれません。 calloutサーバ応答は首尾よく交渉された補助のメッセージ部分の部分集合を定義します。
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
Negotiation Offer(いいえ)メッセージを受け取るとき、calloutサーバはAux-部品パラメタに記載されたどんな非補足編も無視しなければなりません。 時はNegotiation Response(NR)メッセージを送るcalloutサーバです。
Rousskov & Stecher Standards Track [Page 8] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[8ページ]。
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.
交渉申し出で明らかに記載されなかった少しのアプリケーションメッセージ部分も選択してはいけません。 最後の規則の違反の場合には、作品プロセッサはトランザクションを終えなければなりません。
An OPES processor MUST send each negotiated auxiliary part to the callout server, unless the part is absent.
部分が欠けていない場合、作品プロセッサはそれぞれの交渉された補足編をcalloutサーバに送らなければなりません。
Example:
Aux-Parts: (request-header,request-body)
例: 補助の部分: (要求ヘッダー、要求本体)
Figure 3
図3
3.2.4. Pause-At-Body
3.2.4. ボディーに止まってください。
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.
calloutサーバは、オリジナルのデータフローが始まる前に原出願メッセージボディー送信におけるくぎりを要求するのにボディーのPauseパラメタを使用するかもしれません。 パラメタの値はタイプ「オフセット」のものです。 パラメタは送付者が一時見るのに関心がない非補助のアプリケーションメッセージボディー接尾語の始まりを指定します。
[headers][ body prefix | body suffix ][trailer] <-- ? --><-- offset --><-- ? ----------------> <-- equiv. DWP offset ->
[ヘッダー][ボディー接頭語| ボディー接尾語][トレーラ]<----><(オフセット)><--?----------------><--equiv。 DWPは->を相殺します。
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.
作品プロセッサがボディーのPauseパラメタを受け取るとき、それはまるで対応するorg-オフセットでWant Data Paused(DWP)メッセージを受け取ったかのように反応しなければなりません。 後者のオフセットがボディーのPauseオフセットと異なって、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.
例えば、ボディーのPause値がゼロであるなら、応答身体の部分がHTTP応答プロフィールにある状態で最初のData Use Mine(DUM)メッセージを送るすぐ前に作品プロセッサはPaused My Data(DPM)メッセージを送るはずです。 ボディーのPause値が300であるなら、そのアプリケーションメッセージ部分に300OCTETsを伝えた後に、作品プロセッサはDPMメッセージを送るはずです。
Example:
Pause-At-Body: 0
例: ボディーに止まってください: 0
Figure 5
図5
Rousskov & Stecher Standards Track [Page 9] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[9ページ]。
3.2.5. Stop-Receiving-Body
3.2.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サーバは、オリジナルのデータフローが始まる前にWant Stop Receiving Data(DWSR)メッセージの振舞いを含意するのにStop受信ボディーパラメタを使用するかもしれません。 パラメタの値はタイプ「オフセット」のものです。 パラメタはオリジナルの、そして、非補助のメッセージ身体の部分(要求プロフィールの要求本体と応答プロフィールの応答本体)にオフセットを指定します。
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.
Want Stop Receiving Data(DWSR)メッセージが送られるプロフィールのすべてのトランザクションのためのメッセージ本体に固定オフセットがあれば、calloutサービスは交渉応答と共にStop受信ボディーパラメタを送るかもしれません。 まるで対応するオフセットでDWSRメッセージを受け取ったかのように作品プロセッサは反応しなければなりません。 後者のオフセットがStop受信ボディーオフセットと異なって、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.
例えば、Stop受信ボディー値がHTTP応答プロフィールのゼロであるなら、作品プロセッサは応答ヘッダメッセージ部分を送る直後応答身体のメッセージ部分から始まる前の結果コード206があるApplication Message End(AME)メッセージを送るはずです。
Example:
Stop-Receiving-Body: 0
例: ボディーを受ける停止: 0
Figure 6
図6
3.2.6. Preservation-Interest-Body
3.2.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関心ボディーパラメタを使用できます。 パラメタの値は、タイプ「サイズ」があって、(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.
Data Preservation Interest(DPI)メッセージが送られるアプリケーションメッセージ本文の固定サイズ接頭語があれば、calloutサービスは交渉応答と共にPreservation関心ボディーパラメタを送るかもしれません。 まるでPreservation関心ボディーパラメタの値と等しいorg-オフセットゼロとorg-サイズでDPIメッセージを受け取るかのように作品プロセッサは反応しなければなりません。
Rousskov & Stecher Standards Track [Page 10] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[10ページ]。
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.
例えば、Preservation関心ボディー値がHTTP応答プロフィールのゼロであるなら、calloutサーバは応答身体の部分へのどんなData Use Yours(DUY)メッセージも送ってはいけません。 作品プロセッサは、データを保存するという決定をする前にさえデータ保存の振舞いを最適化するのにこの情報を使用するかもしれません。
Example:
Preservation-Interest-Body: 0
例: 保存関心本体: 0
Figure 7
図7
3.2.7. Content-Encodings
3.2.7. 内容-Encodings
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.
calloutサーバは、内容encodingsにおける好みを示すためにContent-Encodingsリストを送るかもしれません。 最初に記載されたEncodingsは他のencodingsより好まれます。 アプリケーションメッセージをcalloutサーバに送るとき、作品プロセッサはどんな満足しているコード化も使用するかもしれません。
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.
都合のよい内容encodingsのリストは他のencodingsのサポートの不足を含意しません。 実際の満足しているコード化がサービスの好みに合っているだけではないので、作品プロセッサはサービスを迂回させてはいけません。
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;
内容をコード化しています: 原子を広げています。 満足しているコーディング: 内容をコード化していることのリストを広げています。
Example:
Content-Encodings: (gzip)
例: 満足しているEncodings: (gzip)
Figure 8
エイト環
The semantics of content-coding is defined in section 3.5 of [RFC2616].
内容をコード化していることの意味論は[RFC2616]のセクション3.5で定義されます。
Rousskov & Stecher Standards Track [Page 11] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[11ページ]。
3.2.8. Profile Negotiation Example
3.2.8. プロフィール交渉の例
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
;
例: P: (「54、: http://www.iana.org/assignments/opes/ocp/http/response 、」 補助の部分: (要求ヘッダー、要求本体)、)、SG: 5 ; S: NR、「54、: 」 補助の部分: (要求ヘッダー)がボディーでポーズする http://www.iana.org/assignments/opes/ocp/http/response : 30保存関心本体: 0内容-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.
この例は既に創設されたサービスグループ(イド5)のために作品プロセッサによってされた交渉申し出を示しています。 calloutサーバは適切な交渉応答を送ります。
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.
作品プロセッサはHTTP応答メッセージのために1つのプロフィールの特徴を提供します。 標準のメッセージ部分以外に、作品プロセッサは補助のメッセージ部分としてオリジナルの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.
作品プロセッサは以下のメッセージ部分を高々送ります、指定された順序で、サービスグループ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関心ボディーパラメタを通してどんなDUYメッセージも送らないのをサイズゼロで示します。 したがって、作品プロセッサはこのプロフィールのどんなトランザクションのための保存も全く保存しないかもしれません。
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の値をボディーのPauseに送ることによって、calloutサーバはデータくぎりを要求します。 応答身体の部分の少なくとも30OCTETsを送る直後作品プロセッサはPaused My Data(DPM)メッセージを送ります。 その後、作品プロセッサはcalloutサービスからWant More Data(DWM)メッセージを待ちます。
Rousskov & Stecher Standards Track [Page 12] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[12ページ]。
3.3. Application Message Start Message
3.3. アプリケーションメッセージ開始メッセージ
A new named parameter for Application Message Start (AMS) messages is introduced.
Application Message Start(AMS)メッセージのための新しい命名されたパラメタは紹介されます。
AM-EL: size
AM高架鉄道: サイズ
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.
AMSメッセージを送るときHTTPメッセージ実体([RFC2616]でセクション7.2.2「実体の長さ」を見る)の正確な長さを知っているOCPエージェント、SHOULDは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).
HTTPメッセージを構成するとき、AM-ELパラメタSHOULDを受ける作品プロセッサはContent-長さのHTTP実体ヘッダーでパラメタの値を使用します、Content-長さのHTTP実体ヘッダーが与えられたアプリケーションメッセージのためにHTTPによって許容されているなら(セクション3.8.1を見てください)。
3.4. DUM Message
3.4. DUMメッセージ
A new named parameter for Data Use Mine (DUM) messages is introduced.
Data Use Mine(DUM)メッセージのための新しい命名されたパラメタは紹介されます。
AM-Part: am-part
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部分パラメタを送らなければなりません。 AM部分パラメタ価値がシングルである、午前、-離れてください、トークン。 構文で含意されるように、DUMメッセージはただ一つのアプリケーションメッセージ部分に関するデータを含むことができるだけです。 同じAM部分パラメタで1つのメッセージ部分をいろいろなDUMメッセージに断片化できます。
Rousskov & Stecher Standards Track [Page 13] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[13ページ]。
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応答メッセージを含む3つのDUMメッセージを示しています。 2つのDUMメッセージの中で応答身体の部分を断片化して、送ります。
Example:
P: DUM 88 1 0
Kept: 0
AM-Part: response-header
例: P: DUM88 1 0は保たれました: 午前0時部分: 応答ヘッダ
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 51
64: HTTP/1.1 200はコンテントタイプを承認します: html Contentテキスト/長さ: 51
;
P: DUM 88 1 64
Kept: 64
AM-Part: response-body
; P: 64が保ったDUM88 1: 64 AM部分: 応答本体
19:<html><body>This is
;
P: DUM 88 1 83
Kept: 83
AM-Part: response-body
19: <html><ボディー>Thisはそうです。 P: 83が保ったDUM88 1: 83 AM部分: 応答本体
32: a simple message.</body></html>
;
32: a簡単なメッセージ</ボディー></html>。
Figure 12
図12
3.5. Selective Adaptation
3.5. 選択している適合
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メッセージに適用されます。 その範囲は1xxの(情報)の応答や、ポストや、CONNECTや、OPTIONS要求などのHTTPメッセージを含んでいます、拡大ステータスコードによる応答と拡大メソッドがある要求と同様に。 別の方法でするために明確に構成されない場合、作品プロセッサはcalloutサーバで適合へのすべてのHTTPメッセージを転送しなければなりません。 calloutサーバとの作品迂回指示、構成された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(続けている)応答などの「コントロール」メッセージを適合させるのを試みるのが役に立たなく思えているかもしれない間、そのようなメッセージをスキップするのはデフォルトで重大なセキュリティー・フローと相互運用性問題を引き起こすかもしれません。例えば、機密の会社の情報はaを通してリレーされるかもしれません。
Rousskov & Stecher Standards Track [Page 14] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[14ページ]。
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.
慎重に作られた100Continue応答。 または、作品プロセッサがそれらを扱うべきであるcalloutサービスにこれらのメッセージを転送しないなら、悪意があるCONNECT要求は登録されないかもしれません。
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.
故意に、作品プロセッサ実装は、HTTPメッセージは適合させる価値がないと一方的に決めることができません。 それは、決定をするようにcalloutサーバ意見、構成設定、または別の外部の情報を必要とします。
3.6. Hop-by-hop Headers
3.6. ホップごとのヘッダー
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は、ホップごとの数個のヘッダー(例えば、Connection)を定義して、拡張ヘッダーがホップごとのもの(Connectionヘッダーメカニズムを通した)として指定されるのを許容します。 環境と構成によって、作品プロセッサは、ホップごとのヘッダーをcalloutサーバに送って、次のアプリケーションホップにホップごとのcalloutサーバによって返された、HTTPメッセージを築き上げたヘッダーを使用するかもしれません。 しかしながら、ヘッダーをコード化しながら、要件のためのセクション3.7がTransferに特定であることを見てください。
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.
例えば、伐採か統計取立業務が、ホップごとの先の出願ホップによって作品プロセッサに送られたヘッダー、そして/または、ホップごとのヘッダーが作品プロセッサによって次のアプリケーションホップに送られるのを見たがっているかもしれません。 別のサービスは実際にホップごとのヘッダーを取り除いて、加えるHTTP論理を扱うかもしれません。 多くのサービスがホップごとのヘッダーを無視するでしょう。 区別しているこれらがケースを使用するので、この仕様はメカニズムを定義しません。
3.7. Transfer Encodings
3.7. 転送Encodings
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メッセージは転送encodings、ホップごとにHTTPの特徴をコード化する使用するかもしれません。 HTTP転送encodingsを使用する適合は明らかに交渉されなければなりません。 この仕様はそのような交渉を記録しません。 明白な転送をコード化する交渉がないとき、OCPエージェントは転送でコード化されたアプリケーションメッセージ本文を送ってはいけません。
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.
OCP範囲に入る前に非公式に、HTTPメッセージ本体からエージェントかその環境がすべてがencodingsを移すのを確実にするために持っている上の規則手段を剥取ります。 アプリケーションメッセージ本文を送らなければならないなら、エージェントはOCPトランザクションを終えなければなりませんが、すべての転送encodingsを取り外すことができるというわけではありません。 これらの規則の違反は相互運用性問題を引き起こします。
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トランザクションを終えるかもしれません。
Rousskov & Stecher Standards Track [Page 15] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[15ページ]。
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.
ヘッダー部分をcalloutサービスに送る前に、転送encodingsを取り外す作品プロセッサはTransferをコード化しているヘッダーを取り除かなければなりません。 Transferをコード化しているヘッダーを受けるcalloutサーバは、原出願データがそれでもコード化された転送であると仮定するかもしれません(トランザクションを終えてください)。 作品プロセッサは正しいTransferをコード化しているヘッダーを次の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.
伐採と盗聴は許容できる転送encodingsを交渉する価値があるかもしれない例です。 calloutサーバがコード化を剥取ることができないかもしれない間、それはまだ「そのままで」全体のメッセージを登録していたがっているかもしれません。 多くの場合、しかしながら、calloutサーバは意味深長に未知の転送encodingsを扱うことができないでしょう。
3.8. HTTP Header Correctness
3.8. HTTPヘッダの正当性
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アプリケーションとコミュニケートするとき、作品プロセッサは言いなりになるプロセッサが、意図する仕様に記録されたすべての計算できるHTTPヘッダの正当性を確実にしなければなりません。 計算できるヘッダーはメッセージ本体に基づいて単独で値を計算できるヘッダーと定義されます。 例えば、Content-長さとContent-MD5ヘッダーの正当性はHTTP/1.1([RFC2616])へのコンプライアンスを要求するプロセッサによって確実にされなければなりません。
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".
非公式にデフォルトで、作品プロセッサは、calloutサーバによって返された適合しているアプリケーションメッセージからの対応するHTTPメッセージを築き上げるために計算できるHTTPヘッダを有効にして、再計算しなければならないか、加えなければならないか、または結局、取り除かなければなりません。特定の作品プロセッサが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.
作品プロセッサはcalloutサーバから次のcalloutサーバまで部分的に適合しているHTTPメッセージを転送するかもしれません、HTTPヘッダの正当性について確かめないで。 その結果、calloutサービスは、それが受けるHTTPヘッダがHTTP観点から正しいか、または最終的であると仮定できません。
The following subsections present guidelines for the recalculation of some HTTP headers.
以下の小区分はいくつかのHTTPヘッダの再計算のためのガイドラインを提示します。
3.8.1. Message Size Recalculation
3.8.1. メッセージサイズ再計算
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ヘッダメッセージ部分の中で送られるContent-長さのヘッダーを信じてはいけません。 HTTPメッセージヘッダーの適合なしでcalloutサービスでメッセージ長を変更できるでしょう。
Rousskov & Stecher Standards Track [Page 16] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[16ページ]。
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同輩に送る前に、[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メッセージの正当性を確実にすること以外に、配送潜在を最小にするのを含んでいて、良い作品プロセッサは性能を最適化するメッセージをセットアップします。 明確に、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サーバがAMSメッセージがあるAM-ELパラメタを送るなら、作品プロセッサSHOULDは、永続的なHTTP接続を保つことができるようにContent-長さのヘッダーを創造するのにこの値を使用します。 HTTP規則が転送でコード化されたメッセージで使用されるためにContent-長さのヘッダーを禁止することに注意してください。
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が転送コード化をchunkedしたなら、作品プロセッサSHOULD使用は転送コード化をchunkedしました。 どんなContent-長さのヘッダーもこの場合取り除かれなければならないことに注意してください。
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 メッセージサイズが先験的に知られていなくて、chunked転送コード化を使用できませんが、作品プロセッサが、永続的なHTTP接続に関する適合しているHTTPメッセージを転送する前にOCPトランザクションが終わるのを待つことができるなら、プロセッサSHOULDはContent-長さのヘッダーを計算して、加えます。
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 最終的に、すべての最適化が適切であるというわけではないなら、作品プロセッサSHOULDはすぐに、HTTP接続を終えることによってメッセージ終わりを示している間、どんなContent-長さのヘッダーと前進の適合しているデータも削除します。
3.8.2. Content-MD5 Header
3.8.2. 内容-MD5ヘッダー
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.
デフォルトで、作品プロセッサは、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ヘッダーを生成してはいけません。 したがって、作品プロセッサが適合させられる実体に正式であると考えられる場合にだけ、再計算は可能です。 それを検出しない場合、不-正式の作品プロセッサはContent-MD5ヘッダーを取り除かなければなりません。HTTPメッセージは変更されませんでした。 この場合、それはメッセージにContent-MD5ヘッダーを置き去りにするかもしれません。 そのような検出がメッセージ潜在をかなり増強するとき、Content-MD5ヘッダーを削除するのは、より良いオプションであるかもしれません。
Rousskov & Stecher Standards Track [Page 17] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[17ページ]。
3.9. Examples
3.9. 例
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のホームページにアクセスしたがっていますが、アクセスはプロキシによって使用されたcalloutサーバで動くサービスを妨げる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.
作品プロセッサからのOCPメッセージがマークされる、「P:」 そして、OCPがサーバがマークされるcalloutから通信する、「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
例: P: Cs。 S: Cs。 P: SGC11、(「31、: ocp-test.example.com/url-フィルタ、」、)、。 P: (「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: t55 11。 P: AMS55AM高架鉄道: 0 ; P: DUM55 0は保たれました: 午前0時部分: 要求ヘッダー235: GET http://www.restricted.example.com/ HTTP/1.1Accept: */*、言語を受け入れます: de Acceptをコード化しています: gzip、User-エージェントに空気を抜かせてください: Mozilla/4.0、(コンパチブル、; Windows NT5.0) 以下を接待してください。 www.restricted.example.com Proxy-接続: 生きている生活費
;
P: AME 55;
S: AMS 55;
S: DUM 55 0
AM-Part: response-header
; P: AME55。 S: AMS55。 S: DUM55午前0時部分: 応答ヘッダ
Rousskov & Stecher Standards Track [Page 18] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[18ページ]。
76:HTTP/1.1 403 Forbidden
Content-Type: text/html
Proxy-Connection: close
76: HTTP/1.1 403の禁制のコンテントタイプ: html Proxyテキスト/接続: 閉鎖
;
S: DUM 55 0
AM-Part: response-body
; S: DUM55午前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><ボディー>は. このページ</ボディー></html>にアクセスします。 S: AME55。 P: Te55。 S: Te55。
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
例: P: Cs。 S: Cs。 P: (「54、: http://www.iana.org/assignments/opes/ocp/http/response 、」、)、。 S: NR、「54、: http://www.iana.org/assignments/opes/ocp/http/response 、」、。 P: SGC12(「44: ocp-test.example.com/は=アンと=DEに翻訳します」)。 P: t89 12。 P: AMS89AM高架鉄道: 86 ; P: DUM89午前0時部分: 応答ヘッダ
65:HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 86
65: HTTP/1.1 200はコンテントタイプを承認します: テキスト/明瞭なContent-長さ: 86
;
P: DUM 89 65
AM-Part: response-body
; P: DUM89 65AM部分: 応答本体
Rousskov & Stecher Standards Track [Page 19] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[19ページ]。
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:、法外な財産の石つぶてや矢弾の雨を受ける心では、より高貴です。 P: AME89。 S: AMS89AM高架鉄道: 78 ; P: Te89。 S: DUM89午前0時部分: 応答ヘッダ
65:HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 78
65: HTTP/1.1 200はコンテントタイプを承認します: テキスト/明瞭なContent-長さ: 78
;
S: DUM 89 63
AM-Part: response-body
; S: DUM89 63AM部分: 応答本体
80:Ob's edler im Gemuet, die Pfeil und Schleudern
des wuetenden Geschicks erdulden
;
S: AME 89;
S: TE 89;
80: オビs edler不-Gemuet、Pfeil und Schleudern des wuetenden Geschicks erduldenで、死んでください。 S: AME89。 S: Te89。
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リソースの変更を示していて、データ保存最適化を示します。 calloutサーバは変わりのない応答ヘッダ部分を返送するDUYメッセージを使用しますが、AMSメッセージを送るとき変えられたHTMLリソースのサイズを知らないので、calloutサーバはAM-ELパラメタを省略します。 作品プロセッサはContent-長さのヘッダーを調整するのに原因となります。
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)
}
例: P: Cs。 S: Cs。 P: SGC10(「: ocp-test.example.com/が広告してフィルターにかける30」)。 P: (「54、: http://www.iana.org/assignments/opes/ocp/http/response 、」 補助の部分: (要求ヘッダー、要求本体)、「45、: http://www.iana.org/assignments/opes/ocp/MIME 、」、)、SG: 10 ; S: NR「54、: http://www.iana.org/assignments/opes/ocp/http/response 、」 補助の部分: (要求ヘッダー)内容-Encodings: (gzip)
Rousskov & Stecher Standards Track [Page 20] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[20ページ]。
SG: 10
;
P: TS 88 10;
P: AMS 88
AM-EL: 95
;
P: DUM 88 0
AM-Part: request-header
SG: 10 ; P: t88 10。 P: AMS88AM高架鉄道: 95 ; P: DUM88午前0時部分: 要求ヘッダー
65:GET /opes/adsample.html HTTP/1.1
Host: www.martin-stecher.de
65: opes/adsample.html HTTP/1.1が接待する/を手に入れてください: www.martin-stecher.de
;
P: DUM 88 65
; P: DUM88 65
Kept: 65 64
AM-Part: response-header
保たれる: 65 64AM部分: 応答ヘッダ
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 95
64: HTTP/1.1 200はコンテントタイプを承認します: html Contentテキスト/長さ: 95
;
P: DUM 88 129
Kept: 65 90
AM-Part: response-body
; P: DUM88 129は保たれました: 65 90AM部分: 応答本体
26:<html>
<body>
This is my
;
S: AMS 88;
P: DUM 88 155
Kept: 65 158
AM-Part: response-body
26、: <html><ボディー>Thisがそうである、私、。 S: AMS88。 P: DUM88 155は保たれました: 65 158 AM部分: 応答本体
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: 新しい広告: 88の<img src=「私の_ad.gif」幅=高さは31></ボディー></html>と等しいです。 S: 64秒間のDUY88 65: dpi88 129、2147483647。 P: AME88。 S: DUM88午前0時部分: 応答本体
Rousskov & Stecher Standards Track [Page 21] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[21ページ]。
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><ボディー>Thisは私の新しい広告です: </ボディー></html>。 S: dpi88 129、0。 P: Te88。 S: AME88。 S: Te88。
Figure 15
図15
4. Tracing
4. たどること
[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]は作品でアプリケーション不可知論者追跡施設を定義します。 この仕様への承諾は[RFC3897]へのコンプライアンスを必要とします。 HTTPを適合させるとき、HTTPメッセージヘッダーを使用することで跡のエントリーを供給します。 以下のHTTP拡張ヘッダーは、跡のエントリーを運ぶために定義されます。 [RFC2616]で定義されたBNF記法と要素を使用することで彼らの定義を与えます。
OPES-System = "OPES-System" ":" #trace-entry
OPES-Via = "OPES-Via" ":" #trace-entry
「作品システム=「作品システム」」:、」 #を通してを通して「跡エントリー、作品、-、等しさ、「作品、-、」、」、:、」 #跡エントリー
trace-entry = opes-agent-id *( ";" parameter )
opes-agent-id = absoluteURI
; 跡エントリーがopesエージェントイド*と等しい、(「」、パラメタ) 作品エージェントイド=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.
作品Systemは作品システムヘッダーに跡のエントリーを加えなければなりません。 を通して他の作品エージェントが使用しなければならない、作品、-、ヘッダーは彼らであるなら彼らの追跡エントリーを加えます。 すべての作品エージェントが彼らのエントリーを追加しなければなりません。 を通して作品システムが非公式に、追跡ヘッダーがゆったり過ごす唯一の必要な作品である、作品、-、任意の追跡詳細を明らかにします。 両方のヘッダーは跡のエントリー追加の注文を反映します。
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.
を通してを通して作品、-、ヘッダー、原出願メッセージ、Systemがエントリーを追加しなければならない作品で使用される、作品、-、ヘッダー を通してさもなければ、作品Systemがエントリーを追加するかもしれない、作品、-、ヘッダー。 を通して作品Systemが両方のヘッダーを使用しているなら、それ以外の同じ跡のエントリーがいくつかかすべての跡エントリーパラメタを省略するかもしれないと言い足さなければならない、作品、-、ヘッダー を通してを通して非公式である、中の作品Systemエントリー、作品、-、ヘッダー、区切って、分類するのに使用される、作品、-、作品System識別子に関する小修道院知識を持っていることのない異なった作品Systemsからのエントリー。
Rousskov & Stecher Standards Track [Page 22] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[22ページ]。
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メッセージは複数の1ヘッダーあたりの跡のエントリーを含んでもよいです。 作品エージェントSHOULDは長い跡を記録するのに複数の等しく命名された分野を使用するよりむしろただ一つのヘッダーフィールドを使用します。 複数の等しく命名された拡大ヘッダーフィールドを使用するのは、HTTPの観点から不法であり、何人かの作品気づかない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の作品サービスを実行しながら、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
例: HTTP/1.1 200OK日付: グリニッジ標準時2003年9月18日木曜日6時25分24秒の最終更新日: グリニッジ標準時2003年9月17日水曜日18時24分25秒の文書内容: 八重奏アプリケーション/ストリーム作品システム: を通して http://www.cdn.example.com/opes?session=ac79a749f56 、作品、-、: 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 。 モードは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.
上記の例では、作品プロセッサが跡のエントリーを含んでいないか、または作品システム跡のエントリーで跡のエントリーを取り替えました。 10のサービスのうちの3だけがたどられます。 残っているサービスが彼らのエントリーを含んでいなかったか、または作品システムかプロセッサは彼らのエントリーを取り除きました。 最後にたどられたサービスは「モード」パラメタを含んでいました。 跡のエントリーにおける様々な識別子は、たぶんメッセージの受取人に意味でないのを持ちますが、作品Systemソフトウェアによって解読されるかもしれません。
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.
作品実体はメッセージトレーラ(すなわち、chunkedコード化されたメッセージのChunked-ボディーの先の実体ヘッダー)に任意の追跡エントリーを置くかもしれません、トレーラ存在がHTTPプロトコルに違反しないなら。 どんな追跡エントリーが任意であるかに関する定義に関して[RFC3897]を見てください。 実体が置いてはいけない作品は、メッセージトレーラをエントリーをたどるのを必要としました。
Rousskov & Stecher Standards Track [Page 23] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[23ページ]。
5. Bypass
5. 迂回
An HTTP extension header is introduced to allow for OPES system bypass as defined in [RFC3897].
HTTP拡張ヘッダーは、[RFC3897]で定義されるように作品システム迂回を考慮するために紹介されます。
OPES-Bypass = "OPES-Bypass" ":" ( "*" | 1#bypass-entry )
bypass-entry = opes-agent-id
「作品迂回=「作品迂回」」:、」 (「*」| 1#迂回エントリー) 迂回エントリーはopesエージェントイドと等しいです。
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要求にこのヘッダーを追加できます。 アスタリスク「*」キャラクタは、すべての可能な作品エージェントの代理をするのに使用されます。
See [RFC3897] for what can be bypassed and for bypass requirements.
迂回できることと迂回要件に関して[RFC3897]を見てください。
6. IAB Considerations
6. IAB問題
OPES treatment of IETF Internet Architecture Board (IAB) considerations [RFC3238] are documented in "OPES Treatment of IAB Considerations" [RFC3914].
IETFインターネット・アーキテクチャ委員会(IAB)問題[RFC3238]の作品処理は「IAB問題の作品処理」[RFC3914]に記録されます。
7. Security Considerations
7. セキュリティ問題
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.
アプリケーションから独立しているセキュリティ問題はアプリケーション不可知論者作品仕様に記録されます。 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要求のRequest-URIを書き直すか、またはHTTPプロキシがそれに影響できる前にホップごとのHTTP Upgradeヘッダーを取り除くような適合を含んでいます。 どんな適合ならも、作品エージェントはHTTPクライアントもサーバ同意なしでそのような動作を実行してはいけません。
8. IANA Considerations
8. IANA問題
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と登録手順を用いる応答プロフィール機能(セクション3.2)がOCP Coreの「IANA問題」セクションに[RFC4037]について概説しました。 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
Rousskov & Stecher Standards Track [Page 24] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[24ページ]。
9. Compliance
9. 承諾
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.
作品メカニズムへのコンプライアンスは対応するアプリケーション不可知論者仕様に基づき定義されます。 まるでそれぞれのプロフィールが法人組織であるかのようにこれらのメカニズムのためのHTTPプロフィールはこれらの仕様からそれが輪郭を描くアプリケーション不可知論者仕様に対応する承諾定義を使用します。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[RFC3897] Barbir, A., "Open Pluggable Edge Services (OPES) Entities
and End Points Communication", RFC 3897, September 2004.
[RFC3897]Barbir、A.、「Pluggable縁のサービス(作品)実体とエンドポイントコミュニケーションを開いてください」、RFC3897、2004年9月。
[RFC4037] Rousskov, A., "Open Pluggable Edge Services (OPES) Callout
Protocol (OCP) Core", RFC 4037, March 2005.
[RFC4037] Rousskov、A.、「開いているPluggable縁のサービス(作品)Calloutプロトコル(OCP)コア」、RFC4037、2005年3月。
10.2. Informative References
10.2. 有益な参照
[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.、ペンノ、R.、チェン、R.、ホフマン、M.、およびH.Orman、「開いているPluggable縁のサービスのための構造(作品)」、RFC3835(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] べック、A.、ホフマン、M.、Orman、H.、ペンノ、R.、およびA.Terzis、「開いているPluggableのための要件はサービス(作品)Calloutプロトコルを斜めに進みます」、RFC3836、2004年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.、ホフマン、M.、およびH.Orman、「開いているPluggableのための軍事的脅威とリスクはサービス(作品)を斜めに進みます」、RFC3837、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.、バーガー、E.、チェン、R.、マクヘンリー、S.、Orman、H.、およびR.ペンノ、「開いているPluggable縁のサービス(作品)はケースと展開シナリオを使用します」、RFC3752、2004年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.、べック、A.、チェン、T.、H.Orman、および「開いているPluggable縁のサービス(作品)の方針、認可、および実施要件」、RFC3838(2004年8月)
[rules-p] Beck, A. and A. Rousskov, "P: Message Processing
Language", work in progress, October 2003.
[pを統治している] べック、A.、およびA.Rousskov、「P:」 「メッセージProcessing Language」は進歩、2003年10月に働いています。
Rousskov & Stecher Standards Track [Page 25] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[25ページ]。
[RFC3914] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services
(OPES) Treatment of IAB Considerations", RFC 3914, October
2004.
[RFC3914]BarbirとA.とA.Rousskov、「IAB問題の開いているPluggable縁のサービス(作品)処理」、RFC3914、2004年10月。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC
3238, January 2002.
[RFC3238] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、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.
作者は感謝してロバート・コリンズ(Syncretize)とラリーMasinter(Adobe)の貢献を承諾します。 ラリーMasinterはこのドキュメントの早めのレビューを提供しました。
Authors' Addresses
作者のアドレス
Alex Rousskov The Measurement Factory
アレックスRousskov測定工場
EMail: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/
メール: rousskov@measurement-factory.com ユリ: http://www.measurement-factory.com/
Martin Stecher CyberGuard Corporation Vattmannstr. 3 Paderborn 33100 DE
マーチンステッチャーCyberGuard社のVattmannstr。 3 パーテルボルン33100DE
EMail: martin.stecher@webwasher.com URI: http://www.webwasher.com/
メール: martin.stecher@webwasher.com ユリ: http://www.webwasher.com/
Rousskov & Stecher Standards Track [Page 26] RFC 4236 HTTP Adaptation with OPES November 2005
RousskovとステッチャーStandardsは2005年11月に作品とのRFC4236HTTP適合を追跡します[26ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rousskov & Stecher Standards Track [Page 27]
Rousskovとステッチャー標準化過程[27ページ]
一覧
スポンサーリンク
