[要約] RFC 3229は、HTTPでのデルタエンコーディングに関する仕様であり、変更された部分のみを転送することで帯域幅を節約することを目的としています。
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
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.
Copyright（c）The Internet Society（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（HyperText Transport Protocol）要求は、クライアントがすでにキャッシュエントリを持っているリソースのわずかに変更されたインスタンスの取得を引き起こします。調査によると、このような変更更新が頻繁に行われ、通常、変更は実際のエンティティよりもはるかに小さいことが示されています。そのような場合、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.
World Wide Webは分散システムであるため、検索の遅延を減らすためにキャッシュの恩恵を受けることがよくあります。インターネットやその他の広い地域のネットワークを介した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リソースは時間とともに変化するため、実用的なキャッシングアプローチには、古い情報をユーザーに提示しないように、コヒーレンシーメカニズムを含める必要があります。もともと、HyperText Transfer Protocol（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]では、サーバーは「ラスト変更された」タイムスタンプを応答して提供する場合があります。クライアントがこの応答をキャッシュエントリに保存し、その後応答を再利用することを望む場合、そのタイムスタンプを含む「ifmodified-since」フィールドでリクエストメッセージを送信する場合があります。これは条件付き検索として知られています。条件付きリクエストを受信すると、サーバーは完全な応答で返信するか、リソースが変更されていない場合は、クライアントのキャッシュエントリがまだ有効であることを示す略式の返信を送信する場合があります。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.
ただし、Common Senseは、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.
デルタは、クライアントやプロキシキャッシュからできるだけ多くの利益を絞る方法と考えることができます。応答全体を「キャッシュライン」として扱うのではなく、Deltasを使用すると、キャッシュされた応答の任意の部分を交換可能なユニットとして扱い、変更されていないピースの転送を避けることができます。
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ビデオ圧縮標準は、時折イメージフレームを伝達しますが、送信されたフレームのほとんどは、隣接するフレームからの変更として（単純化しすぎるように）エンコードされています。ソフトウェアバージョン制御用のSCCおよびRCS [27]システムは、中間バージョンをデルタとして表しています。SCCは元のバージョンで始まり、フォワードデルタを使用して後続のバージョンをエンコードしますが、RCSは以前のバージョンを後継者からのリバースデルタとしてエンコードします。Slow Links [17]にIPおよびTCPヘッダーを圧縮するためのJacobsonの手法は、巧妙で高度に専門化された形式のデルタエンコーディングを使用しています。
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キャッシングの開発がやや偶然であったため、Deltaエンコードを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.
[変更されていない]応答）。サーバー側のプロキシのみがキャッシュコピーを持っている場合、サーバー側のプロキシが独自のキャッシュエントリを検証した場合、それは楽観的に（おそらく古い）コピーをクライアント側のプロキシに送信することがあります（必要に応じて）デルタが続きます。Origin Server。Deltaエンコーディングとは異なり、楽観的なデルタの使用は、Origin Serverからの「変更されていない」応答を予測することでレイテンシを改善するために、ネットワーク上で送信されるバイト数を実際に増やします。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.
Mogul et al。[23]は、2つの異なるサイトで、HTTPメッセージの完全な内容の長いトレースを収集し、デルタエンコードされた応答の潜在的な利点を定量化しました。彼らは、DeltaエンコードがHTTPコンテンツタイプの重要なサブセットに対して応答サイズと応答遅延の顕著な改善を提供できることを示しました。彼らは、一連のHTTP拡張機能を提案しましたが、仕様に必要な詳細レベルはありませんでした。ダグリス等[8]は、同じ完全なコンテンツトレースのセットを使用して、リソースがWebで変化するレートを定量化しました。
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.
Marimba、Netscape、Sun、Novell、および自宅でW3Cに提案されたHTTP分布および複製プロトコル（DRP）は、HTTPの「データの効率的な複製」をサポートするために、HTTPの新機能のコレクションを提供することを目指しています[13]。DRP提案の1つの側面は、「差動ダウンロード」の使用です。これは、本質的にデルタエンコーディングの形式です。元の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とMackerras [28]は、デルタエンコーディングに似た何かを達成する「rsync」アルゴリズムについて説明しています。RSYNCでは、クライアントは一連の固定サイズのブロックへのキャッシュエントリを破壊し、各ブロックのダイジェスト値を計算し、リクエストの一部として一連のダイジェスト値をサーバーに送信します。Origin Serverは同じブロックベースの計算を行い、Digest値が異なるブロックのみを返します。このドキュメントで説明した「インスタンス操作」フレームワークを使用して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応答の平均サイズを削減し、それによりレイテンシとネットワーク利用を改善します。
2. Avoid any extra network round trips.
2. 追加のネットワークラウンドトリップを避けてください。
3. Minimize the amount of per-request and per-response overheads.
3. リクエストごとと応答ごとのオーバーヘッドの量を最小限に抑えます。
4. Support a variety of encoding algorithms and formats.
4. さまざまなエンコードアルゴリズムと形式をサポートします。
5. Interoperate with HTTP/1.0 and HTTP/1.1.
5. HTTP/1.0およびHTTP/1.1と相互運用します。
6. Be fully optional for clients, proxies, and servers.
6. クライアント、プロキシ、およびサーバーに完全にオプションになります。
7. Allow moderately simple implementations.
7. 適度に簡単な実装を許可します。
The goals do not include:
目標には以下が含まれません。
- Reducing the number of HTTP requests sent to an origin server.
- 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.
この仕様には、プットリクエストの本体にエンコードするデルタの使用を具体的に排除するものはありません。ただし、現在、クライアントがサーバーがそのようなメッセージを解釈できるかどうかを発見するメカニズムは現在存在しないため、使用方法を指定しようとしません。
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定義のヘッダーフィールドとメッセージの内容またはマルチパートエンティティの本体内の部分の1つを指すものと定義しています。
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仕様には、「指定されたリソースの選択されたバリアントの現在の時間に応答して返される値」を説明する用語はありません。これは、この概念が必要な場所での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つの異なる応答メッセージには同じエンティティタグが含まれる場合がありますが、リソースの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クライアントの範囲は、インスタンス値全体ではなく、インスタンスの1つ以上のサブレンジをサーバーに返すことを要求する場合があります。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.
クライアントは、「受け入れエンコード」ヘッダーを送信することにより、コンテンツコーディングを受け取る意欲を示し、理解しているコンテンツコーディングのセットをリストします。オプションで、どのコンテンツコーディングが好むかに関する情報を含めることができます。サーバーが非アイデンティティコンテンツコーディングを使用する場合、応答に「コンテンツエンコード」ヘッダーフィールドが含まれ、これらのコンテンツコーディングをアプリケーションの順にリストします。
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.
このドキュメントでは、インスタンス操作の使用をサポートするために、新しいオプションのメッセージヘッダーを追加します。クライアントは、「A-IM」ヘッダーを送信することにより、インスタンス操作を受信する意欲を示します（「受け入れエンコード」ヘッダーに類似した「A-IM」ヘッダー（「受け入れの操作」が長すぎます）を送信します。。同様に、サーバーは、「IM」ヘッダーを使用して適用した一連のインスタンスマニキュメントをリストします。
One must understand the relationship between these transformations in order to see how delta encoding applies to HTTP responses.
Deltaエンコードが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. この時点で、サーバーはインスタンスに非アイデンティティコンテンツコーディングを適用するか、その生成に固有のものであった可能性があります。これにより、コンテンツをコードするヘッダーも生成されます。
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つのステップの結果は、インスタンスです。インスタンスには、ボディ（おそらく空）とおそらくいくつかのインスタンスヘッダーが含まれます。エンティティタグは、もしあれば、この時点で割り当てられます。つまり、エンティティタグは、エンティティではなくインスタンスに関連付けられています。
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. サーバーは、インスタンス操作を適用する場合があります。たとえば、要求に範囲ヘッダーが含まれている場合、サーバーはオプションで、元のヘッダーセット、コンテンツレンジヘッダー、および（おそらくエンコードされた）本体からの適切な範囲で構成される範囲応答を生成する場合があります。デルタエンコーディングはインスタンスマニキュベーションであり、この段階で計算されます。
6. The result of the fifth step becomes the entity, consisting of entity headers and an entity body.
6. 5番目のステップの結果は、エンティティヘッダーとエンティティボディで構成されるエンティティになります。
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仕様[10]のセクション14.13では、「コンテンツレングスエンティティヘッダーフィールドはエンティティボディのサイズを示しています」と述べています。言い換えれば、コンテンツの長さは、インスタンスやバリアントではなく、エンティティの長さを測定します。たとえば、メッセージがデルタエンコーディングの場合、コンテンツレングスは、現在のインスタンスの長さではなく、デルタエンコードの長さを与えます。
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
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. メッセージ送信の早期終了後に部分的な応答を完了します。
2. to obtain just selected sections of an instance.
2. インスタンスの選択したセクションのみを取得します。
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).
範囲の最初の使用では、デルタエンコード後に適用する必要があります。これは、意図した使用は、デルタエンコードされたインスタンスの無傷のコピーを回復することであるためです。範囲の2番目の使用では、デルタエンコードの前に適用する必要があります。それ以外の場合は、範囲要求で指定されたオフセットは意味がありません（クライアントは一般に、サーバーのデルタがマップインスタンスバイトオフセットをエンティティバイトオフセットにどのようにオフセットするかを知ることができません）。
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.
したがって、クライアントが2つ以上のインスタンス操作を適用する順序を指定できるようにするメカニズムが必要です。これは、「A-IM」ヘッダーの仕様の一部として簡単に提供されます（セクション10.5.3を参照）。ここでは、サーバーが「A-IM」ヘッダーにリストされている順にインスタンスマニキュベーションを適用する必要があります。。また、登録されたインスタンスマニピュレーションのセットにリテラルの「範囲」を含めて、クライアントが（他のインスタンスマニキュベーションに関する順序付けにより）範囲の選択がデルタエンコードの前または後に行われるかどうかを指定できるようにします。
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).
また、サーバーが2つ以上のインスタンス操作が適用されている順序を示すメカニズムも必要です。これは、「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により、クライアントは「条件付きGET」を実行できます。HTTP/1.0とHTTP/1.1の両方で利用可能な従来の形式では、クライアントは「if-modified-since」リクエストヘッダーを使用して、サーバーに「ラスト修飾」タイムスタンプ（存在する場合）を提示することができます。応答が提供されたサーバー。リソースのサーバーのタイムスタンプが変更されていない場合、リソースの本文を送信しない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-none-match」リクエストヘッダーを使用して条件付きリクエストを送信することにより、キャッシュエントリを検証することができます。キャッシュされた応答に関連付けられたエンティティタグを提示します。（プロトコルは、「if-range」ヘッダーなど、エンティティタグを送信する他のいくつかの方法を定義します。これは、それ以外の場合は必要な往復を短絡するために使用されます。）提示されたエンティティタグがリソースのサーバーの現在のタグと一致する場合、サーバー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.
- Status = 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つのインスタンスが異なることを指定せずにデルタを要求することはできません。「新しい」インスタンスは、サーバーが無条件のリクエストのために戻るという現在のインスタンスであり、「古い」インスタンスは現在クライアントのキャッシュにあるものです。Cache Validator（Last Modified TimeまたはEntity Tag）は、サーバーに古いインスタンスのIDを通信するために使用されるものです。
In order to support the transmission of actual deltas, an extension to HTTP/1.1 needs to provide these features:
実際のデルタの送信をサポートするには、HTTP/1.1の拡張がこれらの機能を提供する必要があります。
1. A way to mark a request as conditional.
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. クライアントが1つ以上の特定の形式のデルタエンコーディングを適用できることを示す方法。
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).
最初の2つの機能は既にHTTP/1.1によって提供されています。条件付きリクエストヘッダーの存在（「if-midified-since」や「if-none-match」など）は条件としてリクエストをマークし、その値はその価値をマークします。ヘッダーは、古いインスタンスを一意に指定します（永久に修正されたタイムスタンプの粒度の問題を無視します）。
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.
3番目の機能は、クライアントがデルタを適用できることを示す方法（些細な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 if-none-match： "123xyz" a-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 "diff -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」を使用して圧縮された回答を受け入れることをいとわない。（「diff -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.
クライアントがDeltasを受け入れる意思があることを示しているが、サーバーがこの形式のインスタンス操作をサポートしていない場合、サーバーは単にリクエストのこの側面を無視するだけであることに注意してください。（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.
サーバーは、デルタエンコードされた応答を送信する必要はありません。たとえば、結果は、リソースの現在のサイズよりも大きくなる可能性があります。サーバーは、このタイプのリソースのデルタを計算できない場合があります（たとえば、圧縮バイナリ形式など）。サーバーには、Delta計算に十分な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つのDeltaエンコード形式を好む場合があります。）
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.
いくつかの異なるDeltaで利用可能なクライアントが変更の合間にリソースが要求される場合、デルタを内部的にサーバーにキャッシュするために支払う可能性があることに注意してください。この場合、デルタを計算するコストは多くの応答で償却される可能性があるため、サーバーはより高価な計算を使用する可能性があります。
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.0キャッシュが応答を保存するのを防ぎ、「キャッシュコントロール：MAX-AGE」（HTTP/1.1で定義）を使用して、より近代的なものを許可することです。デルタエンコードされた応答を保存するキャッシュ。これにより、応答ヘッダーに多くのバイトが追加されるため、デルタエンコーディングの有効性が低下します。また、このアプローチがすべての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.
Deltaエンコーディングのサポートの一部として、追加のステータスコードを定義することに消極的でした。ただし、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仕様は、応答が有効期限を切るか、明示的に許可する可能性がある場合にこの動作を許可します。キャッシング。これは、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」を定義します。これは、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
...
...
"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ステータスコードの仕様に準拠するキャッシュ）は、ストアなしの指令を無視し、したがって、最大年齢の指令はキャッシュを許可していると考えています。
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キャッシュが、最大年齢の指令が非店舗指令によってオーバーライドされているというルールに従うことは完全にはわかりません。運用テストでこれが問題であることが明らかになった場合、より精巧なソリューションが可能です。
Warning to origin server implementors: it does not suffice to send
起源サーバーの実装者への警告：送信するだけでは十分ではありません
Vary: If-None-Match, A-IM
Vary：if-none-match、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.
Status-226応答。IMおよびA-IMを実装しないプロキシキャッシュを誤って実装しないプロキシキャッシュを誤って「検証」することを妨げない少なくとも1つのシナリオを発見しました。
A delta-encoded response differs from a standard response in four ways:
デルタエンコードの応答は、4つの方法で標準応答とは異なります。
1. It carries a status code of 226 (IM Used).
1. 226のステータスコード（IM使用）が含まれています。
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： "489UHW" IM：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.
注：Deltaエンコードを使用した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 if-none-match： "123xyz" a-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 if-none-match： "123xyz" a-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」ヘッダーで最後に表示されるため、Origin Serverは他のInstance-Manipulationの後に範囲の選択を適用するように指示します。。
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.
IF-RangeメカニズムとDeltaエンコーディングの間の相互作用はやや複雑です。（if-rangeは、非公式に「エンティティが変更されていない場合は、私が欠けている部分を送ってください。そうでなければ、新しいエンティティ全体を送ってください。」）これは、この組み合わせの使用を明確にする必要がある例です。。
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の完全な現在のインスタンスを持っていると仮定します。このURIの（完全な）キャッシュエントリが既にあり、エンティティタグ「A」があるため、次の要求を発行します。
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 if-none-match： "a" 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 date：tue、1997年11月25日18: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 if-none-match： "a" if-range： "b" a-im：vcdiff、範囲範囲：bytes = 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"（つまり、何らかの理由で、インスタンスはすでにクライアントのキャッシュにある値に戻りました）。サーバーは、「if-none-match」の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"（つまり、インスタンスは再び変更されていません）。この場合、「if-none-match」のHTTP/1.1仕様は、ヘッダーフィールドが無視されていることです（デルタエンコーディングを理解していないサーバーによって）。したがって、これはクライアントの以前の要求と同等ですが、範囲の選択がVCDIFFインスタンス操作の後に適用されることを除きます（両方が適用される場合）。したがって、（delta-aware）サーバーは、「a」インスタンスと「b」インスタンスの間のデルタを再度計算します（またはデルタのキャッシュ計算を使用します）、範囲選択を適用し、226（使用した）応答を返します、vcdiffエンコードの結果のバイト900〜999を含むメッセージボディを「im：vcdiff、range」応答ヘッダーを備えています。
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-none-match」のHTTP/1.1仕様は、これが現在のインスタンスに対する無条件の要求と同等であることを意味します。「if-range」の仕様では、サーバーが現在のインスタンス全体を返す必要があります。ただし、Delta-Awareサーバーは、「if-none-match」フィールドと現在の（「c」）インスタンスで説明されている「A」インスタンスの間にデルタを構築し、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-none-match： "a"」ヘッダーフィールドが含まれていなかった場合、サーバーはデルタを計算できませんでした。なぜなら、どのインスタンス全体がクライアントが使用できるかを知らなかったからです。リクエストに「if-range： "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 if-none-match： "a" if-range： "b" a-im：range、vcdiff range：bytes = 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"の場合、この場合、サーバーは最初に指定された範囲（端900から端900）を「a」と「b」の両方から選択する必要があります。次に、これらの範囲間でエンコードするデルタを計算します（vcdiffを使用）、次に、「im：range、vcdiff」応答ヘッダーを使用して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.
diff -e unix "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.
diff -e |GZIP「gzip」[5]（またはおそらくより良い「7、6]）などの圧縮アルゴリズムを介して「diff」の出力を実行すると、よりコンパクトなエンコードが得られますが、エンコードとデコードのコストははるかに大きいです「diff」よりも高い。このアルゴリズムは、テキスト形式ファイルでのみ使用できます。
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]を生成するアルゴリズムは、本質的にその出力を圧縮し、一般に「diff」と「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 GDIFF形式[14]は、デルタを表現するための一般的なアルゴリズムに依存しない形式として指定されました。より一般的であるため、実装は簡単ですが、最もコンパクトなエンコード形式ではない場合があります。
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）アルゴリズムの使用は、キャッシュ置換などのいくつかの同様の状況で効果的であることが証明されています。
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-none-match」ヘッダーは、サーバーに保存されていないベースインスタンスを指定する場合があります。
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.
これまでに指定した例は、「if-none-match」ヘッダーに1つのエンティティタグのみを示していますが、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 if-none-match： "123xyz"、 "337pey"、 "489uhw" a-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 Delta-Base： "337pey"日付：TUE、1997年11月25日18: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アルゴリズムなど）を使用して達成できますが、サーバーからの特定の「ヒント」情報は、クライアントのキャッシュを管理する能力を向上させる可能性があります。Webキャッシュのパフォーマンスを改善するためのヒントの使用は、以前に説明されています[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:
この目的のために、既存の「キャッシュコントロール」ヘッダーに新しい指令を追加することを提案します。たとえば、無条件の要求に応じて、サーバーは次のことを送信する場合があります。
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日18:30:05 GMTキャッシュコントロール：保持
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日18:30:05 GMTキャッシュコントロール：保持IM：vcdiff delta-base： "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
means that the server intends to retain this base instance for one hour.
サーバーがこのベースインスタンスを1時間保持することを意味します。
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.
「保持」指令は、「最大年齢」指令に直交することに注意してください。「Max-Age」指令は、キャッシュエントリが新鮮なままでいる期間を示します（つまり、再検証のためにOrigin Serverに連絡することなく使用できます）。キャッシュエントリが古くなった後、「保持」指令はクライアントにとって興味深いものです。
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-none-match」フィールド（つまり、対応するフィールドのスーパーセットのいずれかのフィールドでその後のリクエストに返信するかもしれません最初に応答を引き出したリクエスト、またはキャッシュされた応答の「デルタベース」値を含むもの）、および互換性のある「IM」応答ヘッダーフィールド（応答。）もちろん、そのような用途は、キャッシュエントリの有効性に関する他のすべての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.
- プロキシがデルタ対応クライアントから条件付きリクエストを受信し、プロキシにはキャッシュに最新の（ "fresh、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).
- プロキシが非Delta対応クライアントからリクエストを受信すると、これをサーバーに転送する前にこれをデルタリクエストに変換し、その後（独自のキャッシュエントリのいずれかに結果のデルタ応答を適用した後）に戻ります。クライアントに対する全身応答（または、必要に応じてステータスコード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メッセージダイジェストが提供されます（ヘッダーではありません）。Digest認証メカニズム[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]で提案されています。Deltaメッセージを改ざんから保護するために、Digest認証メカニズム、またはより強いものをまだ使用したい場合があります。
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].
この仕様では、キーワードは「必須」、「必要はない」、「そうは思わない」、「そうでない」、および「可能性」は、RFC 2119 [3]に記載されているように解釈されるべきです。
This specification defines a new HTTP parameter type, an instance-manipulation:
この仕様では、新しいHTTPパラメータータイプ、インスタンス操作：
instance-manipulation = token [imparams]
instance-manipulation = token [Imparams]
imparams = ";" imparam-name [ "=" ( token | quoted-string ) ]
imparam-name = token
Note that the imparam-name MUST NOT be "q", to avoid ambiguity with the use of qvalues (see [10]).
QValuesを使用した曖昧さを避けるために、Imparam-Nameは「Q」であってはなりません（[10]を参照）。
The set of instance-manipulation values is initially:
インスタンス操作値のセットは、最初は次のとおりです。
- vcdiff A delta using the "vcdiff" encoding format [19, 20].
- vcdiff「vcdiff」エンコード形式[19、20]を使用してデルタ。
- diffe The output of the UNIX "diff -e" command [26].
- Unix "diff -e"コマンド[26]の出力をDiffieします。
- gdiff The GDIFF encoding format [14].
- GDIFFエンコード形式[14]をgdiff。
- gzip Same definition as the HTTP "gzip" content-coding.
- GZIP HTTP「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トークンは、A-IMヘッダー（IMヘッダーではない）でのみ使用され、IDインスタンス操作が許容できるかどうかを示します。
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
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）は、例えば操作値のために名前空間を管理します。値とその意味は、独立した実装間の相互運用性が可能になるように、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. クライアントの要求には、少なくとも1つのデルタコーディングをリストする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. クライアントのリクエストには、リクエスト-URI（「ベースインスタンス」）のインスタンスの少なくとも1つの有効なエンティティタグをリストするif-none-matchヘッダーフィールドが含まれています。
A delta-encoded response:
デルタエンコード応答：
- MUST carry a status code of 226 (IM Used).
- 226のステータスコードを携帯する必要があります（IM使用）。
- 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リクエストを満たしており、応答は現在のインスタンスに適用される1つ以上のインスタンスマニキュメントの結果の表現です。実際の現在のインスタンスは、特定のインスタンス操作に適しているように、この応答を他の以前または将来の応答と組み合わせることを除いて、利用できない場合があります。その場合、結果のインスタンスのヘッダーは、HTTP/1.1仕様[10]のセクション13.5.3のルールに従って、Status-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.
リクエストには、少なくとも1つのインスタンス操作をリストする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有効期限メカニズムとキャッシュ制御ヘッダー、およびセクション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 Entity-Headerフィールドは、Baseインスタンスのエンティティタグを指定するために、Deltaエンコードされた応答で使用されます。
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.
デルタエンコードされた応答がデルタベースヘッダーを含める必要がある、または含める必要がある他のケースを認識していませんが、徹底的または正式な分析を行っていません。実装者は、すべてのデルタエンコードされた応答にデルタベースヘッダーを含めることが賢明かもしれません。
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).
デルタベースヘッダーを欠くデルタエンコードされた応答を受信するキャッシュまたはプロキシは、リクエストのif-none-matchフィールドで与えられたエンティティタグである値であるデルタベースヘッダーを追加する場合があります（ただし、そのフィールドがリストしている場合にのみ正確に1つのエンティティタグ）。
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 Response-Headerフィールドは、応答で表されるインスタンスに適用されているインスタンスマニキュベーションがあれば、ある場合、操作を示すために使用されます。典型的なインスタンス操作には、デルタエンコードと圧縮が含まれます。
IM = "IM" ":" #(instance-manipulation)
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ヘッダーが「範囲」インスタンス操作をリストしている場合、応答には、コンテンツレンジヘッダーまたは各パーツにコンテンツレンジヘッダーが含まれるマルチパート/バイテレンジコンテンツタイプのいずれかを含める必要があります。（デルタのエンコードとマルチパート/バイテリアを組み合わせた具体的な説明については、セクション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.
IMヘッダーを含む応答は、セクション10.4.1で指定されているように、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：diffa、deflate、範囲
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エンコードを使用してデルタエンコードされたことを示しており、その結果はデフレートを使用して圧縮され、最後にその圧縮エンコードの1つ以上の範囲が選択されています。
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.
この例は、インスタンスの1つ以上の範囲が選択されており、その結果、以前のベースインスタンスの同一の範囲に対してデルタがエンコードされたことを示しています。
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.
1つのリクエストに返信した応答を使用して、後続のリクエストに返信するためのキャッシュは、キャッシュされた応答に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 ] )
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つ以上のDeltaコーディング値が含まれている場合、リクエストには、IF-Noneマッチヘッダーフィールドを含める必要があります。
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フィールドにリストされている場合、0のQValueを伴わない限り、それは許容されます（HTTP/1.1仕様[10]のセクション3.9で定義されているように、0平均のQ値「受け入れられません。」）サーバーは、インスタンス操作がリクエストの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".
3. A-IMフィールドには「ID; Q = 0」が含まれているために特別に拒否されない限り、「ID」インスタンス操作は常に受け入れられます。
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入力インスタンスマニピュレーションには、入力として2つの異なる値を取るため、Delta-Codingsが含まれます。圧縮と「範囲」インスタンスマニピュレーションは、1つの入力のみを取得します。他のインスタンスマニピュレーションは将来定義される場合があります。）
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
a-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
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
a-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またはdiffa形式でエンコードするデルタを受け入れ、GZIPで圧縮されたデルタエンコードの出力を受け入れることを意味します。また、A-IMがDIFFIFを使用した場合にのみ使用することを主張する方法を提供しないため、クライアントはデルタエンコードなしでインスタンスの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).
Serverの実装者には、許容可能なインスタンス操作の有用な組み合わせを選択することができます（たとえば、GZIPによるDiffaに従うことは有用ですが、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. Status-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):
Status-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ヘッダーフィールドに表示されない場合。ヘッダー間の比較は、関連するインパラム値を含む各インスタンス操作値の正確な一致を使用して行われます（セクション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.
注：このルールにより、展開されたキャッシュ実装がエラーをコミットすることなく、インスタンスマニキュベーションのセットを拡張することができます。新しいInstance-Manipulationの仕様には、認知実装のキャッシュヒット率を改善するための追加のキャッシュルールが含まれる場合があります。
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.
4. キャッシュされたIMヘッダーフィールドのインスタンス操作値のいずれかがデルタコーディングであり、キャッシュエントリにはデルタベースヘッダーフィールドが含まれている場合、デルタベースエンティティタグはifにリストされているエンティティタグの1つではない場合 - 後続のリクエストのマッチヘッダーフィールドはありません。
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マッチヘッダーフィールドが含まれていない場合エントリは、後続のリクエストの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ヘッダーフィールドに「範囲」インスタンス操作が含まれている場合、キャッシュされた応答が範囲ヘッダーフィールド値と矛盾する場合、後続の要求に応じてステータス226キャッシュエントリを使用してはなりません。リクエストでは、キャッシュされた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.
サーバーがデルタエンコードされた応答を生成する場合、サーバーが使用するコンテンツコーディングのリスト（つまり、応答のコンテンツエンコードヘッダーフィールドの値）は、サーバーが使用していたコンテンツコーディングのリストのプレフィックスである必要があります。デルタエンコーディングは生成されませんでした。
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. 新しい（delta）応答とキャッシュされた応答が異なるコンテンツコーディングのセットを持っている場合、デルタを適用する前に、クライアントがキャッシュされた応答から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. プロキシまたはキャッシュがキャッシュされたベースインスタンス応答にデルタ応答を適用した結果を転送している場合、または後でこの結果をキャッシュエントリから転送する場合、転送された応答は、新しい（DELTA）応答と同じコンテンツエンコードヘッダーフィールドを運ぶ必要があります（したがって、そのヘッダーフィールドで示されるように、コンテンツエンコードする必要があります）。
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）は、結果は、エンティティタグがコンテンツコーディングの結果に関連付けられているというルールと常に一致していること、およびデルタの適用後の受信者はコーディングは、Origin Serverからのステータス-200応答として受け取ったのとまったく同じ応答を受け取ります（Delta-Codingなし）。
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-encoding：gzip
and the origin server responds with:
Origin Serverは次のとおりです。
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日水曜日14: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").
表記URI;エンティティタグを使用して特定のインスタンスを示すため、この応答により、クライアントはエンティティGZIP（foo.html; "abc"）をキャッシュします。
Then suppose that the client, a minute later, issues this conditional request:
次に、1分後にクライアントがこの条件付きリクエストを発行すると仮定します。
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 host：example.com if-none-match： "abc" accept-encoding：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):
サーバーがデルタエンコードされた応答を生成できる場合、2つの選択肢のいずれかを選択する場合があります。1つ目は、圧縮されたインスタンスからデルタを計算することです（ただし、これは最も効率的なコーディングをもたらさない可能性があります）：
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日14:01:00 GMT ETAG： "def" delta-base： "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（gzip（foo.html; "abc"）、gzip（foo.html; "def"））の結果です。クライアントは、デルタを以前のキャッシュエントリに適用してそのエンティティを回復した後、エンティティGZIP（foo.html; "def"）を新しいキャッシュエントリとして保存します。
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日14:01:00 GMT Delta-Base： "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（gunzip（gzip（foo.html; "abc"））、foo.html; "ghi"）、またはより単純なvcdiff_delta（foo.html; "abc"、fooの結果です。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コンテンツコーディングなしのfoo.html（14:01:00 GMT）の新しい値には、同じ基礎となるファイルの圧縮インスタンスとは異なるエンティティタグが必要であることに注意してください。
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
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.
クライアントは、Accept-EncodingとA-IMヘッダーの両方にGZIPをリストします。なぜなら、サーバーがデルタエンコードをサポートしていない場合、クライアントは少なくとも圧縮の利点（コンテンツコーディングとして）を達成したいからです。ただし、サーバーがDiffe Delta-Codingをサポートしている場合、クライアントは結果を圧縮したいと考えており、これはインスタンス操作として行う必要があります。
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日14:01:00 GMT Delta-Base： "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"））の結果です。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 [10]を参照）。
The set of cache-response-directive values is augmented to include the retain directive.
Cache-Response-Directive値のセットは、保持指令を含めるように補強されています。
cache-response-directive = ... | "retain" [ "=" delta-seconds ]
Cache-Response-Directive = ... |「保持」["=" 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.
Reves DirectiveにDelta-Seconds値が含まれている場合、サーバーは、指定された秒数の後に対応するインスタンスの使用をベースインスタンスとして停止する可能性があります。クライアントは、その間隔が終了した後、デルタエンコードされた応答の将来の要求で、対応するエンティティタグを使用しないでください。間隔は、応答が生成される時間から測定されるため、クライアントは計算に応答の年齢を含める必要があります。
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.
Reves DirectiveにゼロのDelta-Seconds値が含まれている場合、クライアントはDeltaエンコードされた応答の将来の要求で対応するエンティティタグを使用してはなりません。
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指令を含めるように補強されています。
cache-response-directive = ... | "im"
Cache-Response-Directive = ... |"私は"
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 Deltaのコーディングへのデータ圧縮の適用は、多くの場合、結果のメッセージ本文のサイズを大幅に削減することが示されています。（一方、VCDIFFコーディングは本質的に圧縮されており、さらなる圧縮から利益を得ていません。）したがって、diffieおよび/またはgdiffデルタコーディングをサポートする実装もGZIPをサポートし、圧縮コーディングをデフレートすることを強くお勧めします。。（デフレートコーディングは、よりコンパクトな結果を提供します。）しかし、これは、主に圧縮と減圧に関連するCPU時間コストが環境によって過剰である可能性があるため、デルタエンコードの使用の要件ではありません。
A client that supports both delta encoding and compression as instance-manipulations signals this by, for example
たとえば、インスタンスマニピュレーションとしてのデルタエンコーディングと圧縮の両方をサポートするクライアントは、これを示しています。
A-IM: diffe, deflate
a-im：diffe、deflate
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：diffa、deflate
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
Accept-Encoding：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.
クライアントは、単一の要求で複数の非連続バイト範囲を要求する場合があります。サーバーの応答では、「マルチパート/バイテリア」メディアタイプ（[10]のセクション19.2）を使用して、応答で複数の範囲を伝えます。MultiPart/Byteranges応答がデルタエンコードされている場合（つまり、インスタンス操作としてデルタコーディングを使用）、デルタ関連のヘッダーは、個々の部品ではなく、応答全体に関連付けられています。（これは、1つのベースインスタンスと現在の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.
サーバーがMultiPart/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ヘッダーフィールドは、「範囲」リテラルの前にデルタコーディングをリストします。（これは、メッセージ送信の早期終了後に部分的な応答を取得するために取られたアプローチであることを思い出してください。）最初に、サーバーは、ベースインスタンスと現在のインスタンスとの差（DELTA）を表すバイトのシーケンスを生成し、指定されたものを選択します。バイトの範囲、およびそのような各範囲をマルチパート/バイテンジのメディアタイプの一部に送信します。
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.
MultiPart/Byteranges Responseが範囲選択後にDelta-Codingを使用する場合、A-IMおよびIMヘッダーフィールドは、「範囲」リテラルの後にデルタコーディングをリストします。（これは、インスタンスの選択されたセクションのすぐに更新されたバージョンを取得するために取られたアプローチであることを思い出してください。）サーバーは、最初に現在のインスタンスから指定された範囲を選択し、ベースインスタンスから同じ指定された範囲を選択します。（インスタンスが十分に長くない場合、これらの選択された範囲の一部は空のシーケンスである可能性があります。）サーバーは、範囲のペア間に個々の違い（デルタ）を生成し、マルチパート/バイテージの一部にそれぞれそのような違いを送信しますメディアタイプ。
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つのヘッダーが含まれます。
A-IM:vcdiff
a-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バイトの2つの異なるトレースからの平均要求サイズを報告しているため、リクエストサイズの正味の増加は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).
クライアントは、デルタエンコードされた応答のベースとして使用するために既存のキャッシュエントリを持っている必要があるため、無条件のリクエストのために「a-im：vcdiff」（または他のデルタエンコード形式のリスト）を送信することはありません。同じ研究では、長いトレースの要求の少なくとも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.
最後に、「保持」キャッシュ制御指令を使用すると、追加のオーバーヘッドが発生する可能性があります。一部のサーバーヒューリスティックは、これらのヘッダーの使用を、おそらく将来の応答を最適化する状況に制限することに成功する可能性があります。これらのヘッダーは、デルタエンコーディングのより単純な使用には必要ありません。
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.
Phong Voは、アルゴリズムとフォーマットをエンコードするデルタを選択するために、多くのガイダンスを提供しています。Issac GoldstandとMike Dahlinは、仕様に関する多くの有用なコメントを提供しました。デイブ・クリストルは多くのテキストの修正を提案しました。
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の手順に関する情報は、BCP 11に記載されています。この仕様の実施者またはユーザーによるそのような独自の権利を使用するための一般的なライセンスまたは許可を取得するために行われたのは、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. ガウラヴ・バンガ、フレッド・ダグリス、マイケル・ラビノビッチ。WWWレイテンシ削減のための楽観的なデルタ。Proc。1997 Usenix Technical Conference、カリフォルニア州アナハイム、1997年1月、289-303ページ。
2. Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2. Berners-Lee、T.、Fielding、R。and H. Frystyk、「HyperText Transfer Protocol-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. Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. エディス・コーエン、バラチャンダー・クリシュナムルシー、ジェニファー・レックスフォード。サーバーボリュームとプロキシフィルターを使用して、Webのエンドツーエンドのパフォーマンスを改善します。Proc。Sigcomm '98、1998年9月、pp。241-253。
5. Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
5. Deutsch、P。、「GZIPファイル形式の仕様バージョン4.3」、RFC 1952、1996年5月。
6. Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
6. Deutsch、P。、「圧縮データ形式の仕様バージョン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. Deutsch、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. フレッド・ダグリス、アンジャ・フェルドマン、バラチャンダー・クリシュナムルシー、ジェフリー・モーグル。変化率とその他の指標：World Wide Webのライブ研究。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. Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H。、およびT. Berners-Lee、「HyperText Transfer Protocol-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. Fielding、R.、Gettys、J.、Mogul、J.、Nielsen、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-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. Franks、J.、Hallam-Baker、P.、Hostetler、J.、Leach、P.、Luotonen、A.、Luotonen、L。and L. Stewart、「HTTP認証：基本および消化アクセス認証」、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. Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、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. アーサー・ヴァン・ホフ、ジョン・ジャンナンドレア、マーク・ハプナー、スティーブ・カーター、ミロ・メディン。HTTP分布および複製プロトコル。テクニカルレポートNote-DRP、World Wide Webコンソーシアム、1997年8月。
14. Arthur van Hoff and Jonathan Payne. Generic Diff Format Specification. Technical Report NOTE-GDIFF, World Wide Web Consortium, August, 1997.
14. アーサー・ヴァン・ホフとジョナサン・ペイン。汎用diff形式の仕様。テクニカルレポートNote-Gdiff、World Wide Webコンソーシアム、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.ハウセルとデビッドB.リンドキスト。WebExpress：ワイヤレス環境でのWebブラウジングを最適化するシステム。Proc。第2回年次INTL。conf。モバイルコンピューティングとネットワーキング、ACM、ライ麦、ニューヨーク、1996年11月、pp。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・ハント、キエム・フォン・ヴォ、ウォルター・F・ティチ。デルタアルゴリズムの実証研究。IEEEソフト。config。そして維持します。ワークショップ、1996年。
17. Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
17. Jacobson、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. Lawrence、「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. David G. KornとKiem-Phong Vo。一般的な違いデータ形式と圧縮データ形式。テクニカルレポートHA1630000-021899-02TM、AT＆T Labs-Research、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 genericの違いと圧縮データ形式」、進行中の作業。
21. Merriam-Webster. Webster's Seventh New Collegiate Dictionary. G. & C. Merriam Co., Springfield, MA, 1963.
21. メリアム・ウェブスター。Websterの7番目の新しい大学辞書。G.＆C。Merriam Co.、マサチューセッツ州スプリングフィールド、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・モーグル。Webでキャッシュされたキャッシュ。Proc。7番目のACM Sigops European Workshop、コネマラ、アイルランド、1996年9月、pp。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・モーグル、フレッド・ダグリス、アンジャ・フェルドマン、バラチャンダー・クリシュナムルシー。HTTPのデルタエンコードとデータ圧縮の潜在的な利点。調査報告書97/4、DECWRL、1997年7月。
24. Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 3230, January 2002.
24. Mogul、J。およびA. Van Hoff、「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. オープングループ。単一のUnix仕様、バージョン2-6 Vol unix 98用のVolセット。ドキュメント番号T912、Open Group、1997年2月。
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・スタンドリッジ、ガレブ・アブドゥラ、エドワード・A・フォックス。世界的なWebドキュメントのネットワークキャッシュの削除ポリシー。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、米国
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 Labs-Research 180 Park Ave、Room D-229 Florham Park、NJ 07932-0971、U.S.A。
EMail: bala@research.att.com
Fred Douglis AT&T Labs - Research 180 Park Ave, Room B-137 Florham Park, NJ 07932-0971, U.S.A.
フレッドダグリスAT＆Tラボ - リサーチ180パークアベニュー、ルームB-137フローハムパーク、ニュージャージー07932-0971、米国
Phone: 1 973 360-8775 EMail: douglis@research.att.com
電話：1 973 360-8775メール：douglis@research.att.com
Anja Feldmann University of Saarbruecken, Germany, Computer Science Department Im Stadtwald, Geb. 36.1, Zimmer 310 D-66123 Saarbruecken, Germany
Anja Feldmann Saarbruecken大学、ドイツ、コンピューターサイエンス部門IM Stadtwald、GEB。36.1、Zimmer 310 D-66123 Saarbruecken、ドイツ
EMail: anja@cs.uni-sb.de
Yaron Y. Goland
Email: yaron@goland.org
Arthur van Hoff Marimba, Inc. 440 Clyde Avenue Mountain View, CA 94043, U.S.A.
アーサー・ヴァン・ホフ・マリンバ、Inc。440 Clyde Avenue Mountain View、CA 94043、U.S.A。
Phone: 1 650 930 5283 EMail: avh@marimba.com
電話：1 650 930 5283メール：avh@marimba.com
Daniel M. Hellerstein Economic Research Service, USDA 1909 Franwall Ave, Wheaton MD 20902
Daniel M. Hellerstein Economic Research Service、USDA 1909 Franwall Ave、Wheaton MD 20902
Phone: 1 202 694-5613 or 1 301 649-4728
EMail: danielh@crosslink.net or webmaster@srehttp.org
17 Full Copyright Statement
17完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。