Network Working Group J. Mogul
Request for Comments: 3229 Compaq WRL
Category: Standards Track B. Krishnamurthy
F. Douglis
AT&T
A. Feldmann
Univ. of Saarbruecken
Y. Goland
A. van Hoff
Marimba
D. Hellerstein
ERS/USDA
January 2002
Delta encoding in 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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1.
この文書は、デルタ符号化は、HTTP / 1.1と互換性拡張機能としてサポートすることができる方法について説明します。
Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."
多くのHTTP（ハイパーテキスト転送プロトコル）要求は、クライアントがすでにキャッシュエントリを持っているリソースを少し変更したインスタンスの検索を引き起こします。研究は、そのような変更、更新が頻繁であることが示されている、および改変は、典型的には、実体よりもはるかに小さいこと。それは、むしろ資源の全体の新しいインスタンスよりも、変化の最小限の記述を転送することができれば、このようなケースでは、HTTPは、ネットワーク帯域幅をより効率的に利用するだろう。これは、「デルタエンコーディング」と呼ばれています。
Table of Contents
目次
1 Introduction.................................................... 3
1.1 Related research and proposals........................... 4
2 Goals........................................................... 5
3 Terminology..................................................... 6
4 The HTTP message-generation sequence............................ 8
4.1 Relationship between deltas and ranges................... 11
5 Basic mechanisms................................................ 13
5.1 Background: an overview of HTTP cache validation......... 13
5.2 Requesting the transmission of deltas.................... 14
5.3 Choice of delta algorithm and format..................... 16
5.4 Identification of delta-encoded responses................ 16
5.5 Guaranteeing cache safety................................ 17
5.6 Transmission of delta-encoded responses.................. 18
5.7 Examples of requests combining Range and delta encoding.. 19
6 Encoding algorithms and formats................................. 22
7 Management of base instances.................................... 23
7.1 Multiple entity tags in the If-None-Match header......... 24
7.2 Hints for managing the client cache...................... 25
8 Deltas and intermediate caches.................................. 27
9 Digests for data integrity...................................... 28
10 Specification.................................................. 28
10.1 Protocol parameter specifications....................... 28
10.2 IANA Considerations..................................... 30
10.3 Basic requirements for delta-encoded responses.......... 30
10.4 Status code specifications.............................. 30
10.4.1 226 IM Used...................................... 31
10.5 Header specifications................................... 31
10.5.1 Delta-Base....................................... 31
10.5.2 IM............................................... 32
10.5.3 A-IM............................................. 33
10.6 Caching rules for 226 responses......................... 35
10.7 Rules for deltas in the presence of content-codings..... 36
10.7.1 Rules for generating deltas in the presence of
content-codings.................................. 37
10.7.2 Rules for applying deltas in the presence of
content-codings.................................. 37
10.7.3 Examples for using A-IM, IM, and content-codings. 38
10.8 New Cache-Control directives............................ 40
10.8.1 Retain directive................................. 40
10.8.2 IM directive..................................... 40
10.9 Use of compression with delta encoding.................. 41
10.10 Delta encoding and multipart/byteranges................ 42
11 Quantifying the protocol overhead.............................. 42
12 Security Considerations........................................ 44
13 Acknowledgements............................................... 44
14 Intellectual Property Rights................................... 44
15 References..................................................... 44
16 Authors' addresses............................................. 47
17 Full Copyright Statement....................................... 49
1 Introduction
1はじめに
The World Wide Web is a distributed system, and so often benefits from caching to reduce retrieval delays. Retrieval of a Web resource (such as a document, image, icon, or applet) over the Internet or other wide-area networks usually takes enough time that the delay is over the human threshold of perception. Often, that delay is measured in seconds. Caching can often eliminate or significantly reduce retrieval delays.
ワールド・ワイド・ウェブは、分散システムであり、そのため多くの場合、検索の遅延を減らすために、キャッシングから利益を得ます。インターネットまたは他の広域ネットワークを介して（例えば、文書、画像、アイコン、またはアプレットなど）のWebリソースの検索は、通常、遅延が知覚の人間の閾値を超える十分な時間を要します。多くの場合、その遅延は秒単位で測定されます。キャッシングは、多くの場合、排除または大幅に検索遅延を低減することができます。
Many Web resources change over time, so a practical caching approach must include a coherency mechanism, to avoid presenting stale information to the user. Originally, the Hypertext Transfer Protocol (HTTP) provided little support for caching, but under operational pressures, it quickly evolved to support a simple mechanism for maintaining cache coherency.
多くのWebリソースは、時間の経過とともに変化するので、実用的なキャッシングのアプローチは、ユーザーに古い情報を提示避けるために、一貫性のメカニズムを含める必要があります。もともとは、ハイパーテキスト転送プロトコル（HTTP）は、キャッシングのために少しのサポートを提供しますが、操作圧力の下で、それはすぐにキャッシュ・コヒーレンシを維持するための簡単なメカニズムをサポートするために進化しました。
In HTTP/1.0 [2], the server may supply a "last-modified" timestamp with a response. If a client stores this response in a cache entry, and then later wishes to re-use the response, it may transmit a request message with an "If-modified-since" field containing that timestamp; this is known as a conditional retrieval. Upon receiving a conditional request, the server may either reply with a full response, or, if the resource has not changed, it may send an abbreviated reply, indicating that the client's cache entry is still valid. HTTP/1.0 also includes a means for the server to indicate, via an "Expires" timestamp, that a response will be valid until that time; if so, a client may use a cached copy of the response until that time, without first validating it using a conditional retrieval.
HTTPに/ 1.0 [2]、サーバが応答して「最終変更」タイムスタンプを供給することができます。クライアント格納する場合、この応答キャッシュエントリで、かつ再利用応答したいその後、それは「修飾された場合-ので、」そのタイムスタンプを含むフィールドを有する要求メッセージを送信することができます。これは、条件付き検索として知られています。条件付きリクエストを受信すると、サーバーは、完全な応答で応答することができるのいずれか、または、リソースが変更されていない場合、それは、クライアントのキャッシュエントリがまだ有効であることを示す、簡略返信を送ることができます。 HTTP / 1.0は、応答がその時点まで有効となりますことを、タイムスタンプを、「有効期限」を介して、サーバが指示するための手段を含みます。その場合、クライアントは、最初の条件付き検索を使用してそれを検証せずに、それまで応答のキャッシュされたコピーを使用することができます。
HTTP/1.1 [10] adds many new features to improve cache coherency and performance. However, it preserves the all-or-none model for responses to conditional retrievals: either the server indicates that the resource value has not changed at all, or it must transmit the entire current value.
HTTP / 1.1 [10]はキャッシュの一貫性とパフォーマンスを向上させるために多くの新機能が追加されます。しかし、それは条件付きの回収のへの応答のための全か無かのモデルを維持する：いずれかのサーバーはリソース値がまったく変わっていないことを示し、またはそれは全体の現在の値を送信しなければなりません。
Common sense suggests (and traces confirm), however, that even when a Web resource does change, the new instance is often substantially similar to the old one. If the difference, or "delta", between the two instances could be sent to the client instead of the entire new instance, a client holding a cached copy of the old instance could apply the delta to construct the new version. In a world of finite bandwidth, the reduction in response size and delay could be significant.
Webリソースが変化しない場合でも、新しいインスタンスは、多くの場合、古いものと実質的に同じであること、しかし、常識を示唆している（とトレースが確認します）。 2つのインスタンス間の差、または「デルタ」は、全体ではなく、新しいインスタンスのクライアントに送信することができれば、古いインスタンスのキャッシュされたコピーを保持しているクライアントは、新しいバージョンを構築するためのデルタを適用することができます。有限帯域幅の世界では、応答の大きさと遅延の低減が重要である可能性があります。
One can think of deltas as a way to squeeze as much benefit as possible from client and proxy caches. Rather than treating an entire response as the "cache line", with deltas we can treat arbitrary pieces of a cached response as the replaceable unit, and avoid transferring pieces that have not changed.
一つは、クライアントとプロキシのキャッシュからできるだけ多くの利益を圧迫するための方法として、デルタと考えることができます。むしろデルタで、「キャッシュ・ライン」として全体の応答を処理するよりも、我々は、交換可能なユニットとしてキャッシュされたレスポンスの任意の部分を処理し、変更されていない部分を転送避けることができます。
This document proposes a set of compatible extensions to HTTP/1.1 that allow clients and servers to use delta encoding with minimal overhead.
このドキュメントでは、クライアントとサーバは、最小限のオーバーヘッドでデルタエンコーディングを使用できるようにするHTTP / 1.1と互換性の拡張セットを提案しています。
We assume that the reader is familiar with the HTTP/1.1 specification.
私たちは、読者がHTTP / 1.1仕様に精通していることを前提としています。
The idea of delta encoding to reduce communication or storage costs is not new. For example, the MPEG-1 video compression standard transmits occasional still-image frames, but most of the frames sent are encoded (to oversimplify) as changes from an adjacent frame. The SCCS and RCS [27] systems for software version control represent intermediate versions as deltas; SCCS starts with an original version and encodes subsequent ones with forward deltas, whereas RCS encodes previous versions as reverse deltas from their successors. Jacobson's technique for compressing IP and TCP headers over slow links [17] uses a clever, highly specialized form of delta encoding.
通信やストレージコストを削減するために、デルタエンコーディングの考え方は新しいものではありません。例えば、MPEG-1ビデオ圧縮標準は時折静止画フレームを送信するが、符号化され送信されたフレームの大部分は、隣接するフレームからの変化として（oversimplifyします）。ソフトウェアバージョン管理のためのSCCSおよびRCS [27]システムは、デルタなどの中間バージョンを表します。 SCCSは、元のバージョンから開始し、RCSはその後継からの逆デルタなどの以前のバージョンをコードするのに対し、前方デルタと後続のものをコードします。低速リンクでIPおよびTCPヘッダを圧縮するためのヤコブソン手法[17]は、デルタエンコーディングの巧妙な、専門性の高いフォームを使用しています。
In spite of this history, it appears to have taken several years before anyone thought of applying delta encoding to HTTP, perhaps because the development of HTTP caching has been somewhat haphazard. The first published suggestion for delta encoding appears to have been by Williams et al. in a paper about HTTP cache removal policies [30], but these authors did not elaborate on their design until later [29].
この歴史にもかかわらず、誰もがHTTPキャッシングの開発はやや行き当たりばったりされているかもしれないので、HTTPにデルタエンコーディングを適用するものと考える前に数年をとっているように見えます。デルタエンコーディングのための最初の公表の提案は、ウィリアムズらがされているように見えます。 HTTPキャッシュの削除ポリシー[30]、これらの作家に関する論文の後半まで、そのデザインに凝っていなかった[29]。
The WebExpress project [15] appears to be the first published description of an implementation of delta encoding for HTTP (which they call "differencing"). WebExpress is aimed specifically at wireless environments, and includes a number of orthogonal optimizations. Also, the WebExpress design does not propose changing the HTTP protocol itself, but rather uses a pair of interposed proxies to convert the HTTP message stream into an optimized form. The results reported for WebExpress differencing are impressive, but are limited to a few selected benchmarks.
WebExpressプロジェクト[15]は（彼らは「差分」と呼ぶ）HTTPのデルタエンコーディングの実装の最初の公表の記述であるように思われます。 WebExpressは、無線環境で特異的目的と、直交最適化の数を含んでいます。また、WebExpress設計は、HTTPプロトコル自体を変更する提案していない、むしろ最適化された形にHTTPメッセージストリームを変換するために介在プロキシのペアを使用します。 WebExpress差異のために報告された結果は印象的ですが、いくつかの選択されたベンチマークに限定されています。
Banga et al. [1] describe the use of optimistic deltas, in which a layer of interposed proxies on either end of a slow link collaborate to reduce latency. If the client-side proxy has a cached copy of a resource, the server-side proxy can simply send a delta (or a 304
バンガら。 [1]は、低速リンクの両端に介在プロキシの層は、待ち時間を低減するために協力した楽観的デルタの使用を記載しています。クライアント側のプロキシは、リソースのキャッシュされたコピーを持っている場合は、サーバー側のプロキシは、単にデルタ（または304を送信することができます
[Not Modified] response). If only the server-side proxy has a cached copy, it may optimistically send its (possibly stale) copy to the client-side proxy, followed (if necessary) by a delta once the server-side proxy has validated its own cache entry with the origin server. The use of optimistic deltas, unlike delta encoding, actually increases the number of bytes sent over the network, in an attempt to improve latency by anticipating a "Not Modified" response from the origin server. The optimistic delta paper, like the WebExpress paper, did not propose a change to the HTTP protocol itself, and reported results only for a small set of selected URLs.
）応答を[変更しません]。唯一のサーバ側プロキシがキャッシュされたコピーを持っている場合、それは楽観サーバー側のプロキシが持つ独自のキャッシュエントリを検証した後、デルタで（必要ならば）、その後、クライアント側のプロキシにその（おそらく古い）コピーを送信することができオリジンサーバ。楽観的なデルタの使用は、デルタエンコーディングとは異なり、実際にはオリジンサーバから「変更しない」応答を予想することで、待ち時間を改善する試みには、ネットワークを介して送信されたバイトの数が増加します。楽観デルタ紙は、WebExpress紙のように、HTTPプロトコル自体への変更を提案していなかった、とだけ選択したURLの小さなセットの結果を報告しました。
Mogul et al. [23] collected lengthy traces, at two different sites, of the full contents of HTTP messages, to quantify the potential benefits of delta-encoded responses. They showed that delta encoding can provide remarkable improvements in response-size and response-delay for an important subset of HTTP content types. They proposed a set of HTTP extensions, but without the level of detail required for a specification. Douglis et al. [8] used the same sets of full-content traces to quantify the rate at which resources change in the Web.
モーグルら。 [23]デルタエンコードされた応答の潜在的な利点を定量化するために、HTTPメッセージの完全な内容の2つの異なるサイト、で、長いトレースを収集しました。彼らは、デルタエンコーディングがHTTPコンテンツタイプの重要なサブセットに対して応答サイズ及び応答遅れに著しい改善をもたらすことができることを示しました。彼らは、HTTPの拡張セットを提案しますが、仕様に必要な詳細レベルなし。 Douglisら。 [8]リソースがウェブに変化する速度を定量化するために、フルコンテンツトレースの同じセットを使用します。
The HTTP Distribution and Replication Protocol (DRP), proposed to W3C by Marimba, Netscape, Sun, Novell, and At Home, aims to provide a collection of new features for HTTP, to support "the efficient replication of data over HTTP" [13]. One aspect of the DRP proposal is the use of "differential downloading," which is essentially a form of delta encoding. The original DRP proposal uses a different approach than is described here, but a forthcoming revision of DRP will be revised to conform to the proposal in this document.
HTTPの配布とレプリケーションプロトコル（DRP）は13 [、マリンバ、ネットスケープ、日、ノベルによってW3Cに提案し、自宅で、「HTTPを介してデータの効率的な複製」をサポートするために、HTTPのための新機能のコレクションを提供することを目的と]。 DRP提案の一つの態様は、本質的に、デルタ符号化の一形態である「差分ダウンロード」の使用です。元DRP提案はここに記述されているとは異なるアプローチを使用していますが、DRPの今後の改正は、この文書の提案に合わせて修正されます。
Tridgell and Mackerras [28] describe the "rsync" algorithm, which accomplishes something similar to delta encoding. In rsync, the client breaks a cache entry into a series of fixed-sized blocks, computes a digest value for each block, and sends the series of digest values to the server as part of its request. The origin server does the same block-based computation, and returns only those blocks whose digest values differ. We believe that it might be possible to support rsync using the "instance manipulation" framework described later in this document, but this has not been worked out in any detail.
Tridgellとマッケラス[28]差分エンコーディングと同様なものを達成「rsyncの」アルゴリズムを記述する。 rsyncのでは、クライアントは、固定サイズの一連のブロックにキャッシュエントリを壊し、各ブロックのダイジェスト値を計算し、その要求の一部としてサーバーにダイジェスト値の系列を送信します。オリジンサーバは、同じブロック・ベースの計算を行い、そしてそのダイジェスト値が異なるブロックのみを返します。私たちは、このドキュメントで後述する「インスタンス操作」フレームワークを使ってrsyncをサポートすることは可能かもしれないと信じているが、これは詳細には働いていません。
2 Goals
2つの目標
The goals of this proposal are:
この提案の目的は次のとおりです。
1. Reduce the mean size of HTTP responses, thereby improving latency and network utilization.
1.これにより、遅延とネットワークの使用率を改善し、HTTP応答の平均サイズを減らします。
The goals do not include:
目標が含まれていません。
- Reducing the number of HTTP requests sent to an origin server.
- オリジンサーバに送信されたHTTPリクエストの数を減らします。
- Reducing the size of every HTTP message.
- すべてのHTTPメッセージのサイズを小さくします。
- Increasing the cache-hit ratio of HTTP caches.
- HTTPキャッシュのキャッシュヒット率を上げます。
- Allowing excessively simplistic implementations of delta encoding.
- デルタ符号化の過度に単純な実装を可能にします。
- Delta encoding of request messages, or of responses to methods other than GET.
- 要求メッセージのデルタエンコーディング、またはGET以外の方法への応答の。
Nothing in this specification specifically precludes the use of a delta encoding for the body of a PUT request. However, no mechanism currently exists for the client to discover if the server can interpret such messages, and so we do not attempt to specify how they might be used.
本明細書中の何も、具体的にPUTリクエストのボディのデルタ符号化の使用を排除しません。しかし、メカニズムは現在サーバーは、このようなメッセージを解釈できるかどうかを発見するために、クライアントのために存在しない、と私たちは、彼らが使用されるかもしれない方法を指定しようとしないでください。
3 Terminology
3用語
HTTP/1.1 [10] defines the following terms:
HTTP / 1.1 [10]以下の用語を定義しています。
resource A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways.
セクション3.2で定義されるように、URIによって識別することができるネットワーク・データ・オブジェクトまたはサービスリソース。リソースが複数の表現に利用可能である（例えば、複数の言語、データフォーマット、サイズ、解像度）、または他の方法で変えることができます。
entity The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in section 7.
エンティティ要求または応答のペイロードとして転送される情報。セクション7で説明したように、エンティティは、エンティティ - ヘッダフィールド及びエンティティ - 本体の形のコンテンツの形でメタ情報から構成されています。
variant A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `variant.' Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.
バリアントリソースは、1つ、または任意の所与の瞬間に、それに関連付けられた複数の、表現（単数または複数）を有していてもよいです。これらの表現のそれぞれを `バリアントと呼ばれています。」用語 `バリアント」の使用は、必ずしもリソースが内容交渉の対象であることを意味するものではありません。
The dictionary definition for "entity" is "something that has separate and distinct existence and objective or conceptual reality" [21]. Unfortunately, the definition for "entity" in HTTP/1.1 is similar to that used in MIME [12], based on a false analogy between MIME and HTTP.
「実体」の辞書の定義は、「独立した別個の存在と客観的または概念的な現実を持っているもの」[21]です。残念ながら、HTTP / 1.1の「エンティティ」の定義はMIMEとHTTPとの間の誤った類推に基づいて、MIME [12]で用いたものと同様です。
In MIME, electronic mail messages do have distinct and separate existences. MIME defines "entity" as something that "refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity."
MIMEでは、電子メールメッセージは異なる別個な存在を持っています。 MIMEは、何かのように、「実体」を定義する「MIME定義ヘッダフィールドおよびメッセージまたはマルチパートエンティティの本体内の部品のいずれかの内容を具体的に指します。」
In HTTP, however, a response message to a GET does not have a distinct and separate existence. Rather, it reflects the current state of a resource (or a variant, subject to a set of constraints). The HTTP/1.1 specification has no term to describe "the value that would be returned in response to a GET request at the current time for the selected variant of the specified resource." This leads to awkward wordings in the HTTP/1.1 specification in places where this concept is necessary.
HTTPでは、しかし、GETに応答メッセージは異なる別個の存在を持っていません。むしろ、リソース（またはその変異体、制約のセットを受ける）の現在の状態を反映しています。 HTTP / 1.1仕様では、説明するためない用語がありません「指定されたリソースの選択された変異体のための現時点でGET要求に応答して返される値。」これは、この概念が必要な場所でのHTTP / 1.1仕様では厄介な文言につながります。
To express this concept, we define a new term, for use in this document:
この概念を表現するために、我々は、このドキュメントで使用するために、新しい用語を定義します。
instance The entity that would be returned in a status-200 response to a GET request, at the current time, for the selected variant of the specified resource, with the application of zero or more content-codings, but without the application of any instance manipulations (see below) or transfer-codings.
インスタンスが、すべてのインスタンスを適用せず、ゼロ個以上の内容コーディングを適用して、指定されたリソースの選択した変異体のために、現在の時点で、GET要求に対するステータス-200応答で返されることになるエンティティ操作（下記参照）、または転送コーディング。
It is convenient to think of an entity tag, in HTTP/1.1, as being associated with an instance, rather than an entity. That is, for a given resource, two different response messages might include the same entity tag, but two different instances of the resource should never be associated with the same (strong) entity tag.
むしろ実体よりも、インスタンスに関連するものとして、HTTP / 1.1で、エンティティタグを考えると便利です。つまり、与えられたリソースのために、二つの異なる応答メッセージは、同じエンティティタグが含まれる場合がありますが、リソースの2つの異なるインスタンスが同じ（強い）エンティティタグに関連付けられてはいけません。
We will informally use the term "delta," in this document, to mean an HTTP response encoded as the difference between two instances.
私たちは、非公式に2つのインスタンス間の差としてエンコードされたHTTPレスポンスを意味するように、このドキュメントの「デルタ」という用語を使用します。
More formally, delta encodings are members of a potentially larger class of transformations on instances, leading to this new term:
より正式に、デルタエンコーディングは、この新しい用語につながるインスタンス上の変換の潜在的に大きなクラスのメンバーは、以下のとおりです。
instance manipulation An operation on one or more instances which may result in an instance being conveyed from server to client in parts, or in more than one response message. For example, a range selection or a delta encoding. Instance manipulations are end-to-end, and often involve the use of a cache at the client.
部品にサーバからクライアントに搬送される場合に、または複数の応答メッセージをもたらすことができる1つまたは複数のインスタンスでインスタンス操作オペレーション。例えば、範囲選択またはデルタエンコード。インスタンス操作はエンド・ツー・エンドであり、多くの場合、クライアントでのキャッシュの使用を含みます。
For reasons that will become clear later on, it is convenient to think about subrange selection as a form of instance manipulation. In some contexts, compression might also be treated as an instance manipulation, rather than as a content-coding or transfer-coding.
後に明らかとなる理由から、インスタンス操作の形式として、サブレンジの選択を考えると便利です。いくつかの状況では、圧縮はまた、インスタンス操作としてではなく、コンテンツコーディングまたは転送コーディングとして扱われるかもしれません。
4 The HTTP message-generation sequence
4のHTTPメッセージ生成シーケンス
HTTP/1.1 supports a number of different transformations on the body of a value:
HTTP / 1.1は、値の身体上の異なる変換の数をサポートしています。
Content-coding According to the specification, "Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only decoded by the recipient." Content-codings are normally end-to-end transformations; i.e., once applied at the sender, they are not removed except at the ultimate recipient. An intermediate server may apply a content-coding, in appropriate circumstances.
コンテンツ符号化値」、仕様によれば、コンテンツ符号化された又はエンティティに適用することができる符号変換を示す。コンテンツコーディングは、主に文書は、その根底にあるのアイデンティティを失うことなく、圧縮またはその他の有用形質転換されることを可能にするために使用されメディアタイプと情報の損失なし。しばしば、エンティティは、符号化された形式で格納され、直接送信され、受信者だけによって復号されます。」内容コーディングは、通常、エンド・ツー・エンドの変換です。すなわち、一度彼らは最終的な受信者以外では削除されません、送信者に適用されます。中間サーバは、適切な状況下で、コンテンツの符号化を適用することができます。
Transfer-coding According to the specification, "Transfer coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer coding is a property of the message, not of the original entity." Transfer-codings are explicitly hop-by-hop transformations (although, as an optimization, an intermediate proxy may store the transfer-coded version of a message if this behavior is not inconsistent with its externally visible function.)
転送符号化仕様によれば、「転送コーディング値がされた符号化変換を示すために使用される、とすることができる、または確実にするために、エンティティボディに適用する必要があるかもしれない 『ネットワークを介して安全な輸送』。この転送符号化がない元のエンティティから、メッセージのプロパティであることを符号化コンテンツとは異なります。」転送コーディングされ、明示的にホップバイホップ変換（最適化として、メッセージの転送、符号化されたバージョンを格納することができる中間プロキシは、この動作が外部から見える機能と矛盾しない場合には、ありません。）
Ranges An HTTP client, using the Range header, may request that the server return one or more subranges of the instance, rather than the entire instance value. HTTP/1.1 only supports byte-ranges, although there is some possibility that future extensions will allow for other kinds of range-specifiers (such as chapters of a document).
HTTPクライアントは範囲、Rangeヘッダを使用して、サーバではなくインスタンス全体の値よりも、インスタンスの一つ以上の部分範囲を返すことを要求してもよいです。将来の拡張は、（例えば、文書の章のような）範囲指定子他の種類のを可能にするいくつかの可能性があるものの、HTTP / 1.1のみ、バイト範囲をサポートします。
A client signals its willingness to receive a content-coding by sending an "Accept-Encoding" header, listing the set of content-codings that it understands. It may optionally include information about which content-codings it prefers. If a server uses any non-identity content-coding(s), it includes a "Content-Encoding" header field in the response, listing these content-codings in their order of application.
クライアントは、それが理解する内容コーディングのセットをリスト、「同意エンコード」ヘッダを送信することにより、コンテンツの符号化を受信する意思を伝えます。それは、必要に応じて、それが好む内容コーディングについての情報を含むことができます。サーバが非同一内容コーディング（複数可）を使用している場合、それはアプリケーションの彼らのためにこれらの内容コーディングをリストアップ、レスポンス中の「Content-Encoding」ヘッダフィールドが含まれます。
RFC 2068 [9] did not include an analogous mechanism for negotiating the use of transfer-codings, although it does include an analogous "Transfer-Encoding" header for marking the response. A new "TE" header has since been added to HTTP/1.1 [10], analogous to the "Accept-Encoding" header.
それは応答をマーキングするための類似した「転送エンコーディング」ヘッダを含まないものの、RFC 2068 [9]、転送コーディングの使用を交渉するための類似の機構を含んでいませんでした。新しい「TE」ヘッダは、以降、「受け入れエンコード」をヘッダに類似し、HTTP / 1.1 [10]に追加されています。
In this document, we add new, optional message headers to support the use of instance manipulations. A client signals its willingness to receive an instance-manipulation by sending an "A-IM" header (short for "Accept-Instance-Manipulation", which is far too long to spell out), analogous to the "Accept-Encoding" header. Similarly, a server lists the set of instance-manipulations it has applied using an "IM" header.
この文書では、我々は、インスタンス操作の使用をサポートするために、新しい、オプションのメッセージヘッダを追加します。クライアントは、「同意エンコード」をヘッダに類似し、（スペルアウトするにはあまりにも長いです「のAccept-インスタンス・マニピュレーション」の略）「A-IM」ヘッダを送信することにより、インスタンスの操作を受信する意思を知らせます。同様に、サーバは、それが「IM」ヘッダを使用して適用しているインスタンス操作のセットを一覧表示します。
One must understand the relationship between these transformations in order to see how delta encoding applies to HTTP responses.
一つは、デルタエンコーディングは、HTTPレスポンスに適用されるかを確認するために、これらの変換の間の関係を理解する必要があります。
Conceptually, the various transformations are applied in the following sequence:
概念的には、様々な変換は以下の順序で適用されます。
1. Upon receiving a GET request, the server uses the URI in the request to identify the requested resource.
1. GET要求を受信すると、サーバは、要求されたリソースを識別するために、要求にURIを使用します。
2. Optionally, it uses information from the request (and perhaps additional information) to select a variant of that resource.
2.必要に応じて、そのリソースの変異体を選択するために、要求（おそらく付加情報）からの情報を使用します。
3. At this point, the server may apply a non-identity content-coding to the instance, or one might have been inherent in its generation. This also results in a Content-Encoding header.
3.この時点で、サーバーは、インスタンスに非同一の内容コーディングを適用することができる、または1つは、その世代に内在している可能性があります。これは、コンテンツ-Encodingヘッダーになります。
4. The result of the first three steps, at the time when the request is processed, is an instance. The instance includes a body (possibly empty) and possibly some instance headers. The entity tag, if any, is assigned at this point. That is, an entity tag is associated with an instance, NOT an entity.
4.最初の3つのステップの結果は、要求が処理される時には、インスタンスです。インスタンスは、本体（空）とおそらくいくつかのインスタンスヘッダを含みます。エンティティタグは、もしあれば、この時点で割り当てられています。これは、エンティティタグは、例えば、NOTエンティティに関連付けられている、です。
5. The server may then apply an instance-manipulation. For example, if the request included a Range header, the server may optionally produce a range response, consisting of the original set of headers, a Content-Range header, and the appropriate range(s) from the (possibly encoded) body. Delta encodings are instance-manipulations, and are computed at this stage.
5.次に、サーバは、インスタンス操作を適用することができます。リクエストがRangeヘッダが含まれている場合、例えば、サーバは、必要に応じてヘッダーの元のセットは、Content-Rangeヘッダ、及び（おそらくエンコードされた）本体から適切な範囲（S）からなる範囲の応答を生成することができます。デルタエンコーディングは、インスタンスの操作であり、この段階で計算されます。
6. The result of the fifth step becomes the entity, consisting of entity headers and an entity body.
前記第五のステップの結果は、エンティティヘッダとエンティティボディから成る、エンティティなります。
7. The server may then apply a non-identity transfer-coding; on-the-fly compression could be done in this step. If so, a Transfer-Encoding header is added to the message.
7.サーバは、非同一の転送コーディングを適用してもよいです。オンザフライ圧縮が、この段階で行うことができます。その場合、転送符号化ヘッダがメッセージに付加されます。
8. The results of the seventh step is the message, consisting of a message body (the transfer-coded version of the entity body), the entity headers, and additional response and general headers.
8.第7の工程の結果は、メッセージ本体（エンティティボディの転送符号化されたバージョン）、エンティティヘッダ、および追加の応答と一般ヘッダーからなるメッセージです。
Note: Section 14.13 of the HTTP/1.1 specification [10] says "The Content-Length entity-header field indicates the size of the entity-body." In other words, Content-Length measures the length of an entity, not of an instance or of a variant. For example, if the message is a delta encoding, Content-Length gives the length of the delta encoding, not the length of the current instance.
注：HTTP / 1.1仕様のセクション14.13 [10]「のContent-Lengthエンティティヘッダフィールドは、エンティティボディのサイズを示す。」と言います換言すれば、コンテンツ長がないインスタンスの、または変異体の、実体の長さを測定します。メッセージは、差分エンコーディングである場合、例えば、コンテンツの長さは、デルタ符号化、現在のインスタンスのない長さの長さを与えます。
Diagrammatically, the sequence is:
図式、シーケンスは次のとおりです。
datatype operation leading to next datatype
======== ==================================
resource
| choose acceptable variant, if needed
v
variant
| apply content-coding, if any
v
| compute/assign entity tag v instance | apply instance manipulation, if any v (delta encoding, range selection, etc.) entity-body | apply transfer-coding, if any v message-body
|コンピューティング/インスタンスvのエンティティタグを割り当てます| |、もしあればV（デルタ符号化、範囲選択、等）エンティティボディインスタンス操作を適用します任意のVメッセージ・ボディ場合、転送コーディングを適用
This formalization of the HTTP message generation sequence has not previously been described. However, it is clear that Range selection needs to be done after the entity tag has been assigned and after any content-coding has been applied, and before any transfer-coding is applied. Therefore, this formalization is fully consistent with previous practice and specification.
HTTPメッセージ生成シーケンスのこの定式化は、以前に記載されていませんでした。しかし、範囲選択がエンティティタグが割り当てられた後に任意のコンテンツコーディングが適用された後に行われる必要があることは明らかであり、かつ任意の転送コーディングが適用される前に。したがって、この定式化は、前の練習や仕様に完全に一致しています。
If both Ranges and delta encodings are forms of instance manipulation, which should be applied first? This depends on how the Range is being used.
範囲およびデルタエンコーディングの両方が最初に適用されるべきインスタンス操作の形式は、ある場合は？これは、範囲が使用されている方法によって異なります。
Ranges are used for two main purposes, at the discretion of the requesting client:
範囲が要求しているクライアントの裁量で、2つの主な目的のために使用されます。
1. to complete a partial response after a premature termination of a message transmission.
1.メッセージ送信の早期終了後に部分的応答を完了します。
In the first use of Range, it would have to be applied after any delta encoding, since the intended use is to recover an intact copy of the delta-encoded instance. In the second use of Range, it would have to be applied before any delta encoding, because otherwise the offsets specified in the Range request would be meaningless (the client generally cannot know how a server's delta encoding maps instance byte offsets to entity byte offsets).
使用目的は、デルタ符号化されたインスタンスの完全なコピーを回復することであるので、範囲の最初の使用時に、それは、任意のデルタ符号化の後に適用されなければなりません。範囲要求で指定されたそうオフセットは意味がないので、レンジの第二の使用では、それは、任意のデルタエンコーディングの前に適用されなければならない（クライアントは一般的に、サーバーのデルタエンコーディングがエンティティのバイトオフセットにインスタンスのバイトオフセットをマップする方法を知ることはできません） 。
Therefore, we need a mechanism to allow the client to specify the order in which two or more instance-manipulations should be applied. This is easily provided as part of the specification of the "A-IM" header (see section 10.5.3), where we require that the server apply instance-manipulations in the order that they are listed in the "A-IM" header. We also include a "range" literal in the set of registered instance-manipulations, to allow the client to specify (by its ordering with respect to other instance-manipulations) whether range selection is done before or after delta encoding.
したがって、我々は、クライアントが二つ以上のインスタンスの操作が適用されるべき順序を指定できるようにするメカニズムが必要です。これは簡単に、我々は、サーバーは、それらが「A-IM」ヘッダにリストされているために、インスタンス操作を適用することを必要とする「A-IM」ヘッダ（セクション10.5.3を参照）の仕様の一部として提供されます。我々はまた、クライアントは、範囲選択が差分エンコーディングの前または後に行われているかどうか（他のインスタンスの操作に対して、その順序によって）指定することを可能にする登録インスタンス操作のセットにおけるリテラル「範囲」を含みます。
We also need a mechanism for the server to indicate in which order two or more instance-manipulations have been applied; this is part of the specification of the "IM" header (see section 10.5.2), where we follow the same practice used for the "Content-Encoding" header: the "IM" header lists the instance-manipulations in the order that were applied (including, perhaps, the special "range" literal).
我々はまた、二つ以上のインスタンスの操作を発注したが、適用されている示すために、サーバのメカニズムが必要です。これは、「IM」ヘッダの仕様の一部であり、我々は「コンテンツ・エンコード」ヘッダーのために使用したのと同じ練習を従って、（セクション10.5.2を参照してください）：「IM」ヘッダが順番にそのインスタンスの操作を示しています（おそらく、特別な「範囲」リテラルを含む）を適用しました。
A similar issue arises when Ranges are combined with compression. If the client is using a Range to complete a partial response after a premature termination of a compressed message, then the Range would have to be applied after the compression. This is feasible in unmodified HTTP/1.1, because the compression can be done as a content-coding. However, if the client is using a Range to obtain selected sections of an instance, it would normally be able to specify offsets only in terms of the uncompressed variant. If the selected portion was large enough to warrant compression, the client could request a compressed transfer-coding, but this is a hop-by-hop transformation and is not the most efficient approach (especially if an HTTP/1.0 proxy is in the path).
範囲は圧縮と組み合わせた場合、同様の問題が発生します。クライアントが圧縮されたメッセージの早期終了後に部分的応答を完了するために、範囲を使用している場合は、その範囲は、圧縮後に適用されなければならないだろう。圧縮コンテンツ符号化として行うことができるので、これは、修飾されていないHTTP / 1.1で実現可能です。クライアントは、インスタンスの選択されたセクションを得るために、範囲を使用している場合は、正常にのみ、非圧縮バリアントの面でオフセットを指定することができるだろう。選択された部分が圧縮を保証するのに十分な大きさであった場合、クライアントは、圧縮された転送コーディングを要求することができるが、これはホップバイホップ変換され、HTTP / 1.0プロキシがパスである場合は特に（最も効率的なアプローチではありません）。
We can resolve this issue by supporting the use of compression as an instance-manipulation (as well as as a content-coding or transfer-coding), and by using the new mechanism that allows the client to specify that the compression instance-manipulation is done after the Range instance-manipulation.
私たちは、インスタンス操作として（だけでなく、コンテンツのコーディングまたは転送コーディングなど）圧縮の使用をサポートすることにより、クライアントが圧縮インスタンス操作であることを指定することを可能にする新しいメカニズムを使用してこの問題を解決することができますレンジインスタンス操作の後に行わ。
This also allows the client to control whether compression is done before or after delta encoding, since some simple differencing algorithms (such as the UNIX "diff" command) require post-compression of their output to yield the best results.
（そのようなUNIXコマンド「diff」のように）いくつかの単純な差分アルゴリズムは最良の結果を得るために、それらの出力の圧縮後を必要とするので、これはまた、クライアントがデルタエンコーディングの前または後に圧縮が行われているかどうかを制御することができます。
5 Basic mechanisms
5つの基本的なメカニズム
In this section, we explain the concepts behind delta encoding. This is not meant as a formal specification of the proposed extensions; see section 10 for that.
このセクションでは、デルタエンコーディングの背後にある概念を説明します。これは、提案された拡張の正式な仕様として意図されていません。そのためのセクション10を参照してください。
When a client has a response in its cache, and wishes to ensure that this cache entry is current, HTTP/1.1 allows the client to do a "conditional GET", using one of two forms of "cache validators." In the traditional form, available in both HTTP/1.0 and in HTTP/1.1, the client may use the "If-Modified-Since" request-header to present to the server the "Last-Modified" timestamp (if any) that the server provided with the response. If the server's timestamp for the resource has not changed, it may send a response with a status code of 304 (Not Modified), which does not transmit the body of the resource. If the timestamp has changed, the server would normally send a response with a status code of 200 (OK), which carries a complete copy of the resource, and a new Last-Modified timestamp.
クライアントがキャッシュ内に応答があり、このキャッシュエントリが最新のものであることを確認したい場合は、HTTP / 1.1は、クライアントが2つの形式のいずれかを使用して、「条件付きGET」を行うことを可能にする「キャッシュバリデータを。」 HTTP / 1.0の両方に及びHTTP / 1.1で利用可能な伝統的な形態では、クライアントは「変更した場合-ので」リクエストヘッダそのサーバに「最終変性」タイムスタンプ（もしあれば）を提示するために使用することができます応答を提供するサーバー。リソースに対するサーバーのタイムスタンプが変更されていない場合は、リソースの本体を送信しない304のステータスコード（変更不可）、との応答を送信することができます。タイムスタンプが変更された場合、サーバは通常、リソースの完全なコピーを運ぶ200のステータスコード（OK）、および新しい最後に変更されたタイムスタンプ付きの応答を送信します。
This timestamp-based approach is prone to error because of the lack of timestamp resolution: if a resource changes twice during one second, the change might not be detectable. Therefore, HTTP/1.1 also allows the server to provide an entity tag with a response. An entity tag is an opaque string, constructed by the server according to its own needs; the protocol specification imposes a bare minimum of requirements on entity tags. (In particular, a "strong" entity tag must change if the value of the resource changes.) In this case, the client may validate its cache entry by sending its conditional request using the "If-None-Match" request-header, presenting the entity tag associated with the cached response. (The protocol defines several other ways to transmit entity tags, such as the "If-Range" header, used for short-circuiting an otherwise necessary round trip.) If the presented entity tag matches the server's current tag for the resource, the server should send a 304 (Not Modified) response. Otherwise, the server should send a 200 (OK) response, along with a complete copy of the resource.
このタイムスタンプベースのアプローチがあるため、タイムスタンプの解像度の不足のエラーを起こしやすいです：リソースが1秒間に2回変更された場合、変更は検出できない場合があります。従って、HTTP / 1.1は、サーバが応答してエンティティタグを提供することを可能にします。エンティティタグは、独自のニーズに応じて、サーバによって構成され、不透明な文字列です。プロトコル仕様は、エンティティタグの要件の最低限を課します。 （具体的には、「強い」エンティティタグは、リソースの変更の場合、値を変更しなければならない。）この場合、クライアントは、「IF-なしマッチ」要求ヘッダを使用して条件付き要求を送信することによって、そのキャッシュエントリを検証することができます、キャッシュされた応答に関連するエンティティタグを提示します。 （プロトコルは、そうでなければ、必要なラウンドトリップを短絡するために使用される「IFレンジ」ヘッダなどエンティティタグを送信するには、いくつかの他の方法を定義する。）に提示エンティティタグは、サーバ、リソースのためのサーバの現在のタグと一致する場合304（未修正）応答を送信する必要があります。そうしないと、サーバーはリソースの完全なコピーとともに、200（OK）応答を送信する必要があります。
In the existing HTTP protocol (HTTP/1.0 or HTTP/1.1), a client sending a conditional request can expect either of two responses:
既存のHTTPプロトコル（HTTP / 1.0またはHTTP / 1.1）では、条件付きリクエストを送信するクライアントは、2つの応答のいずれかを期待することができます。
- status = 200 (OK), with a full copy of the resource, because the server's copy of the resource is presumably different from the client's cached copy.
- リソースの完全なコピーを持つ状態= 200（OK）、リソースのサーバーのコピーは、クライアントのキャッシュされたコピーから、おそらく異なるため。
- status = 304 (Not Modified), with no body, because the server's copy of the resource is presumably the same as the client's cached copy.
- ステータス= 304リソースのサーバのコピーはおそらく、クライアントのキャッシュされたコピーと同じであるため、本文なしで、（変更不可）。
Informally, one could think of these as "deltas" of 100% and 0% of the resource, respectively. Note that these deltas are relative to a specific cached response. That is, a client cannot request a delta without specifying, somehow, which two instances of a resource are being differenced. The "new" instance is implicitly the current instance that the server would return for an unconditional request, and the "old" instance is the one that is currently in the client's cache. The cache validator (last-modified time or entity tag) is what is used to communicate to the server the identity of the old instance.
非公式に、人はそれぞれ、100％およびリソースの0％の「デルタ」としてこれらを考えることができます。これらのデルタは、特定のキャッシュされた応答に関連していることに注意してください。これは、クライアントがリソースの2つのインスタンスが差分されているか、どういうわけか、指定せずにデルタを要求することはできません、です。 「新しい」インスタンスは、暗黙のうちにサーバが無条件の要求のために戻ってくることを、現在のインスタンスであり、「古い」のインスタンスは、クライアントのキャッシュ内に現在あるものです。キャッシュバリデータ（最終更新時刻またはエンティティタグ）が、サーバーに古いインスタンスのアイデンティティを通信するために使用されるものです。
In order to support the transmission of actual deltas, an extension to HTTP/1.1 needs to provide these features:
実際のデルタの送信、これらの機能を提供するために、HTTP / 1.1のニーズへの拡張をサポートするために：
2. A way to specify the old instance, to which the delta will be applied by the client.
これはデルタがクライアントによって適用されるために、古いインスタンスを指定する2.方法。
3. A way to indicate that the client is able to apply one or more specific forms of delta encoding.
3.方法は、クライアントがデルタエンコーディングの一つ以上の特定の形式を適用することが可能であることを示します。
4. A way to mark a response as being delta-encoded in a particular format.
4.デルタ符号化された特定のフォーマットであると応答をマークする方法。
The first two features are already provided by HTTP/1.1: the presence of a conditional request-header (such as "If-Modified-Since" or "If-None-Match") marks a request as conditional, and the value of that header uniquely specifies the old instance (ignoring the problem of last-modified timestamp granularity).
最初の二つの機能は既にHTTP / 1.1によって提供される：条件付きのリクエストヘッダの存在のような条件付きの要求をマークし、その値（例えば、または「IF-なしマッチ」「IF修飾は-ため」）ヘッダ一意古いインスタンス（最終更新タイムスタンプ粒度の問題を無視して）を指定。
We defer discussion of the fourth feature, until section 5.6.
私たちは、セクション5.6になるまで、第4の特徴の議論を延期します。
The third feature, a way for the client to indicate that it is able to apply deltas (aside from the trivial 0% and 100% deltas), can be accomplished by transmitting a list of acceptable delta-encoding formats in a request-header field; specifically, the "A-IM" header. The presence of this list in a conditional request indicates that the client is able to apply delta-encoded cache updates.
第三の特徴、（些細な、0％と100％のデルタは別に）デルタを適用することが可能であることを示すために、クライアントのための方法は、リクエストヘッダフィールドに許容されるデルタ符号化フォーマットのリストを送信することによって達成することができます;具体的には、 "A-IM" ヘッダ。条件付きリクエストでこのリストの存在は、クライアントがデルタエンコードされたキャッシュの更新を適用することが可能であることを示しています。
For example, a client might send this request:
例えば、クライアントはこの要求を送信する場合があります：
GET /foo.html HTTP/1.1 Host: bar.example.net If-None-Match: "123xyz" A-IM: vcdiff, diffe, gzip
GET /foo.html HTTP / 1.1ホスト：bar.example.netの場合 - なし - マッチ： "123xyz"-IM：vcdiff、diffe、GZIP
The meaning of this request is that:
この要求の意味は、次のとおりです。
- The client wants to obtain the current value of /foo.html.
- クライアントは/foo.htmlの現在の値を取得したいと考えています。
- It already has a cached response (instance) for that resource, whose entity tag is "123xyz".
- それは、すでにエンティティタグ「123xyz」でそのリソースのためのキャッシュされたレスポンス（インスタンス）を持っています。
- It is willing to accept delta-encoded updates using either of two formats, "diffe" (i.e., output from the UNIX "diff -e" command), and "vcdiff". (Encoding algorithms and formats, such as "vcdiff", are described in section 6.)
- 2つの形式、「diffe」（すなわち、UNIX「差分-e」からの出力命令）、及び「vcdiff」のいずれかを使用してデルタ符号化された更新を受け入れる意志があります。 （例えば「vcdiff」として符号化アルゴリズムとフォーマットは、セクション6に記載されています）
- It is willing to accept responses that have been compressed using "gzip," whether or not these are delta-encoded. (It might be useful to compress the output of "diff -e".) However, based on the mandatory ordering constraint specified in section 10.5.3, if both delta encoding and compression are applied, then this "A-IM" request header specifies that compression should be done last.
- これらは、デルタ・エンコードされているかどうか「GZIP」を使用して圧縮された応答を受け入れることを望んでいます。 （「差分-e」の出力を圧縮するのに有用かもしれない。）しかし、セクション10.5.3に指定された必須の順序制約に基づいて、差分符号化と圧縮の両方が適用される場合、この「A-IM」要求ヘッダ圧縮は最後に行われるべきであることを指定します。
If, in this example, the server's current entity tag for the resource is still "123xyz", then it should simply return a 304 (Not Modified) response, as would a traditional server.
この例では、リソースのためのサーバーの現在のエンティティタグはまだ「123xyz」であれば、従来のサーバーと同じように、それは単に、304（未修正）応答を返す必要があります。
If the entity tag has changed, presumably but not necessarily because of a modification of the resource, the server could instead compute the delta between the instance whose entity tag was "123xyz" and the current instance.
エンティティタグが変更されている場合は、おそらく必ずしもそうとは限らないため、リソースの変更の、サーバーではなく、エンティティタグ「123xyz」と現在のインスタンスだったインスタンス間の差分を計算することができます。
We defer discussion of what the server needs to store, in order to compute deltas, until section 7.
私たちは、セクション7まで、サーバは差分を計算するために、保存するために必要なものの議論を延期します。
We note that if a client indicates it is willing to accept deltas, but the server does not support this form of instance-manipulation, the server will simply ignore this aspect of the request. (HTTP always allows an implementation to ignore a header that is not required by a specification that the implementation complies with, and the specification of "A-IM" allows the server to ignore an instance-manipulation it does not understand.) So if a server either does not implement the A-IM header at all, or does not implement any of the instance manipulations listed in the A-IM header, it acts as if the client had not requested a delta-encoded response: the server generates a status-200 response.
私たちは、クライアントがデルタを受け入れて喜んでであることを示しているが、サーバーがインスタンス操作のこの形式をサポートしていない場合、サーバは単に要求のこの側面を無視することに注意してください。 （HTTPは常に実装が準拠する仕様によって必要とされていないヘッダを無視するように実装することができ、そして「A-IM」の指定は、サーバは、それが理解していないインスタンスの操作を無視することを可能にする。）そうである場合サーバで全てのA-IMヘッダを実装していない、またはクライアントがデルタ符号化された応答を要求していなかったかのように作用し、A-IMヘッダに記載されているインスタンスの操作のいずれかを実装していない次のいずれかのサーバーステータスを生成します-200応答。
The server is not required to transmit a delta-encoded response. For example, the result might be larger than the current size of the resource. The server might not be able to compute a delta for this type of resource (e.g., a compressed binary format); the server might not have sufficient CPU cycles for the delta computation; the server might not support any of the delta formats supported by the client; or, the network bandwidth might be high enough that the delay involved in computing the delta is not worth the delay avoided by sending a smaller response.
サーバはデルタ符号化された応答を送信する必要はありません。例えば、結果は、リソースの現在のサイズよりも大きくなる可能性があります。サーバは、リソース（例えば、圧縮されたバイナリ形式）このタイプのデルタを計算することができないかもしれません。サーバーは、デルタ計算のための十分なCPUサイクルを持っていない可能性があります。サーバーは、クライアントでサポートされているデルタ形式のいずれかをサポートしていない可能性があります。または、ネットワーク帯域幅は、デルタの計算に関わる遅延が小さい応答を送信することで回避遅れ価値がないことを十分に高いかもしれません。
However, if the server does want to compute a delta, and the set of encodings it supports has more than one encoding in common with the set offered by the client, which encoding should it use? This is mostly at the option of the server, although the client can express preferences using "Quality Values" (or "qvalues") in the "A-IM" header. The HTTP/1.1 specification [10] describes qvalues in more detail. (Clients may prefer one delta encoding format over another that generates a smaller encoding, if the decoding costs for the first format are lower and the client is resource-constrained.)
ただし、サーバーは、デルタを計算したいんし、それがサポートするエンコーディングのセットは、エンコーディングは、それが使用する必要があり、クライアントが提供するセット、との共通点が複数のエンコーディングを持っている場合はどうなりますか？クライアントが「A-IM」ヘッダの「品質値」（または「qvalues」）を使用して好みを表現することができるが、これは、主にサーバの選択です。 HTTP / 1.1仕様書[10]より詳細にqvaluesを記述する。 （第一フォーマットの復号コストが低く、クライアントがリソース制約である場合、クライアントは、より小さな符号を生成する別の上の1つのデルタ符号化フォーマットを好むかもしれません。）
Server implementations have a number of possible approaches. For example, if CPU cycles are plentiful and network bandwidth is scarce, the server might compute each of the possible encodings and then send the smallest result. Or the server might use heuristics to choose an encoding format, based on things such as the content-type of the resource, the current size of the resource, and the expected amount of change between instances of the resource.
サーバ実装は、可能な多数のアプローチがあります。 CPUサイクルが豊富であり、ネットワーク帯域幅が不足している場合たとえば、サーバーは、可能なエンコーディングのそれぞれを計算して、最小の結果を送信することがあります。またはサーバは、そのようなリソースのコンテンツタイプ、リソースの現在のサイズ、およびリソースのインスタンス間の変化の予想量として、物事に基づいて符号化形式を、選択するヒューリスティックを使用する場合があります。
Note that it might pay to cache the deltas internally to the server, if a resource is typically requested by several different delta-capable clients between modifications. In this case, the cost of computing a delta may be amortized over many responses, and so the server might use a more expensive computation.
リソースは通常、変更の間に、いくつかの異なるデルタ対応のクライアントによって要求された場合には、サーバに内部デルタをキャッシュするために支払うかもしれないことに注意してください。この場合、デルタを計算するコストは、多くの回答で償却することができる、そしてそのサーバは、より高価な計算を使用する場合があります。
A response using delta encoding must be identified as such. This is done using the "IM" response-header, specified in section 10.5.2.
デルタ符号化を使用して応答は、そのように識別されなければなりません。これは、セクション10.5.2で指定された「IM」レスポンスヘッダを使用して行われます。
However, a simplistic application of this approach would cause serious problems if a delta-encoded response flows through an intermediate (proxy) cache that is not cognizant of the delta mechanism. Because the Internet still includes a significant number of HTTP/1.0 caches, which might never be entirely replaced, and because the HTTP specifications insist that message recipients ignore any header field that they do not understand, a non-delta-capable proxy cache that receives a delta-encoded response might store that response, and might later return it to a non-delta-capable client that has made a request for the same resource. This naive client would believe that it has received a valid copy of the entire resource, with predictably unpleasant results.
デルタ符号化された応答がデルタ機構を認識しない中間体（プロキシ）キャッシュが流れる場合は、このアプローチの単純アプリケーションは、深刻な問題を引き起こします。インターネットはまだ完全に置き換えることがないかもしれないHTTP / 1.0キャッシュ、かなりの数が含まれているため、およびHTTPの仕様は、そのメッセージの受信者は、彼らが理解していないことを任意のヘッダフィールド、受信非デルタ対応のプロキシキャッシュを無視して主張しているためデルタエンコードされた応答は、その応答を保存するかもしれない、と後で同じリソースに対する要求を行った非デルタ対応のクライアントにそれを返すことがあります。この素朴なクライアントは、それが予想通りに不快な結果で、全体のリソースの有効なコピーを受け取ったことを信じています。
To solve this problem, we propose that delta-encoded responses (actually, all instance-manipulated responses) be identified as such using a new HTTP status code. For specificity in the discussion that follows, we will use the (currently unassigned) code of 226, with a reason phrase of "IM Used". (We see no benefit in spelling out the words "Instance Manipulation Used," since this requires the transmission of unnecessary bytes, and this Reason-phrase should not normally be seen by human users.) There is some precedent for this approach: the HTTP/1.1 specification introduces the 206 (Partial Content) status code, for the transmission of sub-ranges of a resource. Existing proxies apparently forward responses with unknown status codes, and do not attempt to cache them.
この問題を解決するために、我々は新しいHTTPステータスコードを使用して（実際には、すべてのインスタンス操作応答は）そのように識別されているデルタエンコードされた応答を提案します。以下の説明では特異性のために、私たちは「使用IM」の理由フレーズで、226の（現在は割り当てられていない）コードを使用します。 （これは、不必要なバイトの伝送を必要とし、この理由フレーズは、通常、人間のユーザが見るべきではありませんので、我々は「使用されるインスタンス操作」の言葉を綴りで何の利益を見ていない。）このアプローチのためのいくつかの先例があります：HTTPは、 /1.1仕様は、リソースのサブレンジの送信のために、206（部分コンテンツ）ステータスコードを導入します。プロキシに未知のステータスコードと明らかに前方回答を既存の、およびそれらをキャッシュしようとしません。
An alternative to using a new status code would be to use the "Expires" header to prevent HTTP/1.0 caches from storing the response, then use "Cache-Control: max-age" (defined in HTTP/1.1) to allow more modern caches to store delta-encoded responses. This adds many bytes to the response headers, and so would reduce the effectiveness of delta encoding. It is also not entirely clear that this approach suppresses all caching by all HTTP/1.0 proxies.
より現代的な許可する（HTTP / 1.1で定義されている）：新しいステータスコードを使用する代わりに、その後、「最大エージングのCache-Control」を使用し、応答を格納からHTTP / 1.0キャッシュを防ぐために、ヘッダーを「有効期限」を使用することですデルタエンコードされた応答を格納するキャッシュ。これは、レスポンスヘッダに多くのバイトを追加し、その差分エンコーディングの有効性を減少させるであろう。このアプローチは、すべてのHTTP / 1.0プロキシによってすべてのキャッシュを抑制することも完全には明らかではありません。
We were reluctant to define an additional status code as part of the support for delta encoding. However, we see no other efficient way to remain compatible with the deployed base of HTTP/1.0 cache implementations.
我々は、デルタ符号化のためのサポートの一部として、追加のステータスコードを定義することに消極的でした。しかし、我々は、HTTP / 1.0キャッシュ実装の展開ベースとの互換性を維持するために、他の効率的な方法を参照してくださいません。
Although we are not aware of any HTTP/1.1 proxy implementations that would attempt to cache a response with an unknown 2xx status code, the HTTP/1.1 specification does allow this behavior if the response carries an Expires or Cache-Control header field that explicitly allows caching. This would present a problem when a 226 (IM Used) response carries such headers.
我々は、未知の2xxステータスコードで応答をキャッシュしようと任意のHTTP / 1.1プロキシの実装を認識していないが、HTTP / 1.1仕様では、応答が明示的に可能に期限切れになるかのCache-Controlヘッダフィールドを運ぶ場合は、この動作を許可しませんキャッシング。 226（IM中古）応答は、このようなヘッダを有する場合、これは問題を提示します。
The solution in that case is to exploit the Cache Control Extensions mechanism from the HTTP/1.1 specification. We define a new cache-directive, "im", which indicates that the "no-store" cache-directive may be ignored by implementations that conform to the specification for the IM and A-IM headers.
その場合の解決策は、HTTP / 1.1の仕様からキャッシュ制御拡張メカニズムを利用することです。私たちは、「無店舗」キャッシュ・ディレクティブは、IMやA-IMヘッダの仕様に準拠する実装によって無視される可能性があることを示しており、「イム」を新しいキャッシュ・ディレクティブを定義します。
For example, this response:
例えば、この応答：
HTTP/1.1 226 IM Used ETag: "489uhw" IM: vcdiff Date: Tue, 25 Nov 1997 18:30:05 GMT Cache-Control: no-store, im, max-age=30
HTTP / 1.1 226 IM使用したETag： "489uhw" IM：vcdiff日：火、1997年11月25日18時30分05秒GMTのCache-Control：無店舗、IM、最大エージング= 30
...
。。。
"MUST NOT" be stored by a cache that complies with the HTTP/1.1 specification (which states that the max-age cache-directive "implies that the response is cacheable [...] unless some other, more restrictive cache directive is also present."). However, a cache that does comply with the specification for the im cache-directive (i.e., a cache that complies with the specification for the A-IM and IM header fields, and the 226 status code) ignores the no-store directive, and therefore sees the max-age directive as allowing caching.
他のいくつかの、より制限のキャッシュディレクティブでもない限り、最大エージングキャッシュ・ディレクティブは「[...]応答がキャッシュ可能であることを意味していることを述べている（HTTP / 1.1仕様に準拠したキャッシュによって保存され、「てはなりません」存在。 "）。しかし、IMの仕様に準拠しないキャッシュは、キャッシュディレクティブ（すなわち、A-IMおよびIMヘッダフィールドの仕様に準拠キャッシュ、および226のステータスコード）なしストア命令を無視し、そしてしたがって、キャッシングを許可するなどのmax-ageディレクティブを見ています。
We are not entirely sure that all HTTP/1.1 caches obey the rule that the max-age directive is overridden by the no-store directive. If operational testing reveals this to be a problem, more elaborate solutions are possible.
我々は、すべてのHTTP / 1.1キャッシュは最大-ageディレクティブが無店舗ディレクティブで上書きされたルールに従うことを完全に確認されていません。運用テストは、これが問題であることを明らかになった場合、より精巧なソリューションが可能です。
Warning to origin server implementors: it does not suffice to send
オリジンサーバの実装者に警告：それは、送信するために十分ではありません
Vary: If-None-Match, A-IM
ヴァリ：もし-なしマッチ、A-IM
in status-226 responses. We have discovered at least one scenario where this does not prevent a proxy cache that does not implement IM and A-IM from incorrectly "validating" a cached 226 response.
ステータス226レスポンスインチ私たちは、これが間違ってキャッシュされた226応答を「有効」からIMやA-IMを実装していないプロキシキャッシュを防ぐことはできません少なくとも一つのシナリオを発見しました。
A delta-encoded response differs from a standard response in four ways:
デルタ符号化された応答は、4つの方法で標準的な応答とは異なります。
2. It carries an "IM" response-header field, indicating which delta encoding is used in this response.
2.なお、この応答に使用される差分符号化を示す、「IM」レスポンスヘッダフィールドを運びます。
3. Its message-body is a delta encoding of the current instance, rather than a full copy of the instance.
3.そのメッセージボディは、現在のインスタンスの差分エンコーディングではなく、インスタンスの完全なコピーです。
4. It might carry several other new headers, as described later in this document.
このドキュメントで後述するように4。それは、他のいくつかの新しいヘッダを運ぶかもしれません。
For example, a response to the request given in section 5.2 might look like:
例えば、セクション5.2で与えられた要求に対する応答は次のようになります。
HTTP/1.1 226 IM Used ETag: "489uhw" IM: vcdiff Date: Tue, 25 Nov 1997 18:30:05 GMT
HTTP / 1.1 226 IM使用したETag：IMを "489uhw"：vcdiff日：火、1997年11月25日18時30分05秒GMT
...
。。。
(We do not show the actual contents of the response body, since this is a binary format.)
（これはバイナリ形式であるため、我々は、レスポンスボディの実際の内容は表示されません。）
Note: the Etag header in a 226 response with a delta encoding provides the entity tag of the current instance of the resource variant. It is not meaningful to associate an entity tag with the delta value, which is not an instance.
注：差分エンコーディングと226応答のEtagヘッダは、リソースのバリアントの現在のインスタンスのエンティティタグを提供します。インスタンスではないデルタ値とエンティティタグを関連付けることは意味がありません。
In the example used in section 5.2, the client sends:
セクション5.2で使用される例では、クライアントが送信します。
GET /foo.html HTTP/1.1 Host: bar.example.net If-None-Match: "123xyz" A-IM: vcdiff, diffe, gzip
GET /foo.html HTTP / 1.1ホスト：bar.example.netの場合 - なし - マッチ： "123xyz"-IM：vcdiff、diffe、GZIP
and the server either responds with a 304 (Not Modified) response, or with the appropriate delta encoding.
そしてサーバは、いずれかの304（変更されていません）応答で応答、または適切な差分エンコーディング有します。
Here are a few more examples, to clarify how the client request should be interpreted.
ここではいくつかのより多くの例は、クライアントの要求をどのように解釈するかを明確にするために、あります。
If the client sends
クライアントが送信した場合、
GET /foo.html HTTP/1.1 Host: bar.example.net If-None-Match: "123xyz" A-IM: vcdiff, diffe, gzip, range Range: bytes=0-99
GET /foo.html HTTP / 1.1ホスト：bar.example.netの場合 - なし - マッチ： "123xyz"-IM：vcdiff、diffe、GZIP、レンジ範囲：バイト= 0-99
then the meaning is the same as in the example above, except that after the delta encoding (and compression, if any) is computed, the server then returns only the first 100 bytes of the output of the delta encoding. (If it is shorter than 100 bytes, the entire delta encoding is returned.) Because the "range" token appears last in the "A-IM" header, this tells the origin server to apply any range selection after the other instance-manipulations.
その後意味は、その算出された差分符号化後の（もしあれば、圧縮）、サーバは、次に、差分エンコーディングの出力の最初の100のバイトを返す以外は、上記実施例と同様です。 （それは100バイトよりも短い場合、全体の差分エンコーディングが返される。）「範囲」トークンは、「A-IM」ヘッダの最後に表示されているので、これは他のインスタンスの操作後の任意の範囲の選択を適用するために、オリジンサーバに指示。
The interaction between the If-Range mechanism and delta encoding is somewhat complex. (If-Range means, informally, "if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity.") Here is an example that should clarify the use of this combination.
もしレンジメカニズムとデルタエンコーディング間の相互作用はやや複雑です。 （レンジの場合を意味し、非公式に、「エンティティが変更されていない場合は、私が行方不明です一部（複数可）を送る、そうでない場合、私は全体の新しいエンティティを送信する。」）ここでは、この組み合わせの使用を明確にすべき例です。 。
Suppose that the client wants to have the complete current instance of http://bar.example.net/foo.html. It already has a (complete) cache entry for this URI, with entity tag "A", so it issues this request:
クライアントはhttp://bar.example.net/foo.htmlの完全な現在のインスタンスを持っているしたいと仮定します。これは、すでにエンティティタグ「A」と、このURIのための（完全な）キャッシュエントリを、持っているので、この要求を発行します。
GET /foo.html HTTP/1.1 host: bar.example.net If-None-Match: "A" A-IM: vcdiff
GET /foo.html HTTP / 1.1ホスト：bar.example.netの場合 - なし - マッチ： "" A-IM：vcdiff
Suppose that the server's current instance has entity tag "B", and that the server also has retained a copy of the instance with entity tag "A". Then, the server could compute the difference between "B" and "A", and respond with:
サーバーの現在のインスタンスは、エンティティタグ「B」を持っていること、およびサーバはまたエンティティタグ「A」とインスタンスのコピーを保持していると仮定します。その後、サーバは「B」と「A」の間の差を計算し、で応答できます。
HTTP/1.1 226 IM Used Etag: "B" IM: vcdiff Date: Tue, 25 Nov 1997 18:30:05 GMT Content-Length: 1000
HTTP / 1.1 226 IM使用したEtag： "B" IM：vcdiff日：火、1997年11月25日夜6時30分05秒GMTのコンテンツの長さ：1000
...
。。。
but the network connection is terminated after the client has received exactly 900 bytes of the message body for the delta-encoded content.
クライアントは、デルタエンコードされたコンテンツのためのメッセージ本体の正確900バイトを受信した後ではなく、ネットワーク接続を終了します。
The client wants to retrieve the remaining 100 bytes of the delta encoding that was being sent in the interrupted response. It therefore should send:
クライアントは、中断応答して送信されていたデルタエンコーディングの残り100のバイトを取得したいと考えています。したがって、送信する必要があります：
GET /foo.html HTTP/1.1 host: bar.example.net If-None-Match: "A" If-Range: "B" A-IM: vcdiff,range Range: bytes=900-
GET /foo.html HTTP / 1.1ホスト：bar.example.net場合 - なし - マッチ： "" レンジ場合： "B"-IM：vcdiff、レンジの範囲は：バイト= 900-
This rather elaborate request has a well-defined meaning, which depends on the current entity tag Tcur of the instance when the server receives the request:
このかなり精巧な要求は、サーバーが要求を受信したときに、インスタンスの現在のエンティティタグTcurに依存し、明確に定義された意味を、持っています：
Tcur = "A" (i.e., for some reason, the instance has reverted to the value already in the client's cache). The server should return a 304 (Not Modified) response, as required by the HTTP/1.1 specification for "If-None-Match".
Tcur =「A」は（すなわち、何らかの理由で、インスタンスは、クライアントのキャッシュにすでに値に戻っています）。 「もし-なし・マッチ」のためのHTTP / 1.1仕様で要求されるサーバは、304（未修正）応答を返す必要があります。
Tcur = "B" (i.e., the instance has not changed again). The HTTP/1.1 specification for "If-None-Match", in this case, is that the header field is ignored (by a server that does not understand delta encoding). Therefore, this is equivalent to the client's previous request, except that the Range selection is applied after the vcdiff instance manipulation (if both are to be applied). So the (delta-aware) server again computes the delta between the "A" instance and the "B" instance (or uses a cached computation of the delta), then applies the Range selection, and returns a 226 (IM Used) response, with an message-body containing bytes 900 to 999 of the result of the vcdiff encoding, with an "IM:vcdiff,range" response header.
Tcur =「B」（すなわち、インスタンスは再び変更されていません）。 「場合-なしマッチ」のHTTP / 1.1仕様では、この場合には、ヘッダフィールドは（デルタエンコーディングを理解していないサーバで）は無視されることです。したがって、これは、範囲選択が（両方が適用される場合）vcdiffインスタンス操作の後に適用されることを除いて、クライアントの前の要求と同じです。だから（デルタ対応）サーバは、再び「」インスタンスと「B」のインスタンスとの間の差分を計算する（またはデルタのキャッシュされた計算を使用して）、次に、範囲選択を適用し、226（IM中古）応答を返します、「IM：vcdiff、範囲」とvcdiff符号化の結果の999バイト900を含むメッセージボディとレスポンスヘッダ。
Tcur = "C" (i.e., the instance has changed again). In this case, the HTTP/1.1 specification for "If-None-Match" again means that this is equivalent to an unconditional request for the current instance. The specification for "If-Range" requires the server to return the entire current instance. However, a delta-aware server can construct the delta between the "A" instance described by the "If-None-Match" field and the current ("C") instance, and return a 226 (IM Used) response, with an "IM:vcdiff" response header.
Tcur = "C"（すなわち、インスタンスが再び変更されています）。この場合は、「IF-なし・マッチ」のためのHTTP / 1.1仕様では、再び、これは現在のインスタンスのために無条件の要求と等価であることを意味しています。 「もしレンジ」の仕様は、全体の現在のインスタンスを返すようにサーバが必要です。しかしながら、デルタ認識サーバは、「IF-なしマッチ」フィールド及び現在の（「C」）インスタンスによって記述された「」インスタンスとの間のデルタを構築することができる、として、226（IM中古）応答を返します"IM：vcdiff" レスポンスヘッダ。
If the client's request had not included the "If-None-Match: "A"" header field, the server could not have computed a delta, since it would not have known which entire instance was already available to the client. If the request had not included the "If-Range: "B"" header field, the server could not have distinguished between the latter two cases (Tcur = "B" or Tcur = "C") and would not have been able to apply the Range selection to the result of delta encoding.
クライアントの要求は、「IF-なし - マッチ： 『含まれていなかった場合はA』」ヘッダフィールドを、それが全体のインスタンスが既にクライアントが利用可能だった知られていないため、サーバーは、差分を計算していませんでした。要求が含まれていなかった場合、「場合レンジ： 『B』」ヘッダフィールドは、サーバは、後の2つの場合の間の区別はありませでした（Tcurが=「B」またはTcur =「C」）とすることができなかったであろうデルタエンコーディングの結果に範囲選択を適用します。
On the other hand, suppose that the client has a cache entry for the "A" instance of http://bar.example.net/foo.html, and it has already received the first 900 bytes of a new instance "B" (perhaps as the result of an aborted transfer). Now the client wants to receive the entire current instance, so it could send this request:
一方、クライアントはhttp://bar.example.net/foo.htmlの「A」インスタンスのキャッシュエントリがあるとし、それはすでに新しいインスタンス「B」の最初の900のバイトを受信しました（おそらく中止された転送の結果として）。今、クライアントは、この要求を送信することができるように、全体の現在のインスタンスを受信したいです。
GET /foo.html HTTP/1.1 host: bar.example.net If-None-Match: "A" If-Range: "B" A-IM: range,vcdiff Range: bytes=900-
GET /foo.html HTTP / 1.1ホスト：bar.example.netの場合 - なし - マッチ： "A" の場合、範囲： "B"-IM：レンジ、vcdiff範囲：バイト= 900-
In this example, as in the previous example, if Tcur = "A" then the server should send 304 (Not Modified), and if Tcur = "C", then the server should send the entire new instance, either as a 200 response or as a delta encoding against instance "A".
この例では、前の例のように、場合Tcur =「A」、サーバは、送信しなければならない304（変更せず）と、Tcur =「C」は、サーバは、全体の新しいインスタンスを送信する必要がある場合のいずれかの200応答としてまたはインスタンス「A」に対する差分エンコーディングとして。
However, if Tcur = "B", in this case the server should first select the specified range (bytes 900 through the end) from both instances "A" and "B", then compute the delta encoding between these ranges (using vcdiff), and then transmit the result using a 226 (IM Used) response with an "IM:range,vcdiff" response header.
Tcur =「B」は、この場合、サーバは最初の両方のインスタンス「A」と「B」から指定された範囲（エンド貫通バイト900）を選択しなければならない場合は、これらの範囲の間の差分エンコーディングを計算する（使用vcdiff） 「レンジ、vcdiff IM」応答ヘッダ、および次いで226（IM中古）応答を使用して結果を送信します。
6 Encoding algorithms and formats
6つの符号化アルゴリズムとフォーマット
A number of delta encoding algorithms and formats have been described in the literature:
デルタ符号化アルゴリズムとフォーマットの数は、文献に記載されています。
diff -e The UNIX "diff" program is ubiquitously available, and is relatively fast for both encoding and decoding (decoding is actually done using the "ed" program). However, the size of the resulting deltas is relatively large. This algorithm can only be used on text-format files.
UNIX「差分」プログラム-e diffが遍在利用可能であり、そして（復号が実際に「ED」プログラムを使用して行われる）符号化および復号化の両方のために比較的高速です。しかし、得られた差分の大きさが比較的大きいです。このアルゴリズムは、テキスト形式のファイルで使用することができます。
diff -e | gzip Running the output of "diff" through a compression algorithm such as "gzip" [5] (or, perhaps better, "deflate" [7, 6]) yields a more compact encoding, but the costs of encoding and decoding are much higher than for "diff" by itself. This algorithm can only be used on text-format files.
差分-e |そのような「GZIP」などの圧縮アルゴリズムを介して、「差分」の出力を実行するGZIP [5]（または、おそらくより良い、「収縮」[7,6]）よりコンパクトな符号化をもたらすが、符号化および復号化のコストがはるかにありますそれ自体で「差分」よりも高いです。このアルゴリズムは、テキスト形式のファイルで使用することができます。
vcdiff (vdelta) The algorithm that generates the "vcdiff" format [19, 20] inherently compresses its output, and generally produces smaller results than the combination of "diff" and "gzip". The algorithm also runs much faster, and can be applied to binary-format input. The "vcdiff" format is based on previous work on an algorithm named "vdelta." (Note that the "vcdiff" format can be used either for delta encoding or as a compressed format, so two different instance-manipulation values would have to be registered in order to distinguish these two uses, should its use as a compressed format be adopted.) The most recent published study suggests that "vdelta" is the best overall delta algorithm [16].
vcdiff（vdelta）「vcdiff」形式を生成するアルゴリズム[19、20]は、本質的にその出力を圧縮し、一般的に「差分」および「GZIP」の組み合わせよりも小さい結果を生成します。アルゴリズムはまた、はるかに速く実行され、バイナリ形式の入力に適用することができます。 「vcdiff」形式の名前は、アルゴリズムの前の仕事に基づいている「vdelta。」 （「vcdiff」フォーマットが差分符号化または圧縮されたフォーマットのいずれかを用いることができるので、2つの異なるインスタンス操作値は、これら2つの用途を区別するために登録しなければならないであろう、圧縮形式としてのその使用を採用しなければなりません。）直近発表された研究は、「vdeltaは」最高の全体的なデルタアルゴリズム[16]であることを示唆しています。
gdiff The gdiff format [14] was specified as a generic, algorithm-independent format for expressing deltas. Because it is more generic it is easy to implement, but it may not be the most compact encoding format.
GDIFF形式[14] GDIFFデルタを発現させるための一般的なアルゴリズムに依存しない形式として指定されました。それがより一般的であるため、実現するのは簡単ですが、それは最もコンパクトなエンコード形式ではないかもしれません。
Our proposal does not recommend any specific algorithm or format, but rather encourages client and server implementors to choose the most appropriate one(s). However, to avoid the possibility of excessively long "A-IM" headers, we suggest that, after some period of experimentation, it might be reasonable to specify a "recommended" set of delta formats for general-purpose HTTP implementations.
私たちの提案は、いかなる特定のアルゴリズムやフォーマットをお勧めではなく、最も適切なもの（複数可）を選択し、クライアントとサーバーの実装を奨励しません。しかし、過度に長い「A-IM」ヘッダの可能性を回避するために、我々は実験のいくつかの期間の後、指定するのが妥当であるかもしれない、ことを示唆している「推奨」の汎用HTTP実装のためのデルタフォーマットのセット。
We suspect that it should be possible to devise a delta encoding algorithm appropriate for use on typical image encodings, such as GIF and JPEG. Although experiments with vdelta have not shown much potential [23], this may simply be because these experiments used vdelta directly on the already-compressed forms of these encodings. However, it might be necessary to devise a delta encoding algorithm that is aware of the two-dimensional nature of images. We have some expectation that this is possible, since MPEG compression relies on computing deltas between successive frames of a video stream.
私たちは、そのようなGIFやJPEGなどの典型的な画像エンコーディング、上で使用するための適切なデルタ符号化アルゴリズムを考案することが可能なはずであると思われます。 vdeltaを用いた実験は、[23]電位あまり示していないが、これらの実験は、これらのエンコーディングの既に圧縮された形に直接vdeltaを使用するので、これは単純であってもよいです。しかし、画像の2次元的性質を認識しているデルタ符号化アルゴリズムを考案する必要がある場合があります。私たちは、MPEG圧縮はビデオストリームの連続するフレーム間の差分を計算に依存しているので、これは、可能であることを、いくつかの期待を持っています。
7 Management of base instances
ベースインスタンスの7の管理
If the time between modifications of a resource is less than the typical eviction time for responses in client caches, this means that the "old instance" indicated in a client's conditional request might not refer to the most recent prior instance. This raises the question of how many old instances of a resource should be maintained by the server, if any. We call these old instances "base instances."
リソースの変更の間の時間は、クライアントキャッシュでの応答のための典型的な立ち退き時間未満の場合、これはクライアントの条件付き要求に示さ「古いインスタンスは、」最近の前のインスタンスを参照していない可能性があることを意味します。これは、いずれかの場合に、リソースの古いインスタンスは、サーバーによって維持されるべきであるどのように多くの問題を提起します。私たちは、「ベースインスタンス。」これらの古いインスタンスを呼び出します
There are many possible options for server implementors. For example:
サーバーの実装のための多くの可能なオプションがあります。例えば：
- The server might not store any old instances, and so would never respond with a delta.
- サーバーは、任意の古いインスタンスを保存しないかもしれません、そのためデルタで応答することはありません。
- The server might only store the most recent prior instance; requests attempting to validate this instance could be answered with a delta, but requests attempting to validate older instances would be answered with a full copy of the resource.
- サーバは、最新の前のインスタンスを保存するかもしれません。このインスタンスを検証しようとする要求は、デルタと答えたことができますが、古いインスタンスを検証しようとする要求は、リソースの完全なコピーで答えられるでしょう。
- The server might store all prior instances, allowing it to provide a delta response for any client request.
- サーバーは、それが任意のクライアント要求のためのデルタ応答を提供できるように、以前のすべてのインスタンスを格納することがあります。
- The server might store only a subset of the prior instances. The use of a Least Recently Used (LRU) algorithm to determine this kind of subset has proved effective in some similar circumstances, such as cache replacement.
- サーバは、前のインスタンスのサブセットだけを保存することがあります。 LRU（Least Recently Used）アルゴリズムを使用することは、サブセットのこの種は、キャッシュリプレースなどのいくつかの類似した状況で有効なことが証明されているかを決定します。
The server might not have to store prior instances explicitly. It might, instead, store just the deltas between specific base instances and subsequent instances (or the inverse deltas between base instances and prior instances). This approach might be integrated with a cache of computed deltas.
サーバーは、明示的に前にインスタンスを格納する必要はないかもしれません。それは、代わりに、特定のベース・インスタンスとそれに続くインスタンス（またはベースインスタンスと前のインスタンスとの間の逆デルタ）の間だけデルタを格納するかもしれません。このアプローチは、計算されたデルタのキャッシュに統合される可能性があります。
None of these approaches necessarily requires additional protocol support. However, if a server administrator wants to store only a subset of the prior instances, but would like the server to be able to respond using deltas as often as possible, then the client needs some additional information. Otherwise, the client's "If-None-Match" header might specify a base instance not stored at the server, even though an appropriate base instance is held in the client's cache.
これらのアプローチはいずれも、必ずしも追加のプロトコルのサポートを必要としません。サーバ管理者は、前のインスタンスのサブセットだけを保存したいと考えていますが、サーバーはできるだけ頻繁にデルタを使用して対応できるようにしたい場合は、クライアントはいくつかの追加情報を必要とします。それ以外の場合は、クライアントの「IF-なしマッチ」ヘッダは、適切なベース・インスタンスは、クライアントのキャッシュに保持されていても、サーバーに保管されていないベースインスタンスを指定できます。
We identify two additional protocol changes to help solve this problem.
私たちは、この問題を解決するために、2つの追加のプロトコルの変更を識別します。
Although the examples we have given so far show only one entity tag in an "If-None-Match" header, the HTTP/1.1 specification allows the header to carry more than one entity-tag. This feature was included in HTTP/1.1 to support efficient caching of multiple variants of a resource, but it is not restricted to that use.
我々はこれまでに与えられている例は、「もし-なしマッチ」ヘッダーで唯一のエンティティタグを示しているが、HTTP / 1.1仕様では、複数のエンティティタグを運ぶためのヘッダを可能にします。この機能は、リソースの複数のバリアントの効率的なキャッシングをサポートするためにHTTP / 1.1に含まれていたが、それは、その使用に限定されません。
Suppose that a client has kept more than one instance of a resource in its cache. That is, not only does it keep the most recent instance, but it also holds onto copies of one or more prior, invalid instances. (Alternatively, it might retain sufficient delta or inverse-delta information to reconstruct older instances.) In this case, it could use its conditional request to tell the server about all of the instances it could apply a delta to. For example, the client might send:
クライアントがキャッシュ内のリソースの複数のインスタンスを保持していると仮定します。つまり、最新のインスタンスを維持するだけでなく、ですが、それはまた、1つまたは複数の前に、無効なインスタンスのコピー上に保持しています。 （また、それは古いインスタンスを再構成するのに十分なデルタまたは逆デルタ情報を保持することがあります。）この場合、それはデルタへの適用可能性があり、すべてのインスタンスについて、サーバに伝えるために、その条件付きリクエストを使用することができます。例えば、クライアントが送信する場合があります：
GET /foo.html HTTP/1.1 host: bar.example.net If-None-Match: "123xyz", "337pey", "489uhw" A-IM: vcdiff
GET /foo.html HTTP / 1.1ホスト：bar.example.netの場合 - なし - マッチ： "123xyz"、 "337pey"、 "489uhw"-IM：vcdiff
to indicate that it has three instances of this resource in its cache. If the server is able to generate a delta from any of these prior instances, it can select the appropriate base instance, compute the delta, and return the result to the client.
それはそのキャッシュでこのリソースの3つのインスタンスを持っていることを示します。サーバーは、これらの従来のインスタンスのいずれかからデルタを生成することができるならば、それは、適切なベース・インスタンスを選択し、デルタを計算し、結果をクライアントに返すことができます。
In this case, however, the server must also tell the client which base instance to use, and so we need to define a response header, named "Delta-Base", for this purpose. For example, the server might reply:
しかし、この場合には、サーバーにも使用するようにインスタンスをベースにクライアントに通知しなければならない、と私たちは、この目的のために、「デルタ・ベース」という名前のレスポンスヘッダを定義する必要があります。例えば、サーバが応答することがあります。
HTTP/1.1 226 IM Used ETag: "1acl059" IM: vcdiff Delta-Base: "337pey" Date: Tue, 25 Nov 1997 18:30:05 GMT
HTTP / 1.1 226 IM使用したETag： "1acl059" IM：vcdiffデルタ・ベース： "337pey" 日：火、1997年11月25日夜06時30分05秒GMT
This response tells the client to apply the delta to the cached response with entity tag "337pey", and to associate the entity tag "1acl059" with the result.
この応答は、エンティティタグ「337pey」でキャッシュされた応答にデルタを適用するために、そして結果とエンティティタグ「1acl059」を関連付けるためにクライアントに指示します。
Of course, if the server has retained more than one of the prior instances identified by the client, this could complicate the problem of choosing the optimal delta to return, since now the server has a choice not only of the delta format, but also of the base instance to use.
サーバは、クライアントによって識別される前にインスタンスを複数保持している場合、今、サーバーがデルタ形式の、ものではない唯一の選択肢を持っているので、もちろん、これは、返すために最適なデルタを選択する問題を複雑にする可能性がベースインスタンスに使用します。
Support for multiple entity tags in choosing the base instance implies that a client might benefit from storing multiple old instances of a resource in its cache. A client with finite space would not want to keep all old instances, so it must manage its cache for maximal effectiveness by saving those instances most likely to be useful for future deltas. Although this could be accomplished using information purely local to the client (e.g., an LRU algorithm), certain "hint" information from the server could improve the client's ability to manage its cache. The use of hints for improving Web cache performance has been described previously [4, 22].
ベースインスタンスを選択する際に、複数のエンティティタグのサポートは、クライアントがそのキャッシュ内のリソースの複数の古いインスタンスを保存するの恩恵を受ける可能性があることを意味します。それは将来のデルタのために有用である可能性が最も高いそれらのインスタンスを保存することで、最大の効果のためにそのキャッシュを管理しなければならないので、有限のスペースを持つクライアントは、すべての古いインスタンスを維持したいとは思わないでしょう。これは、サーバからクライアント（例えば、LRUアルゴリズム）、特定の「ヒント」の情報への純粋にローカルな情報を使用して達成することができるが、そのキャッシュを管理するためのクライアントの能力を向上させることができます。ウェブ・キャッシュのパフォーマンスを改善するためのヒントを使用することは、以前に[4、22]に記載されています。
If the server intends to retain certain instances and not others, it can label the responses that transmit the retained instances. This would help the client manage its cache, since it would not have to retain all prior instances on the possibility that only some of them might be useful later. The label is a hint to the client, not a promise that the server will indefinitely retain an instance.
サーバは特定の場合ではなく他人を保持しようとする場合、それは保持インスタンスを送信する応答にラベルを付けることができます。それだけでそれらのいくつかは、後で役に立つかもしれない可能性に以前のすべてのインスタンスを保持する必要はないので、これは、クライアントがそのキャッシュを管理するのに役立ちます。ラベルは、クライアントへのヒントではなく、サーバが無期限のインスタンスを保持します約束です。
We propose adding a new directive to the existing "Cache-Control" header for this purpose, named "retain". For example, in response to an unconditional request, the server might send:
私たちは、「保持」という名前のこの目的のために、既存の「のCache-Control」ヘッダに新しいディレクティブを追加提案します。例えば、無条件の要求に応じて、サーバが送信する場合があります：
HTTP/1.1 200 OK ETag: "337pey" Date: Tue, 25 Nov 1997 18:30:05 GMT Cache-Control: retain
HTTP / 1.1 200 OKのETag： "337pey" 日：火、1997年11月25日午後06時30分05秒GMTののCache-Control：保持
to suggest that a delta-capable client should retain this instance. The "retain" directive could also appear in a delta response, referring to the current instance:
デルタ対応のクライアントは、このインスタンスを保持すべきであることを示唆する。 「保持」ディレクティブは、現在のインスタンスを参照する、デルタ応答に現れることができます：
HTTP/1.1 226 IM Used ETag: "1acl059" Date: Tue, 25 Nov 1997 18:30:05 GMT Cache-Control: retain IM: vcdiff Delta-Base: "337pey"
HTTP / 1.1 226 IM使用したETag： "1acl059" 日：火、1997年11月25日午後6時30分05秒GMTののCache-Control：IMを保持：デルタ・ベースvcdiff： "337peyを"
The "retain" directive includes an optional timeout parameter, which the server can use if it expects to delete an old base instance at a particular time. For example,
「保持」ディレクティブは、それが特定の時間に、古いベース・インスタンスを削除するには、想定している場合、サーバーが使用できるオプションのタイムアウトパラメータを含んでいます。例えば、
HTTP/1.1 200 OK ETag: "337pey" Date: Tue, 25 Nov 1997 18:30:05 GMT Cache-Control: retain=3600
HTTP / 1.1 200 OKのETag： "337pey" 日：火、1997年11月25日午後06時30分05秒GMTのCache-Control：= 3600維持
means that the server intends to retain this base instance for one hour.
サーバは一時間、このベースインスタンスを保持しようとしていることを意味します。
Another situation where a server can provide a hint to a client is where the server supports the delta mechanism in general, but does not intend to provide delta-encoded responses for a particular resource. By sending a "retain=0" directive, it indicates that the client should not waste request-header bytes attempting to obtain a delta-encoded response using this base instance (and, by implication, for this resource). It also indicates that the client ought not waste cache space on this instance after it has become stale. To avoid wasting response-header bytes, a server ought not send "retain=0", except in reply to a request that attempts to obtain a delta-encoded response.
サーバーは、一般的にはデルタ・メカニズムをサポートしていますが、特定のリソースのためのデルタ - エンコードされた応答を提供する予定はありません。どこのサーバーがクライアントにヒントを提供することができます別の状況です。 「= 0を保持する」ディレクティブを送信することによって、それは、クライアントが（このリソースに対して、含意により、など）、このベースインスタンスを使用してデルタ符号化された応答を取得しようとリクエスト・ヘッダー・バイトを無駄にはならないことを示しています。また、それが古くなった後、クライアントは、このインスタンスにキャッシュスペースを無駄にしないべきであることを示しています。レスポンスヘッダバイトを浪費を避けるために、サーバは、デルタ符号化された応答を取得しようと要求に対する応答を除いて、「= 0を保持」を送信しないはずです。
Note that the "retain" directive is orthogonal to the "max-age" directive. The "max-age" directive indicates how long a cache entry remains fresh (i.e.,can be used without contacting the origin server for revalidation); the "retain" directive is of interest to a client AFTER the cache entry has become stale.
「保持」ディレクティブが「最大エージング」ディレクティブに直交していることに注意してください。 「最大エージング」ディレクティブは、キャッシュエントリが（すなわち、再検証のためのオリジンサーバに接触することなく使用することができます）、新鮮なまま時間を示し;キャッシュエントリが古くなった後、「保持」ディレクティブはクライアントに重要です。
In practice, the "Cache-Control" response-header field might already be present, so the cost (in bytes) of sending this directive might be smaller than these examples implies.
実際には、「キャッシュ・コントロール」レスポンス・ヘッダー・フィールドは、既に存在するかもしれないので、この指令を送信する（バイト単位）コストは、これらの例が示すよりも小さいかもしれません。
8 Deltas and intermediate caches
8デルタ中間キャッシュ
Although we have designed the delta-encoded responses so that they will not be stored by naive proxy caches, if a proxy does understand the delta mechanism, it might be beneficial for it to participate in sending and receiving deltas.
彼らはナイーブプロキシキャッシュによって保存されないように、我々は、デルタエンコードされた応答を設計してきたが、プロキシがデルタメカニズムを理解しなければ、それはデルタの送受信に参加するために、それは有益かもしれません。
A proxy could participate in several independent ways:
プロキシは、いくつかの独立の方法で参加できます。
- In addition to forwarding a delta-encoded response, the proxy might store it, and then use it to reply to a subsequent request with a compatible "If-None-Match" field (i.e., one that is either a superset of the corresponding field of the request that first elicited the response, or one that includes the "Delta-Base" value in the cached response), and with a compatible "IM" response-header field (one that includes the actual delta-encoding format used in the response.) Of course, such uses are subject to all of the other HTTP rules concerning the validity of cache entries.
- デルタ符号化された応答を転送に加えて、プロキシは、それを格納し、次に「IF-なしマッチ」フィールドの互換性（すなわち、該当のスーパーセットのいずれかであるものと、後続の要求に応答するためにそれを使用するかもしれません最初の応答を誘発し、またはキャッシュされた応答で「デルタベース」値を含むもの）、およびで使用される実際のデルタ符号化フォーマットを含む互換性のある「IM」レスポンス・ヘッダー・フィールドを持つ（1リクエストフィールド応答。）もちろんには、このような用途には、キャッシュエントリの有効性に関する他のHTTPルールの全ての対象となります。
- In addition to forwarding a delta-encoded response, the proxy might apply the delta to the appropriate entry in its own cache, which could then be used for later responses (even from non-delta-capable clients).
- デルタ符号化された応答を転送に加えて、プロキシは次いで、（たとえ非デルタ対応クライアントからの）後の応答のために使用することができ、自身のキャッシュ内の適切なエントリに差分を適用するかもしれません。
- When the proxy receives a conditional request from a delta-capable client, and the proxy has a complete copy of an up-to-date ("fresh," in HTTP/1.1 terminology) response in its cache, it could generate a delta locally and return it to the requesting client.
- プロキシがデルタ対応のクライアントからの条件付きリクエストを受信し、プロキシがキャッシュ内の完全な（HTTP / 1.1の用語では「新鮮な」）最新のコピー応答を持っている場合は、デルタを生成することがありましたローカルと要求元のクライアントに返します。
- When the proxy receives a request from a non-delta-capable client, it might convert this into a delta request before forwarding it to the server, and then (after applying a resulting delta response to one of its own cache entries) it would return a full-body response to the client (or a response with status code 206 or 304, as appropriate).
- プロキシが非デルタ対応のクライアントからの要求を受信すると、それは（独自のキャッシュエントリの1つになるデルタ応答を適用した後）、サーバーに転送する前にデルタ要求にこれを変換し、可能性があることだろうクライアント（または必要に応じて、ステータスコード206または304と対応）に全身応答を返します。
All of these optional techniques increase proxy software complexity, and might increase proxy storage or CPU requirements. However, if applied carefully, they should help to reduce the latencies seen by end users, and load on the network. Generally, CPU speed and disk costs are improving faster than network latencies, so we expect to see increasing value available from complex proxy implementations.
これらのオプションの技術の全ては、プロキシソフトウェアの複雑さを増し、プロキシストレージやCPUの要件が増加する可能性があります。しかし、慎重に適用された場合、彼らはエンドユーザーから見たレイテンシを削減し、ネットワーク上でロードするために役立つはずです。一般的には、CPUの速度とディスクのコストは、より高速なネットワーク遅延よりも向上しているので、私たちは、複雑なプロキシ実装から入手できる増加する値を見ることを期待しています。
9 Digests for data integrity
データ整合性のため9回のダイジェスト
When a recipient reassembles a complete HTTP response from several individual messages, it might be necessary to check the integrity of the complete response. For example, the client's cache might be corrupt, or the implementation of delta encoding (either at client or server) might have a bug.
受信者が複数の個別のメッセージから完全なHTTP応答を再構成するとき、完全な応答の整合性をチェックする必要がある場合があります。たとえば、クライアントのキャッシュが破損している可能性があり、またはデルタエンコーディング（クライアントまたはサーバーでの）の実装では、バグがある可能性があります。
HTTP/1.1 includes mechanisms for ensuring the integrity of individual messages. A message may include a "Content-MD5" response header, which provides an MD5 message digest of the body of the message (but not the headers). The Digest Authentication mechanism [11] provides a similar message-digest function, except that it includes certain header fields. Neither of these mechanisms makes any provision for covering a set of data transmitted over several messages, as would be the case for the result of applying a delta-encoded response (or, for that matter, a Range response).
HTTP / 1.1は、個々のメッセージの整合性を確保するためのメカニズムが含まれています。メッセージは、メッセージ（ただし、ヘッダ）の本体のMD5メッセージダイジェストを提供する「コンテンツ-MD5」応答ヘッダを含むことができます。ダイジェスト認証機構[11]、それは特定のヘッダフィールドを含むことを除いて、同様のメッセージダイジェスト関数を提供します。 （さらに言えば、レンジ応答、または）デルタ符号化された応答を適用した結果のための場合のように、これらのメカニズムのいずれも、いくつかのメッセージを介して送信されるデータのセットをカバーするための任意の規定を行います。
Data integrity for reassembled messages requires the introduction of a new message header. Such a mechanism is proposed in a separate document [24]. One might still want to use the Digest Authentication mechanism, or something stronger, to protect delta messages against tampering.
再構築されたメッセージのためのデータの整合性は、新たなメッセージヘッダの導入が必要となります。そのような機構は、別のドキュメント[24]で提案されています。一つは、まだ改ざんデルタメッセージを保護するため、ダイジェスト認証メカニズム、またはより強力な何かを使用する場合があります。
10 Specification
10仕様
In this specification, the key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described in RFC 2119 [3].
本明細書では[3]、キーワード "MUST"、 "MUST NOT"、 "SHOULD" は、 "べきでない"、及びRFC 2119に記載されるように解釈される "場合があります"。
This specification defines a new HTTP parameter type, an instance-manipulation:
この仕様は、新しいHTTPパラメータの型、インスタンス操作を定義しています。
instance-manipulation = token [imparams]
インスタンス操作=トークン[imparams]
imparams = ";" imparam-name [ "=" ( token | quoted-string ) ] imparam-name = token
imparams = ";" imparam名[「=」（トークン|引用符で囲まれた文字列）] imparam名=トークン
Note that the imparam-name MUST NOT be "q", to avoid ambiguity with the use of qvalues (see [10]).
imparam-nameは（[10]参照）qvaluesを使用してあいまいさを避けるために、「Q」されてはならないことに注意してください。
The set of instance-manipulation values is initially:
インスタンス操作値のセットは、最初は次のとおりです。
- vcdiff A delta using the "vcdiff" encoding format [19, 20].
- "vcdiff" 符号化フォーマット[19、20]を使用してデルタvcdiff。
- diffe The output of the UNIX "diff -e" command [26].
- UNIX "デフ-e" コマンド[26]の出力をdiffe。
- gdiff The GDIFF encoding format [14].
- GDIFF GDIFFエンコード形式[14]。
- gzip Same definition as the HTTP "gzip" content-coding.
- HTTP「GZIP」内容コーディングなどのgzipと同じ定義。
- deflate Same definition as the HTTP "deflate" content-coding.
- HTTPと同じ定義を収縮させるコンテンツコード「収縮」。
- range A token indicating that the result is partial content, as the result of a range selection.
- 結果は、範囲選択の結果として、部分的なコンテンツであることを示すトークンの範囲です。
- identity A token used only in the A-IM header (not in the IM header), to indicate whether or not the identity instance-manipulation is acceptable.
- アイデンティティのみA-IMヘッダ（ないIMヘッダ内）で使用されるトークンは、同一のインスタンス操作が許容されるかどうかを示します。
For convenience in the rest of this specification, we define a subset of instance-manipulation values as delta-coding values:
この仕様の残りの部分では便宜上、我々はデルタコード値としてインスタンスの操作値のサブセットを定義します。
delta-coding = "vcdiff" | "diffe" | "gdiff" | token
デルタコーディング=「vcdiff」| "diffe" | "GDIFF" |トークン
Future instance-manipulation values might also be included in this list.
将来のインスタンス操作値もこのリストに含まれている場合があります。
The Internet Assigned Numbers Authority (IANA) administers the name space for instance-manipulation values. Values and their meaning must be documented in an RFC or other peer-reviewed, permanent, and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. Subject to these constraints, name assignments are First Come, First Served (see RFC 2434 [25]).
IANA（Internet Assigned Numbers Authority）は、インスタンスの操作値のための名前空間を管理します。独立した実装の間の相互運用性が可能になるような値とその意味は十分に詳細に、RFCまたは他の査読、永久的な、かつ容易に入手可能な文献に文書化されなければなりません。件名、これらの制約に、名前の割り当ては早い者勝ちしている（RFC 2434を参照してください[25]）。
This specification also inserts a new value in the IANA HTTP Status Code Registry (see RFC 2817 [18]). See section 10.4.1 for the specification of this code.
本明細書はまた、IANA HTTPステータスコードレジストリ（RFC 2817 [18]参照）に新しい値を挿入します。このコードの仕様のセクション10.4.1を参照してください。
A server MAY send a delta-encoded response if all of these conditions are true:
これらの条件のすべてに該当する場合、サーバーは、デルタエンコードされたレスポンスを送信することがあります。
1. The server would be able to send a 200 (OK) response for the request.
1.サーバーは、要求のための200（OK）応答を送信することができるだろう。
2. The client's request includes an A-IM header field listing at least one delta-coding.
2.クライアントの要求は、少なくとも一つのデルタコードをリストA-IMヘッダフィールドを含んでいます。
3. The client's request includes an If-None-Match header field listing at least one valid entity tag for an instance of the Request-URI (a "base instance").
3.クライアントの要求は、Request-URI（「ベース・インスタンス」）のインスタンスのための少なくとも1個の有効なエンティティタグを一覧表示するIf-None-Matchヘッダフィールドを含みます。
A delta-encoded response:
デルタエンコードされたレスポンス：
- MUST carry a status code of 226 (IM Used).
- （使用されるIM）226のステータスコードを運ばなければなりません。
- MUST include an IM header field listing, at least, the delta-coding employed.
- 少なくとも、使用デルタ符号化、IMヘッダフィールドのリストを含まなければなりません。
- MAY include a Delta-Base header field listing the entity tag of the base-instance.
- ベース・インスタンスのエンティティタグをリストデルタベースヘッダフィールドを含んでいてもよいです。
The following new status code is defined for HTTP.
以下の新しいステータスコードは、HTTPのために定義されています。
The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. The actual current instance might not be available except by combining this response with other previous or future responses, as appropriate for the specific instance-manipulation(s). If so, the headers of the resulting instance are the result of combining the headers from the status-226 response and the other instances, following the rules in section 13.5.3 of the HTTP/1.1 specification [10].
サーバはリソースに対するGET要求を満たしており、応答は、現在のインスタンスに適用される一つまたはそれ以上のインスタンスの操作の結果を表したものです。実際の現在のインスタンスは、特定のインスタンス操作（単数または複数）に応じて、他の以前または将来の応答にこの応答を組み合わせること以外は利用できないかもしれません。もしそうであれば、得られたインスタンスのヘッダはHTTP / 1.1仕様書[10]のセクション13.5.3のルール次のステータス226の応答からヘッダと他のインスタンスを、結合の結果です。
The request MUST have included an A-IM header field listing at least one instance-manipulation. The response MUST include an Etag header field giving the entity tag of the current instance.
要求は、少なくとも一つのインスタンス操作をリストA-IMヘッダフィールドを含んでいなければなりません。応答は、現在のインスタンスのエンティティタグを与えたEtagヘッダフィールドを含まなければなりません。
A response received with a status code of 226 MAY be stored by a cache and used in reply to a subsequent request, subject to the HTTP expiration mechanism and any Cache-Control headers, and to the requirements in section 10.6.
226のステータスコードと、受信した応答は、キャッシュによって記憶され、HTTPの有効期限機構と任意のCache-Controlヘッダーを受け、その後の要求への応答に使用され、セクション10.6で要求することであってもよいです。
A response received with a status code of 226 MAY be used by a cache, in conjunction with a cache entry for the base instance, to create a cache entry for the current instance.
226のステータスコードと、受信した応答は、現在のインスタンスのキャッシュエントリを作成するために、ベース・インスタンスのキャッシュエントリに関連して、キャッシュによって使用されてもよいです。
The following headers are defined, for use as entity-headers. (Due to the terminological confusion discussed in section 3, some entity-headers are more properly associated with instances than with entities.)
以下のヘッダは、エンティティヘッダとして使用するために、定義されています。 （セクション3で説明した用語の混乱に起因する、いくつかのエンティティヘッダは、より適切エンティティとよりインスタンスに関連付けられています。）
The Delta-Base entity-header field is used in a delta-encoded response to specify the entity tag of the base instance.
デルタベースエンティティヘッダフィールドは、ベースインスタンスのエンティティタグを指定するデルタエンコードされたレスポンスに使用されます。
Delta-Base = "Delta-Base" ":" entity-tag
デルタベース=「デルタ・ベース」「：」エンティティタグ
A Delta-Base header field MUST be included in a response with an IM header that includes a delta-coding, if the request included more than one entity tag in its If-None-Match header field.
デルタベースヘッダフィールドは要求がIf-None-Matchヘッダフィールド内の複数のエンティティタグが含まれている場合、デルタ符号化を含むIMヘッダを有する応答に含まれなければなりません。
Any response with an IM header that includes a delta-coding MAY include a Delta-Base header.
デルタ符号化を含むIMヘッダを有する任意の応答は、デルタベースのヘッダを含むかもしれません。
We are not aware of other cases where a delta-encoded response MUST or SHOULD include a Delta-Base header, but we have not done an exhaustive or formal analysis. Implementors might be wise to include a Delta-Base header in every delta-encoded response.
私たちは、デルタエンコードされた応答MUST他の例認識していないか、デルタベースのヘッダを含むべきであるが、我々は徹底的または正式な分析を行っていません。実装者は、すべてのデルタ符号化された応答にデルタベースのヘッダを含めることが賢明かもしれません。
A cache or proxy that receives a delta-encoded response that lacks a Delta-base header MAY add a Delta-Base header whose value is the entity tag given in the If-None-Match field of the request (but only if that field lists exactly one entity tag).
値要求の場合、なしマッチフィールドで与えられたエンティティタグである（しかし、場合にのみ、そのフィールドリストデルタベースのヘッダを加えるかもしれデルタベースのヘッダを欠いてデルタ符号化された応答を受信し、キャッシュまたはプロキシ正確に一つのエンティティタグ）。
The IM response-header field is used to indicate the instance-manipulations, if any, that have been applied to the instance represented by the response. Typical instance manipulations include delta encoding and compression.
IMレスポンスヘッダフィールドは、応答によって表されるインスタンスに適用されていることを、もしあれば、インスタンスの操作を示すために使用されます。典型的なインスタンス操作は差分符号化と圧縮を含みます。
IM = "IM" ":" #(instance-manipulation)
IM = "IM" "" ＃（インスタンス操作）
Instance-manipulations are defined in section 10.1.
インスタンスの操作は、セクション10.1で定義されています。
As a special case, if the instance-manipulations include both range selection and at least one other non-identity instance-manipulation, the IM header field MUST be used to indicate the order in which all of these instance-manipulations, including range selection, were applied. If the IM header lists the "range" instance-manipulation, the response MUST include either a Content-Range header or a multipart/byteranges Content-Type in which each part contains a Content-Range header. (See section 10.10 for specific discussion of combining delta encoding and multipart/byteranges.)
インスタンス操作が範囲選択および少なくとも1つの他の非同一のインスタンス操作の両方を含む場合、特殊なケースとして、IMヘッダフィールドは、順序を示すために使用されなければならない範囲の選択を含む、これらのインスタンスの操作の全て、適用されました。 IMヘッダが「範囲」インスタンス操作の一覧を示した場合、応答は、Content-Rangeヘッダ又はマルチパートのいずれかを含まなければなりません/各部分がコンテンツRangeヘッダが含まれているコンテンツタイプをbyteranges。 （デルタ符号化およびマルチパート/ byterangesを組み合わせる特定の議論についてはセクション10.10を参照）。
Responses that include an IM header MUST carry a response status code of 226 (IM Used), as specified in section 10.4.1.
セクション10.4.1で指定されるようにIMヘッダを含む応答は、226の応答ステータスコード（IM使用）運ばなければなりません。
The server SHOULD omit the IM header if it would list only the "range" instance-manipulation. Such responses would normally be sent with response status code 206 (Partial Content), as specified by HTTP/1.1 [10].
それが唯一の「範囲」インスタンス操作をリストした場合、サーバは、IMヘッダを省略すべきです。 HTTP / 1.1 [10]によって指定されるように、このような応答は、通常、応答ステータスコード206（部分コンテンツ）を用いて送信されます。
Examples of the use of the IM header include:
IMヘッダの使用の例としては、
IM: vcdiff
IM：VCDIFF
This example indicates that the entity-body is a delta encoding of the instance, using the vcdiff encoding.
この例では、エンティティボディはvcdiffエンコーディングを使用して、インスタンスの差分エンコーディングであることを示しています。
IM: diffe, deflate, range
IM：diffe、収縮、範囲
This example indicates that the instance has first been delta-encoded using the diffe encoding, then the result of that has been compressed using deflate, and finally one or more ranges of that compressed encoding have been selected.
この例では、インスタンスは最初diffeエンコーディングを使用してデルタ符号化されたことを示し、その結果は、収縮用いて圧縮され、最終的にその圧縮符号化の一つ以上の範囲が選択されています。
IM: range, vcdiff
IM：範囲、VCDIFF
This example indicates that one or more ranges of the instance have been selected, and the result has then been delta encoded against identical ranges of a previous base instance.
この例では、インスタンスの一つ以上の範囲が選択されていることを示し、その結果は、前のベース・インスタンスの同じ範囲に対して符号化されたデルタとなっています。
A cache using a response received in reply to one request to reply to a subsequent request MUST follow the rules in section 10.6 if the cached response includes an IM header field.
キャッシュされた応答は、IMヘッダフィールドを含む場合、後続の要求に応答する一つの要求に対する応答で受信した応答を使用してキャッシュセクション10.6の規則に従わなければなりません。
The A-IM request-header field is similar to Accept, but restricts the instance-manipulations (section 10.1) that are acceptable in the response. As specified in section 10.5.2, a response may be the result of applying multiple instance-manipulations.
A-IMリクエストヘッダフィールドは、そのまま使用することが同様であるが、応答に許容されるインスタンスの操作（セクション10.1）を制限します。セクション10.5.2で指定されるように、応答は、複数のインスタンスの操作を適用した結果であってもよいです。
A-IM = "A-IM" ":" #( instance-manipulation [ ";" "q" "=" qvalue ] )
-IM = "A-IM" "：" ＃（インスタンス操作[ ";" "Q" "=" のqvalue]）
When an A-IM request-header field includes one or more delta-coding values, the request MUST contain an If-None-Match header field, listing one or more entity tags from prior responses for the request-URI.
A-IMリクエストヘッダフィールドは、1つまたは複数のデルタコード値が含まれている場合、リクエストはリクエストURIのための事前応答から1つ以上のエンティティタグを一覧表示、If-None-Matchヘッダフィールドを含まなければなりません。
A server tests whether an instance-manipulation (among the ones it is capable of employing) is acceptable, according to a given A-IM header field, using these rules:
（それが使用可能であるもののうち）インスタンス操作がこれらの規則を使用して、所与のA-IMヘッダフィールドに応じて、許容可能であるか否かをサーバ・テスト：
1. If the instance-manipulation is listed in the A-IM field, then it is acceptable, unless it is accompanied by a qvalue of 0. (As defined in section 3.9 of the HTTP/1.1 specification [10], a qvalue of 0 means "not acceptable.") A server MUST NOT use a non-identity instance-manipulation for a response unless the instance-manipulation is listed in an A-IM header in the request.
1.インスタンス操作がA-IMフィールドに表示されている場合はHTTP / 1.1仕様書[10]、ののqvalueのセクション3.9で定義されるように、それが0ののqvalue（伴うされていない限り、それは、許容されます0「は受け入れられない。」を意味する）インスタンス操作が要求におけるA-IMヘッダに記載されていない限り、サーバが応答するための非同一のインスタンス操作を使用してはいけません。
2. If multiple but incompatible instance-manipulations are acceptable, then the acceptable instance-manipulation with the highest non-zero qvalue is preferred.
複数が、互換性のないインスタンスの操作が許容される場合は2、最も高い非ゼロのqvalueと許容されるインスタンス操作が好ましいです。
3. The "identity" instance-manipulation is always acceptable, unless specifically refused because the A-IM field includes "identity;q=0".
「; Q = 0同一性」は、具体的にA-IMフィールドが含まれているため、拒否しない限り、前記「同一性」インスタンス操作は、常に許容されます。
If an A-IM field is present in a request, and if the server cannot send a response which is acceptable according to the A-IM header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
A-IMフィールドがリクエスト中に存在し、サーバはA-IMヘッダに従って許容される応答を送信できない場合、サーバは406（許容できない）ステータスコードとエラー応答を送信する必要がある場合。
If a response uses more than one instance-manipulation, the instance-manipulations MUST be applied in the order in which they appear in the A-IM request-header field.
応答が複数のインスタンスの操作を使用している場合、インスタンス操作は、それらがA-IMリクエストヘッダフィールドに表示される順序で適用されなければなりません。
The server's choice about whether to apply an instance-manipulation SHOULD be independent of its choice to apply any subsequent two-input instance-manipulations to the response. (Two-input instance-manipulations include delta-codings, because they take two different values as input. Compression and "range" instance-manipulations take only one input. Other instance-manipulations may be defined in the future.)
インスタンス操作を適用するかどうか、サーバーの選択は、応答に後続の二入力インスタンス操作を適用するためにその選択の独立していなければなりません。 （これらは、入力として2つの異なる値をとる。圧縮と「範囲」インスタンス操作は一つだけ入力を取るので、2入力インスタンス操作は、デルタ・コーディングを含む。他のインスタンスの操作は、将来的に定義されてもよいです。）
Note: the intent of this requirement is to prevent the server from generating a delta-encoded response that the client can only decode by first applying an instance-manipulation encoding to its cached base instance. A server implementor might wish to consider what the client would logically have in its cache, when deciding which instance-manipulations to apply prior to a delta-coding.
注：この要件の目的は、クライアントが最初にキャッシュされ、そのベースインスタンスにインスタンス操作符号化を適用することにより復号できることデルタ符号化された応答を生成するからサーバーを防止することです。サーバーの実装は、前のデルタ・コーディングに適用するインスタンスの操作を決定する際に、クライアントは、論理的に、そのキャッシュを持っているだろうかを検討したいかもしれません。
Examples:
例：
A-IM: vcdiff, gdiff
-IM：VCDIFF、GDIFF
This example means that the client will accept a delta encoding in either vcdiff or gdiff format.
この例では、クライアントがvcdiffやGDIFF形式のいずれかで、デルタエンコーディングを受け入れることを意味します。
A-IM: vcdiff, gdiff;q=0.3
-IM：vcdiff、GDIFF; Q = 0.3
This example means that the client will accept a delta encoding in either vcdiff or gdiff format, but prefers the vcdiff format.
この例では、クライアントがvcdiffやGDIFF形式のいずれかで、デルタエンコーディングを受け入れることを意味するが、vcdiff形式を好みます。
A-IM: vcdiff, diffe, gzip
-IM：vcdiff、diffe、GZIP
This example means that the client will accept a delta encoding in either vcdiff or diffe format, and will accept the output of the delta encoding compressed with gzip. It also means that the client will accept a gzip compression of the instance, without any delta encoding, because A-IM provides no way to insist that gzip be used only if diffe is used.
この例では、クライアントはvcdiff又はdiffeフォーマットのいずれかにおける差分エンコーディングを受け入れる、とgzipで圧縮された差分エンコーディングの出力を受け入れることを意味します。また、IMは、GZIPがdiffeが使用されている場合にのみ使用することを主張する方法を提供していませんので、クライアントは、任意のデルタエンコードせずに、インスタンスのgzip圧縮を受け入れることを意味します。
It is left to the server implementor to choose useful combinations of acceptable instance-manipulations (for example, following diffe by gzip is useful, but following vcdiff by gzip probably is not useful).
これは、許容できるインスタンスの操作の有用な組合せを選択するために、サーバーの実装者に任されている（gzipでdiffe以下、例えばすると便利ですが、gzipで次vcdiffはおそらく有用ではありません）。
When a client or proxy receives a 226 (IM Used) response, it MAY use this response to create a cache entry in three ways:
クライアントまたはプロキシは226（IM使用される）応答を受信すると、それは3つの方法でキャッシュエントリを作成するには、この応答を使用することがあります：
1. It MAY decode all of the instance-manipulations to recover the original instance, and store that instance in the cache. In this case, the recovered instance is stored as a status-200 response, and MUST be used in accordance with the normal HTTP caching rules.
1.これは、元のインスタンスを回復するために、インスタンスの操作のすべてをデコードし、キャッシュにそのインスタンスを格納することができます。この場合には、回収されたインスタンスは、ステータス200の応答として保存され、通常のHTTPキャッシング規則に従って使用されなければなりません。
2. It MAY decode all of the instance-manipulations except for range selection(s), and store the result in the cache. In this case, the result is stored as a status-206 response, and MUST be used in accordance with the normal HTTP caching rules for Partial Content.
2.これは、範囲選択（複数可）を除いインスタンス操作の全てを復号し、キャッシュに結果を格納することができます。この場合、結果は、ステータス206の応答として保存され、そして部分コンテンツの通常のHTTPキャッシング規則に従って使用されなければなりません。
3. It MAY store the status-226 (IM Used) response as a cache entry.
3.これは、キャッシュエントリとしてのステータス-226（IM使用される）応答を格納することができます。
A status-226 cache entry MUST NOT be used in response to a subsequent request under any of these conditions (a cache that never stores status-226 responses may ignore these tests):
ステータス226のキャッシュエントリは、これらの条件のいずれかに後続の要求に応じて使用してはいけません（これらのテストを無視できる状態-226応答を格納することがないキャッシュ）。
1. If any of the instance-manipulation values from the IM header field in the cached response do not appear in the subsequent request's A-IM header field. The comparison between the headers is done using an exact match on each instance-manipulation value including any associated imparams values (see section 10.1).
1.キャッシュされた応答におけるIMヘッダフィールドからのインスタンスの操作値のいずれかが、その後のリクエストのA-IMヘッダフィールドに表示されない場合。ヘッダ間の比較は、任意の関連imparams値（セクション10.1を参照）を含む各インスタンス操作値に正確に一致を使用して行われます。
2. If the order of instance-manipulation values appearing in the cached IM header field differs from the order of that set of instance-manipulations in the A-IM header field of the subsequent request.
2.キャッシュされたIMヘッダフィールドに現れるインスタンス操作値の順序は、後続リクエストのA-IMヘッダフィールドにインスタンス操作のセットの順序と異なる場合。
3. If the cache implementation is not aware of, or is not at least conditionally compliant with, the specification of any of the instance-manipulation values in the cached IM header field.
3.キャッシュ実装が認識しないか、または少なくとも条件に準拠していない場合、キャッシュされたIMヘッダフィールドにインスタンス操作値のいずれかの指定。
Note: This rule allows for extending the set of instance-manipulations without causing deployed cache implementations to commit errors. The specification of new instance-manipulations may include additional caching rules to improve cache-hit rates in cognizant implementations.
注：このルールは、エラーをコミットするために展開キャッシュ実装を引き起こすことなく、インスタンスの操作のセットを拡張することを可能にします。新しいインスタンスの操作の仕様は認識して実装してキャッシュヒット率を向上させるために、追加のキャッシュ・ルールを含むことができます。
4. If any of the instance-manipulation values in the cached IM header field is a delta-coding, and the cache entry includes a Delta-Base header field, and that Delta-Base entity tag is not one of the entity tags listed in an If-None-Match header field of the subsequent request.
前記キャッシュされたIMヘッダフィールドにインスタンス操作値のいずれかは、デルタ符号化であり、キャッシュ・エントリは、デルタベースのヘッダフィールドを含み、デルタベースのエンティティタグがにリストされたエンティティタグの一つではないことを場合次のリクエストのIf-None-Matchヘッダフィールド。
5. If any of the instance-manipulation values in the cached IM header field is a delta-coding, the cache entry does not include a Delta-Base header field, and the If-None-Match header field of the request that led to that cache entry does not match the If-None-Match header field of the subsequent request.
5.キャッシュされたIMヘッダフィールド内のインスタンス・操作値のいずれかがデルタコーディングをされた場合は、キャッシュエントリは、デルタベースのヘッダフィールド、およびにつながったリクエストのIf-None-Matchヘッダフィールドが含まれていません。そのキャッシュエントリは、次のリクエストのIf-None-Matchヘッダフィールドと一致していません。
If the IM header field of the cached response includes the "range" instance-manipulation, then a status-226 cache entry MUST NOT be used in response to a subsequent request if the cached response is inconsistent with the Range header field value(s) in the request, as would be the case for a cached 206 (Partial Content) response.
キャッシュされた応答のIMヘッダフィールドは、「範囲」インスタンス操作が含まれている場合、キャッシュされた応答は、Rangeヘッダフィールド値（S）と一致しない場合には、ステータス226キャッシュエントリ後続の要求に応じて使用してはいけません要求に、ASは、キャッシュ206（部分コンテンツ）応答のための場合です。
Note: we know of no existing, published formal specification for deciding if a cached status-206 response is consistent with a subsequent request. We believe that either of these conditions is sufficient:
注意：我々は、キャッシュされた状態-206応答は、後続の要求と一致している場合を決定するための既存の、公表正式な仕様を知っています。私たちは、これらの条件のいずれかが十分であると考えています。
1. The ranges specified in the headers of the request that led to the cached response are the same as specified in the headers of the subsequent request.
1.キャッシュされた応答につながったリクエストのヘッダに指定された範囲は、後続リクエストのヘッダに指定さと同じです。
2. The ranges specified in the cached response are the same as specified in the headers of the subsequent request.
2.キャッシュ応答で指定された範囲は、後続の要求のヘッダで指定さと同じです。
Further analysis might be necessary.
さらなる分析が必要になる場合があります。
The use of delta encoding with content-encoded instances adds some slight complexity. When a client (perhaps a proxy) has received a delta encoded response, either or both of that new response and a cached previous response may have non-identity content-codings. We specify rules for the server and client, to prevent situations where the client is unable to make sense of the server's response.
コンテンツエンコードされたインスタンスを持つデルタエンコーディングの使用は若干複雑になります。クライアント（おそらくプロキシ）は、差分符号化された応答を受信したときのいずれか、またはその新しい応答と非同一の内容コーディングを有していてもよく、キャッシュされた以前の応答の両方。私たちは、クライアントがサーバの応答の意味を理解することができない場所の状況を防ぐために、サーバとクライアントのための規則を指定します。
When a server generates a delta-encoded response, the list of content-codings the server uses (i.e., the value of the response's Content-Encoding header field) SHOULD be a prefix of the list of content-codings the server would have used had it not generated a delta encoding.
サーバはデルタエンコードされた応答を生成するとき、内容コーディングのリストには、サーバーが使用する（すなわち、レスポンスのContent-Encodingヘッダーフィールドの値）は、サーバが使用していた内容コーディングのリストの接頭辞であるべきである持っていましたそれは、デルタエンコーディングを生成しません。
This requirement allows a client receiving a delta-encoded response to apply the delta to a cached base instance without having to apply any content-codings during the process (although the client might, of course, be required to decode some content-codings).
この要件は、（クライアントが、当然のことながら、いくつかのコンテンツ・コーディングを復号するために必要とされるかもしれないが）プロセス中の任意の内容コーディングを適用することなく、キャッシュされたベース・インスタンスにデルタを適用するデルタ符号化された応答を受信するクライアントを可能にします。
When a client receives a delta response with one or more non-identity content codings:
クライアントは、1つまたは複数の非同一内容コーディングとデルタ応答を受信した場合：
1. If both the new (delta) response and the cached response (instance) have exactly the same set of content-codings, the client applies the delta response to the cached response without removing the content-codings from either response.
新しい（デルタ）レスポンスとキャッシュされたレスポンス（インスタンス）の両方が、内容コーディングのとまったく同じセットを持っている場合1.クライアントは、いずれかの応答から内容コーディングを削除せずにキャッシュされたレスポンスにデルタ応答を適用します。
2. If the new (delta) response and the cached response have a different set of content-codings, before applying the delta the client decodes one or more content-codings from the cached response, until the result has the same set of content-codings as the delta response.
2.新しい（デルタ）レスポンスとキャッシュされた応答は、結果がのContentの同じセットを持ってまで、クライアントは、キャッシュされた応答から1つ以上の内容コーディングをデコードデルタを適用する前に、内容コーディングの異なるセットを持っている場合デルタ応答としてコーディング。
3. If a proxy or cache is forwarding the result of applying the delta response to a cached base instance response, or later forwards this result from a cache entry, the forwarded response MUST carry the same Content-Encoding header field as the new (delta) response (and so it must be content-encoded as indicated by that header field).
3.プロキシまたはキャッシュはキャッシュエントリからのキャッシュされたベース・インスタンスの応答にデルタ応答、またはそれ以降の転送この結果を適用した結果を転送している場合、転送された応答は、新しい（デルタと同一のContent-Encodingヘッダフィールドを運ばなければなりません）、応答（そのヘッダフィールドによって示されるように、コンテンツ・エンコードされなければなりません）。
The intent of these rules (and in particular, rule #3) is that the results are always consistent with the rule that the entity tag is associated with the result of the content-coding, and that any recipient after the application of the delta-coding receives exactly the same response it would have received as a status-200 response from the origin server (without any delta-coding).
これらの規則の意図（特に、ルール＃3）は、結果は常にエンティティタグは、コンテンツ・コーディング、およびデルタの適用後にその受信者の結果と関連していることをルールと一致していることですコーディングは（どのデルタコーディングなしで）それがオリジンサーバからのステータス-200の応答として受け取っているとまったく同じ応答を受け取ります。
Suppose a client, with an empty cache, sends this request:
クライアントを仮定し、空のキャッシュで、この要求を送信します。
GET /foo.html HTTP/1.1 Host: example.com Accept-encoding: gzip
GET /foo.html HTTP / 1.1ホスト：example.comのAccept-エンコーディングを：GZIP
and the origin server responds with:
そして、オリジンサーバがで応答します。
HTTP/1.1 200 OK Date: Wed, 24 Dec 1997 14:00:00 GMT Etag: "abc" Content-encoding: gzip
HTTP / 1.1 200 OK日：水曜日、1997年12月24日午後2時00分00秒GMTのEtag： "ABC" コンテンツエンコード：gzipの
We will use the notation URI;entity-tag to denote specific instances, so this response would cause the client to store in its cache the entity GZIP(foo.html;"abc").
特定のインスタンスを示すためにエンティティタグので、この応答は、クライアントがそのキャッシュにエンティティGZIP（foo.htmlという、「ABC」）を記憶させるでしょう。私たちは、表記URIを使用します。
Then suppose that the client, a minute later, issues this conditional request:
その後、分以降のクライアント、発行する。この条件付きリクエストたとします。
GET /foo.html HTTP/1.1 Host: example.com If-none-match: "abc" Accept-encoding: gzip A-IM: vcdiff
GET /foo.html HTTP / 1.1ホスト：example.com場合は、どれもマッチ： "ABC" にAccept-エンコーディングを：gzipでA-IM：vcdiff
If the server is able to generate a delta-encoded response, it might choose one of two alternatives. The first is to compute the delta from the compressed instances (although this might not yield the most efficient coding):
サーバはデルタエンコードされた応答を生成することができるならば、それは二つの選択肢のいずれかを選択できます。最初は（これが最も効率的な符号化が得られないかもしれないが）圧縮インスタンスからのデルタを計算することです。
HTTP/1.1 226 IM Used Date: Wed, 24 Dec 1997 14:01:00 GMT Etag: "def" Delta-base: "abc" Content-encoding: gzip IM: vcdiff
HTTP / 1.1 226 IM使用される日付：水曜日、1997年12月24日午後02時01分○○秒GMTのEtag： "DEF" デルタ・ベース： "ABC" コンテンツエンコード：gzipのIM：vcdiff
The body of this response would be the result of VCDIFF_DELTA(GZIP(foo.html;"abc"), GZIP(foo.html;"def")). The client would store as a new cache entry the entity GZIP(foo.html;"def"), after recovering that entity by applying the delta to its previous cache entry.
このレスポンスのボディはVCDIFF_DELTA（; "ABC"）、GZIP（foo.htmlという、 "DEF"）GZIP（foo.htmlという）の結果であろう。その前のキャッシュエントリにデルタを適用することによって、そのエンティティを回復した後、;クライアントは、新しいキャッシュエントリとしてエンティティGZIP（「DEF」foo.htmlという）を格納します。
The server's other alternative would be to compute the delta from the uncompressed values, returning:
サーバーの他の代替は戻って、圧縮されていない値から差分を計算するために次のようになります。
HTTP/1.1 226 IM Used Date: Wed, 24 Dec 1997 14:01:00 GMT Delta-base: "abc" Etag: "ghi" IM: vcdiff
HTTP / 1.1 226 IM使用される日付：水曜日、1997年12月24日午後02時01分○○秒GMTデルタ・ベース： "ABC" のEtag： "GHI" IM：vcdiff
The body of this response would be the result of VCDIFF_DELTA(GUNZIP(GZIP(foo.html;"abc")), foo.html;"ghi"), or more simply VCDIFF_DELTA(foo.html;"abc", foo.html;"ghi"). The client would store as a new cache entry the entity foo.html;"ghi" (i.e., without any content-coding), after recovering that entity by applying the delta to its previous cache entry.
単にVCDIFF_DELTA（foo.htmlという、以上; "ABC"、FOO（ "GHI"; "ABC"））、foo.htmlというgunzipを（GZIP（foo.htmlという）このレスポンスのボディはVCDIFF_DELTAの結果であろう。 HTML; "GHI"）。クライアントは、新しいキャッシュエントリとしてエンティティfoo.htmlというを格納することになる。「GHI」（すなわち、任意のコンテンツコーディングせず）、以前のキャッシュエントリにデルタを適用することによって、そのエンティティを回収した後。
Note that the new value of foo.html (at 14:01:00 GMT) without the gzip content-coding must have a different entity tag from the compressed instance of the same underlying file.
GZIPコンテンツコーディングせずに（夜02時01分00秒GMTにおける）foo.htmlというの新しい値は、同じ基本的なファイルの圧縮されたインスタンスとは異なるエンティティタグを有していなければならないことに留意されたいです。
The client's second request might have been:
クライアントの2番目の要求があったかもしれません。
GET /foo.html HTTP/1.1
Host: example.com
If-none-match: "abc"
Accept-encoding: gzip
A-IM: diffe, gzip
The client lists gzip in both the Accept-Encoding and A-IM headers, because if the server does not support delta encoding, the client would at least like to achieve the benefits of compression (as a content-coding). However, if the server does support the diffe delta-coding, the client would like the result to be compressed, and this must be done as an instance-manipulation.
サーバーがデルタエンコーディングをサポートしていない場合、クライアントは、少なくとも（内容コーディングとして）圧縮の利益を達成したいと思いますので、クライアントのリストは、受け入れエンコードおよびA-IMヘッダの両方でgzip圧縮します。サーバはdiffeデルタ・コーディングをサポートする場合は、クライアントは、その結果を圧縮すると、これはインスタンス操作として行わなければなりませんしたいと思います。
A server that does support diffe might reply:
diffeをサポートするサーバは、返信があります
HTTP/1.1 226 IM Used Date: Wed, 24 Dec 1997 14:01:00 GMT Delta-base: "abc" Etag: "ghi" IM: diffe, gzip
HTTP / 1.1 226 IM使用される日付：水曜日、1997年12月24日午後02時01分○○秒GMTデルタ・ベース： "ABC" のEtag： "GHI" IM：diffe、GZIP
The body of this response would be the result of GZIP(DIFFE_DELTA(GUNZIP(GZIP(foo.html;"abc")), foo.html;"ghi")), or more simply GZIP(DIFFE_DELTA(foo.html;"abc", foo.html;"ghi")). Because the gzip compression is, in this case, an instance-manipulation and not a content-coding, it is not retained when the reassembled response is stored or forwarded, so the client would store as a new cache entry the entity foo.html;"ghi" (without any content-coding or compression).
このレスポンスのボディGZIPの結果であろう（DIFFE_DELTA（gunzipを（GZIP（foo.htmlという、 "ABC"））、foo.htmlという、 "GHI"））、またはより単純にGZIP（DIFFE_DELTA（foo.htmlという。」 ABC」、foo.htmlという; "GHI"））。 gzip圧縮であるため、再組み立て応答を記憶または転送されたときに、この場合、インスタンス操作はなく、コンテンツの符号化は、それが保持されないので、クライアントは、新しいキャッシュエントリエンティティfoo.htmlというとして記憶だろう。 「GHI」（任意のコンテンツ符号化または圧縮なし）。
We define two new cache-directives (see section 14.9 of RFC 2616 [10] for the specification of cache-directive).
我々は2つの新しいキャッシュ・ディレクティブを（キャッシュ・ディレクティブの仕様については、RFC 2616 [10]のセクション14.9を参照）を定義します。
The set of cache-response-directive values is augmented to include the retain directive.
キャッシュ応答指令値のセットを保持する指令を含むように拡張されます。
cache-response-directive = ... | "retain" [ "=" delta-seconds ]
キャッシュ・レスポンス・ディレクティブ= ... | 「保持」[「=」デルタ秒]
A retain directive is always a "hint" from a server to a client; it never specifies a mandatory action for the recipient.
保持ディレクティブは常にサーバからクライアントへの「ヒント」です。それは、受信者のための必須のアクションを指定することはありません。
The presence of a retain directive indicates that a delta-capable client ought to retain the instance in the response in its cache, space permitting, and ought to use the corresponding entity tag in a future request for a delta-encoded response. I.e., the server is likely to provide delta-encoded responses using the corresponding instance as a base instance. By implication, if a client has retrieved and cached several instances of a resource, some of which are marked with "retain" and some not, then there is no point in caching the instances not marked with "retain".
保持指令の存在は、デルタ対応クライアントは、そのキャッシュに応答してインスタンスを保持するべきスペース許可、およびデルタ符号化された応答のための将来の要求に対応するエンティティタグを使用するべきであることを示しています。すなわち、サーバは、ベースインスタンスとして対応するインスタンスを使用してデルタ符号化された応答を提供する可能性があります。クライアントを取得し、「保持」といくつかないでマークされているそのうちのいくつかのリソースの複数のインスタンスを、キャッシュされている場合は暗に、その後、「保持」とマークされていないインスタンスをキャッシュしても意味がありません。
If the retain directive includes a delta-seconds value, then the server is likely to stop using the corresponding instance as a base instance after the specified number of seconds. A client ought not use the corresponding entity tag in a future request for a delta-encoded response after that interval ends. The interval is measured from the time that the response is generated, so a client ought to include the response's Age in its calculations.
保持指令がデルタ秒の値が含まれている場合、サーバは指定した秒数後のベースインスタンスとして対応するインスタンスの使用を停止する可能性があります。その間隔が終了した後、クライアントは、デルタ符号化された応答のために、将来の要求に対応するエンティティタグを使用しないはずです。間隔は、応答が生成された時点から測定されるので、クライアントは、その計算に応答者の年齢が含まれるべきです。
If the retain directive includes a delta-seconds value of zero, a client SHOULD NOT use the corresponding entity tag in a future request for a delta-encoded response.
保持指令がゼロのデルタ秒の値が含まれている場合、クライアントは、デルタ符号化された応答のための将来の要求に対応するエンティティタグを使用しないでください。
Note: We recommend that server implementors consider the bandwidth implications of sending the "retain=0" directive to clients or proxies that might not have the ability to make use of it.
注意：私たちは、サーバーの実装者は、それを利用する能力を持っていない可能性があり、クライアントやプロキシを「= 0を保持」ディレクティブを送信する帯域幅への影響を検討することをお勧めします。
The set of cache-response-directive values is augmented to include the im directive.
キャッシュ・レスポンス・ディレクティブの値のセットは、イムディレクティブを含めるように強化されています。
cache-response-directive = ... | "im"
キャッシュ・レスポンス・ディレクティブ= ... | "私は"
A cache that complies with the specification for the IM header, the A-IM header, and the 226 response-status code SHOULD ignore a no-store cache-directive if an im directive is present in the same response. All other implementations MUST ignore the im directive (i.e., MUST observe a no-store directive, if present).
IMディレクティブは同じ応答中に存在する場合IMヘッダ、A-IMヘッダ、及び226応答ステータスコードの仕様に準拠したキャッシュは、無店舗キャッシュ指令を無視すべきです。他のすべての実装は、（存在する場合すなわち、非ストア命令を遵守しなければならない）、IM指令を無視しなければなりません。
The application of data compression to the diffe and gdiff delta codings has been shown to greatly reduce the size of the resulting message bodies, in many cases. (The vcdiff coding, on the other hand, is inherently compressed and does not benefit from further compression.) Therefore, it is strongly recommended that implementations that support the diffe and/or gdiff delta codings also support the gzip and/or deflate compression codings. (The deflate coding provides a more compact result.) However, this is not a requirement for the use of delta encoding, primarily because the CPU-time costs associated with compression and decompression may be excessive in some environments.
diffeとGDIFFデルタコーディングへのデータ圧縮の適用は、多くの場合、大幅得メッセージボディのサイズを減少させることが示されています。 （vcdiff符号化は、一方で、本質的に圧縮されてさらに圧縮の恩恵を受けない。）したがって、diffeをサポートする実装及び/又はGDIFFデルタコーディングもGZIPをサポート及び/又は圧縮コーディングを収縮させることが強く推奨されています。 （DEFLATE符号化は、よりコンパクトな結果を提供する。）しかし、これは圧縮および圧縮解除に関連したCPU時間のコストは、いくつかの環境において過大とすることができる主な理由、デルタ符号化を使用するための要件ではありません。
A client that supports both delta encoding and compression as instance-manipulations signals this by, for example
例えば、このことにより、インスタンス操作信号として両方のデルタ符号化および圧縮をサポートするクライアント
A-IM: diffe, deflate
-IM：diffe、デフレート
The ordering rule stated in section 10.5.3 requires, if the server uses both instance-manipulations in the response, that compression be applied to the result of the delta encoding, rather than vice versa. I.e., the response in this case would include
セクション10.5.3に記載された順序付け規則は、サーバが応答して、両方のインスタンスの操作を使用している場合、その圧縮はデルタ符号化の結果ではなく、その逆に適用することが、必要です。すなわち、この場合の応答が含まれます
IM: diffe, deflate
IM：diffe、デフレート
Note that a client might accept compression either as a content-coding or as an instance-manipulation. For example:
クライアントは、コンテンツの符号化として、あるいはインスタンス操作のいずれかとして圧縮を受け入れる可能性があることに注意してください。例えば：
Accept-Encoding: gzip A-IM: gzip, gdiff
受け入れエンコード：gzipのA-IM：GZIP、GDIFF
In this example, the server may apply the gzip compression, either as a content-coding or as an instance-manipulation, before delta encoding. Remember that the entity tag is assigned after content-coding but before instance-manipulation, so this choice does affect the semantics of delta encoding.
この例では、サーバは、デルタ符号化の前に、コンテンツの符号化として、またはインスタンス操作のいずれかと、gzip圧縮を適用することができます。エンティティタグは、コンテンツ・コーディングの後でインスタンス操作の前に割り当てられているので、この選択は、デルタエンコーディングのセマンティクスに影響を与えないされていることを覚えておいてください。
A client may request multiple, non-contiguous byte ranges in a single request. The server's response uses the "multipart/byteranges" media type (section 19.2 of [10]) to convey multiple ranges in a response. If a multipart/byteranges response is delta encoded (i.e, uses a delta-coding as an instance-manipulation), the delta-related headers are associated with the entire response, not with the individual parts. (This is because there is only one base instance and one current instance involved.) A delta-encoded response with multiple ranges MUST use the same delta-coding for all of the ranges.
クライアントは、単一の要求で複数の非連続バイト範囲を要求することができます。サーバの応答は、応答して複数の範囲を伝えるために、「マルチパート/ byteranges」メディアタイプ（[10]のセクション19.2）を使用します。マルチパート/ byteranges応答デルタ符号化される場合、デルタ関連ヘッダーがない個々の部分で、全体の応答と関連している（すなわちは、デルタ符号化インスタンス操作などを使用します）。 （一つだけベースインスタンスと関与する1つの現在のインスタンスがあるからである。）は、複数の範囲を有するデルタ符号化された応答は、範囲のすべてについて同じデルタ符号化を使用しなければなりません。
If a server chooses to use a delta encoding for a multipart/byteranges response, it MUST generate a response in accordance with the following rules.
サーバは、マルチパート/ byteranges応答のデルタ符号化を使用することを選択した場合、それは次のルールに従って、応答を生成しなければなりません。
When a multipart/byteranges response uses a delta-coding prior to a range selection, the A-IM and IM header fields list the delta-coding before the "range" literal. (Recall that this is the approach taken to obtain a partial response after a premature termination of a message transmission.) The server firsts generates a sequence of bytes representing the difference (delta) between the base instance and the current instance, then selects the specified ranges of bytes, and transmits each such range in a part of the multipart/byteranges media type.
マルチは/応答はデルタ符号化前に範囲選択に、A-IMおよびIMヘッダフィールドはリテラル「範囲」の前にデルタ符号化を一覧使用byteranges場合。 （これは、メッセージ送信の早期終了後に部分的応答を得るために取られたアプローチであることを想起されたい。）サーバ初ベースインスタンスと現在のインスタンスとの間の差（デルタ）を表すバイトのシーケンスを生成し、その後、指定された選択バイトの範囲、及びマルチパート/ byterangesメディアタイプの一部にこのような各範囲を送信します。
When a multipart/byteranges response uses a delta-coding after a range selection, the A-IM and IM header fields list the delta-coding after the "range" literal. (Recall that this is the approach taken to obtain an updated version just of selected sections of an instance.) The server first selects the specified ranges from the current instance, and also selects the same specified ranges from the base instance. (Some of these selected ranges might be the empty sequence, if the instance is not long enough.) The server then generates the individual differences (deltas) between the pairs of ranges, and transmits each such difference in a part of the multipart/byteranges media type.
マルチパート/レスポンスが範囲選択後デルタ符号化を使用byteranges場合、A-IMおよびIMヘッダフィールドは、「範囲」の後にデルタ符号化はリテラルリスト。 （これは単にインスタンスの選択されたセクションの更新バージョンを取得するために取られたアプローチであることを想起されたい。）サーバは、最初の現在のインスタンスから指定された範囲を選択し、また、ベースインスタンスからの同一の特定の範囲を選択します。 （インスタンスが十分に長くない場合は、これらの選択された範囲のいくつかは、空のシーケンスであるかもしれない。）その後、サーバは、範囲の対の間の個体差（デルタ）を生成し、マルチパート/ byterangesの一部に各そのような差を送信しますメディアタイプ。
11 Quantifying the protocol overhead
11プロトコルオーバーヘッドを定量化
The proposed protocol changes increase the size of the HTTP message headers slightly. In the simplest case, a conditional request (i.e., one for a URI for which the client already has a cache entry) would include one more header, e.g.:
提案されたプロトコルの変更はわずかにHTTPメッセージヘッダのサイズを増加させます。最も単純なケースでは、条件付きの要求（即ち、クライアントが既にキャッシュエントリを持っているURIのための1つ）は例えば、1つの以上のヘッダを含むであろう：
A-IM:vcdiff
-IM：VCDIFF
This is about 13 extra bytes. A recent study [23] reports mean request sizes from two different traces of 281 and 306 bytes, so the net increase in request size would be between 4% and 5%.
これは、約13余分なバイトです。最近の研究[23]レポートは、281と306バイトの二つの異なるトレースからの要求サイズを意味するので、要求サイズの正味の増加が4％と5％の間であろう。
Because a client must have an existing cache entry to use as a base for a delta-encoded response, it would never send "A-IM: vcdiff" (or listing other delta encoding formats) for its unconditional requests. The same study showed that at least 46% of the requests in lengthy traces were for URLs not seen previously in the trace; this means that no more than about half of typical client requests could be conditional (and the actual fraction is likely to be smaller, given the finite size of real caches).
その無条件の要求のために（または他のデルタエンコーディング形式をリストアップ）：クライアントはデルタエンコードされたレスポンスのためのベースとして使用する既存のキャッシュエントリを持たなければならないので、それは「vcdiff A-IM」を送信することはありません。同じ研究は、長いトレースでの要求の少なくとも46％が、トレースで以前に見たことがないURLのことを示しました。これは、典型的なクライアント要求のこれ以上の約半数は、条件付き可能性があることを意味します（実際の割合は、実際のキャッシュの有限の大きさを考えると、より小さくなる可能性があります）。
The study also showed that 64% of the responses in a lengthy trace were for image content-types (GIF and JPEG). As noted in section 6, we do not currently know of a delta-encoding format suitable for such image types. Unless a client did support such a delta-encoding format, it would presumably not ask for a delta when making a conditional request for image content-types.
研究はまた、長いトレースでの回答の64％は、画像コンテンツ・タイプ（GIFやJPEG）のためであることを示しました。セクション6で述べたように、我々は、現在、このような画像の種類に適したデルタ符号化フォーマットを知りません。クライアントは、このようなデルタエンコーディング形式のサポートをした場合を除き、画像コンテンツ・タイプのための条件付きリクエストを作るとき、それはおそらく、デルタのために質問しないでしょう。
Taken together, these factors suggest that the mean increase in request header size would be much less than 5%, and probably below 1%.
まとめると、これらの要因は、リクエストヘッダのサイズの平均増加ははるかに少ない5％未満、およびおそらく1％以下であることを示唆しています。
Delta-encoded responses carry slightly longer headers. In the simplest case, a response carries one more header, e.g.:
デルタエンコードされた応答が少し長いヘッダを運びます。最も単純なケースでは、応答は、例えば、1つの以上のヘッダを運び.:
IM:vcdiff
IM：VCDIFF
This is about 11 bytes. Other headers (such as "Delta-Base") might also be included. However, none of these extra headers would be included except in cases where a delta encoding is actually employed, and the sender of the response can avoid sending a delta encoding if this results in a net increase in response size. Thus, a delta-encoded response should never be larger than a regular response for the same request.
これは、約11バイトです。 （例えば、「デルタ・ベース」など）その他のヘッダーも含まれている場合があります。しかし、これらの余分なヘッダのどれもデルタエンコーディングが実際に採用されている場合を除いて含まれないであろう、と応答の送信者は、これが応答サイズの純増加につながる場合、デルタエンコーディングを送るのを避けることができます。したがって、デルタエンコードされたレスポンスは、同じ要求のための定期的な応答よりも大きくすることはありません。
Simulations suggest that, when delta encoding pays off at all, it saves several thousand bytes [23]. Thus, adding a few dozen bytes to the response headers should almost never obviate the savings in the message-body size.
シミュレーションは、デルタエンコーディングが全く報わとき、それは数千バイト[23]を保存し、ことを示唆しています。このように、レスポンスヘッダに数十バイトを追加するとメッセージボディのサイズに貯蓄を未然に防ぐことはほとんどないはずです。
Finally, the use of the "retain" Cache-Control directive might cause some additional overhead. Some server heuristics might be successful in limiting the use of these headers to situations where they would probably optimize future responses. Neither of these headers is necessary for the simpler uses of delta encoding.
最後に、「保持」のCache-Controlディレクティブを使用すると、いくつかの追加のオーバーヘッドが発生する可能性があります。一部のサーバーヒューリスティックは、彼らはおそらく将来の応答を最適化することになる状況にこれらのヘッダの使用を制限することに成功している可能性があります。これらのヘッダのどちらも、デルタエンコーディングの単純な用途のために必要です。
12 Security Considerations
12のセキュリティの考慮事項
We are not aware of any aspects of the basic delta encoding mechanism that affect the existing security considerations for the HTTP/1.1 protocol.
私たちは、HTTP / 1.1プロトコルのための既存のセキュリティの考慮事項に影響を与える基本的なデルタエンコーディングメカニズムのいずれかの側面を認識していません。
13 Acknowledgements
13の謝辞
Phong Vo has provided a great deal of guidance in the choice of delta encoding algorithms and formats. Issac Goldstand and Mike Dahlin provided a number of useful comments on the specification. Dave Kristol suggested many textual corrections.
フォンVoはデルタ符号化アルゴリズムとフォーマットの選択の指針の多くを提供してきました。アイザックGoldstandとマイクダーリンは仕様上の有益なコメントの数を提供します。デイブ・クリストルは、多くのテキストの修正を提案しました。
14 Intellectual Property Rights
14の知的財産権
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights, at <http://www.ietf.org/ipr.html>.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、<http://www.ietf.org/ipr.html>で、要求された権利のオンラインリストを参照してください。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手順に関する情報は、11の出版物のために利用可能となる権利の主張のコピーやライセンスの保証が利用できるようにするBCPで見つかった、または試みの結果することができますIETF事務局から入手することができます実装者またはこの仕様のユーザーによる、このような所有権の使用のための一般的なライセンスまたは許可を取得するために作られました。
15 References
15の参考文献
1. Gaurav Banga, Fred Douglis, and Michael Rabinovich. Optimistic Deltas for WWW Latency Reduction. Proc. 1997 USENIX Technical Conference, Anaheim, CA, January, 1997, pp. 289-303.
1.のGauravバンガ、フレッドDouglis、そしてマイケルRabinovich。 WWW待ち時間削減のための楽観デルタ。 PROC。 1997 USENIX技術会議、アナハイム、CA、1997年1月、頁289から303まで。
2. Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2.バーナーズ=リー、T.、フィールディング、R.、およびH. Frystyk、 "ハイパーテキスト転送プロトコル - HTTP / 1.0"、RFC 1945、1996年5月。
3. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
3.ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
4. Edith Cohen, Balachander Krishnamurthy, and Jennifer Rexford. Improving End-to-End Performance of the Web Using Server Volumes and Proxy Filters. Proc. SIGCOMM '98, September, 1998, pp. 241- 253.
4.エディスコーエン、Balachander Krishnamurthy、そしてジェニファー・レックスフォード。サーバーボリュームとプロキシフィルタを使用したWebのエンドツーエンドのパフォーマンスを向上させます。 PROC。 SIGCOMM '98、1998年9月、頁。241- 253。
5. Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
5.ドイツ、P.、 "GZIPファイル形式の仕様バージョン4.3"、RFC 1952、1996年5月。
6. Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
6.ドイツ、P.、 "DEFLATE圧縮データフォーマット仕様バージョン1.3"、RFC 1951、1996年5月。
7. Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
7.ドイツ、P.及びJ-L。 Gailly氏、 "ZLIB圧縮データフォーマット仕様バージョン3.3"、RFC 1950、1996年5月。
8. Fred Douglis, Anja Feldmann, Balachander Krishnamurthy, and Jeffrey Mogul. Rate of Change and Other Metrics: a Live Study of the World Wide Web. Proc. Symposium on Internet Technologies and Systems, USENIX, Monterey, CA, December, 1997, pp. 147-158.
8.フレッドDouglis、アンジャ・フェルドマン、Balachander Krishnamurthy、およびジェフリー・モーグル。変更およびその他のメトリックの割合：ワールド・ワイド・ウェブのライブ研究。 PROC。インターネット技術・システム、USENIX、モントレー、カリフォルニア州、1997年12月、頁147-158シンポジウム。
9. Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
9.フィールディング、R.、ゲティス、J.、ムガール人、J.、ニールセン、H.、およびT.バーナーズ=リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2068、1997年1月。
10. Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
10.フィールディング、R.、ゲティス、J.、モーグル、J.、ニールセン、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616年、1999年6月。
11. Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Luotonen, L. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authnetication", RFC 2617, June 1999.
11.フランク、J.、ハラム・ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.、Luotonen、L.およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセスAuthnetication"、RFC 2617年、1999年6月。
12. Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
12.フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
13. Arthur van Hoff, John Giannandrea, Mark Hapner, Steve Carter, and Milo Medin. The HTTP Distribution and Replication Protocol. Technical Report NOTE-DRP, World Wide Web Consortium, August, 1997.
13.アーサー・バン・ホフ、ジョンGiannandrea、マーク・Hapner、スティーブ・カーター、そしてミロメジン。 HTTPの配布とレプリケーションプロトコル。テクニカルレポート注-DRP、ワールドワイドウェブコンソーシアム、1997年8月。
14. Arthur van Hoff and Jonathan Payne. Generic Diff Format Specification. Technical Report NOTE-GDIFF, World Wide Web Consortium, August, 1997.
14.アーサー・バン・ホフとジョナサン・ペイン。一般的な差分フォーマット仕様。テクニカルレポートNOTE-GDIFF、ワールドワイドウェブコンソーシアム、1997年8月。
15. Barron C. Housel and David B. Lindquist. WebExpress: A System for Optimizing Web Browsing in a Wireless Environment. Proc. 2nd Annual Intl. Conf. on Mobile Computing and Networking, ACM, Rye, New York, November, 1996, pp. 108-116.
15.バロンC. HouselとDavid B.リンドクイスト。 WebExpress：ワイヤレス環境でのWebブラウジングを最適化するためのシステム。 PROC。第2回国際空港。 confに。モバイルコンピューティングとネットワーキング、ACM、ライ、ニューヨーク、11月、1996年、頁108から116に。
16. James J. Hunt, Kiem-Phong Vo, and Walter F. Tichy. An Empirical Study of Delta Algorithms. IEEE Soft. Config. and Maint. Workshop, 1996.
16.ジェームスJ.ハント、キエム・フォン電圧Vo、およびウォルター・F・ティッチー。デルタアルゴリズムの実証的研究。 IEEEソフト。コンフィグ。そしてメイント。ワークショップ、1996年。
17. Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
17.ヤコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
18. Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
18. Khare、R.とS.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。
19. David G. Korn and Kiem-Phong Vo. A Generic Differencing and Compression Data Format. Technical Report HA1630000-021899-02TM, AT&T Labs - Research, February, 1999.
19.デビッドG. Kornシェルとキエム・フォンVoと。一般的な差分と圧縮データフォーマット。テクニカルレポートHA1630000-021899-02TM、AT＆T研究所 - 研究、1999年2月。
20. Korn, D. and K. Vo, "The VCDIFF Generic Differencing and Compression Data Format", Work in Progress.
20. Kornシェル、D.及びK. Voは、「VCDIFFジェネリック差分と圧縮データフォーマット」が進行中で働いています。
21. Merriam-Webster. Webster's Seventh New Collegiate Dictionary. G. & C. Merriam Co., Springfield, MA, 1963.
21.メリアム・ウェブスター。ウェブスターの第七新カレッジ英英辞典。 G.＆C.メリアム（株）、スプリングフィールド、MA、1963。
22. Jeffrey C. Mogul. Hinted caching in the Web. Proc. Seventh ACM SIGOPS European Workshop, Connemara, Ireland, September, 1996, pp. 103-108.
22.ジェフリーC.モーグル。ウェブでキャッシングを示唆しました。 PROC。セブンスACM SIGOPSヨーロッパのワークショップ、コネマラ、アイルランド、1996年9月、頁103-108。
23. Jeffrey C. Mogul, Fred Douglis, Anja Feldmann, and Balachander Krishnamurthy. Potential benefits of delta encoding and data compression for HTTP. Research Report 97/4, DECWRL, July, 1997.
23.ジェフリーC.モーグル、フレッドDouglis、アンジャ・フェルドマン、およびBalachander Krishnamurthy。デルタエンコーディングおよびHTTPのためのデータ圧縮の潜在的な利点。研究報告書4分の97、DECWRL、7月、1997。
24. Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 3230, January 2002.
24.ムガール人、J.とA.バンホフ、 "HTTPでインスタンスダイジェスト"、RFC 3230、2002年1月。
25. Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
25. Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
26. The Open Group. The Single UNIX Specification, Version 2 - 6 Vol Set for UNIX 98. Document number T912, The Open Group, February, 1997.
26. Open Groupの。シングルUNIX仕様、バージョン2 - UNIX 98.文書番号T912、Open Groupの2月、1997年6巻セット。
27. W. Tichy. "RCS - A System For Version Control". Software - Practice and Experience 15, 7 (July 1985), 637-654.
27 W. Tichy。 「RCS - バージョン管理のためのシステム」。ソフトウェア - 実践と経験15、7（1985年7月）、637から654まで。
28. Andrew Tridgell and Paul Mackerras. The rsync algorithm. Technical Report TR-CS-96-05, Department of Computer Science, Australian National University, June, 1996.
28.アンドリュー・トリジェル、ポール・マッケラス。 rsyncのアルゴリズム。テクニカルレポートTR-CS-96から05、コンピュータサイエンス学部、オーストラリア国立大学、1996年6月。
29. Stephen Williams. Personal communication. http://ei.cs.vt.edu/~williams/DIFF/prelim.html.
29.スティーブン・ウィリアムズ。個人的なコミュニケーション。 http://ei.cs.vt.edu/~williams/DIFF/prelim.html。
30. Stephen Williams, Marc Abrams, Charles R. Standridge, Ghaleb Abdulla, and Edward A. Fox. Removal Policies in Network Caches for World-Wide Web Documents. Proc. SIGCOMM '96, Stanford, CA, August, 1996, pp. 293-305.
30スティーブン・ウィリアムズ、マーク・エイブラムス、チャールズ・R. Standridge、Ghalebアブドゥッラ、エドワード・A.フォックス。ワールド・ワイド・ウェブドキュメントのためのネットワークキャッシュ内の削除方針。 PROC。 SIGCOMM '96、スタンフォード大学、カリフォルニア州、1996年8月、頁293から305まで。
16 Authors' addresses
16本の著者のアドレス
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, U.S.A.
ジェフリーC.モーグル西研究所コンパックコンピュータ株式会社250大学アベニューパロアルト、カリフォルニア、94305、U.S.A.
Phone: 1 650 617 3304 (email preferred) EMail: JeffMogul@acm.org
電話番号：1 650 617 3304（電子メール優先）メール：JeffMogul@acm.org
Balachander Krishnamurthy AT&T Labs - Research 180 Park Ave, Room D-229 Florham Park, NJ 07932-0971, U.S.A.
Balachander Krishnamurthy AT＆T研究所 - 研究180パークアベニュー、ルームD-229フローラムパーク、ニュージャージー州07932から0971、U.S.A.
EMail: bala@research.att.com
メールアドレス：bala@research.att.com
Fred Douglis AT&T Labs - Research 180 Park Ave, Room B-137 Florham Park, NJ 07932-0971, U.S.A.
フレッドDouglis AT＆T研究所 - 研究180パークアベニュー、ルームB-137フローラムパーク、ニュージャージー州07932から0971、U.S.A.
Phone: 1 973 360-8775 EMail: douglis@research.att.com
電話番号：1 973 360-8775 Eメール：douglis@research.att.com
Anja Feldmann University of Saarbruecken, Germany, Computer Science Department Im Stadtwald, Geb. 36.1, Zimmer 310 D-66123 Saarbruecken, Germany
アンジャ・フェルドマンザールブリュッケン、ドイツの大学、市内の森林の中、コンピュータサイエンス学部、36.1を構築し、部屋310 66123ザールブリュッケン、ドイツ
EMail: anja@cs.uni-sb.de
メールアドレス：anja@cs.uni-sb.de
Yaron Y. Goland
ヤロンY. Goland
Email: yaron@goland.org
メール：yaron@goland.org
Arthur van Hoff Marimba, Inc. 440 Clyde Avenue Mountain View, CA 94043, U.S.A.
アーサー・バン・ホフマリンバ、Inc.の440クライドアベニューマウンテンビュー、CA 94043、U.S.A.
Phone: 1 650 930 5283 EMail: avh@marimba.com
電話番号：1 650 930 5283 Eメール：avh@marimba.com
Daniel M. Hellerstein Economic Research Service, USDA 1909 Franwall Ave, Wheaton MD 20902
ダニエル・M. Hellerstein経済研究サービス、USDA 1909 Franwallアベニュー、ウィートンMD 20902
Phone: 1 202 694-5613 or 1 301 649-4728 EMail: danielh@crosslink.net or webmaster@srehttp.org
電話：1 202 694-5613または1 301 649-4728 Eメール：danielh@crosslink.net又はwebmaster@srehttp.org
17 Full Copyright Statement
17完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。