RFC3229 日本語訳
3229 Delta encoding in HTTP. J. Mogul, B. Krishnamurthy, F. Douglis,A. Feldmann, Y. Goland, A. van Hoff, D. Hellerstein. January 2002. (Format: TXT=111953 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループJ.要人要求をネットワークでつないでください: 3229年のコンパックWRLカテゴリ: Goland A.がホフMarimba D.Hellerstein ERS/USDA2002年1月にバンに積むSaarbruecken Y.の規格Track B.Krishnamurthy F.Douglis AT&T A.フェルドマン大学
Delta encoding in HTTP
HTTPにおけるデルタコード化
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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(ハイパーテキストTransportプロトコル)要求がクライアントが既にキャッシュエントリーを持っているリソースのわずかに変更された例の検索を引き起こします。 研究はそのような変更アップデートが頻繁であり、通常、変更が実在物よりはるかに小さいのを示しました。 そのような場合、HTTPはリソースの全体の新しい例よりむしろ変化の最小量の記述を移すことができるならネットワーク回線容量のさらに効率的な使用をするでしょうに。 これは「デルタコード化」と呼ばれます。
Mogul, et al. Standards Track [Page 1] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[1ページ]RFC3229デルタのコード化
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
1つの序論… 3 1.1 研究と提案を関係づけます… 4 2の目標… 5 3用語… HTTPメッセージ世代が配列する6 4… 8 4.1 デルタの間の関係と範囲… 11 5台の基本的機構… 13 5.1バックグラウンド: HTTPキャッシュ合法化の概観… 13 5.2 デルタのトランスミッションを要求します… 14 5.3 デルタアルゴリズムと形式の選択… 16 5.4 デルタでコード化された応答の識別… 16 5.5 キャッシュ安全を保証します… 17 5.6 デルタでコード化された応答の送信… 18 Rangeを結合する要求とデルタコード化に関する5.7の例。 19 6 アルゴリズムと形式をコード化します… 22 7 ベース例の管理… 23 7.1 なにも合わせないIfヘッダーの複数の実体タグ… 24 7.2 クライアントキャッシュを管理するために、暗示します… 25 8つのデルタと中間的キャッシュ… 27 9 データ保全のために、読みこなします… 28 10仕様… 28 10.1 パラメタ仕様を議定書の中で述べてください… 28 10.2 IANA問題… デルタでコード化された応答のための30 10.3の基本的な要件… 30 10.4 ステータスコード仕様… 30 10.4.1 226 不-中古… 31 10.5 ヘッダー仕様… 31 10.5.1 デルタ-基地… 31 10.5.2、不-、… 32 10.5.3、-、不-、… 33 10.6 キャッシュは226の応答のために統治されます… 35 10.7 デルタのために、満足しているコーディングがあるとき、統治します… 36 10.7.1 満足しているコーディングがあるときデルタを発生させるための規則… 37 10.7.2 満足しているコーディングがあるときデルタを適用するための規則… 37 10.7.3 A-IM、IM、および満足しているコーディングを使用するための例。 38 10.8 新しいCache-コントロール指示… 40 10.8.1 指示を保有してください… 40 10.8.2 IM指示… 40 10.9 デルタコード化による圧縮の使用… 41 10.10 デルタのコード化していて複合の/byteranges… プロトコルオーバーヘッドを定量化する42 11… 42 12のセキュリティ問題… 44 13の承認… 44 14知的所有権はまっすぐになります… 44
Mogul, et al. Standards Track [Page 2] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[2ページ]RFC3229デルタのコード化
15 References..................................................... 44 16 Authors' addresses............................................. 47 17 Full Copyright Statement....................................... 49
15の参照箇所… 44 16人の作者のアドレス… 47 17の完全な著作権宣言文… 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.
WWWは、分散システムであり、検索遅れを減少させるためにそうたびたびキャッシュの利益を得ます。 通常、インターネットか他の広域ネットワークの上のウェブリソース(ドキュメント、イメージ、アイコン、またはアプレットなどの)の検索は知覚の人間の敷居の上に遅れがある十分な時間がかかります。 しばしば、その遅れは秒に測定されます。 キャッシュは、検索遅れをしばしば排除するか、またはかなり、減少させることができます。
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.
多くのウェブリソースが時間がたつにつれて変化するので、実用的なキャッシュアプローチは聞き古した情報をユーザに提示するのを避けるために一貫性メカニズムを含まなければなりません。 元々、ハイパーテキストTransferプロトコル(HTTP)はほとんどキャッシュのサポートを提供しませんでしたが、操作上の圧力の下で、それは、キャッシュの一貫性を維持するために簡単なメカニズムをサポートするために急速に発展しました。
In HTTP/1.0 [2], the server may supply a "last-modified" timestamp with a response. If a client stores this response in a cache entry, and then later wishes to re-use the response, it may transmit a request message with an "If-modified-since" field containing that timestamp; this is known as a conditional retrieval. Upon receiving a conditional request, the server may either reply with a full response, or, if the resource has not changed, it may send an abbreviated reply, indicating that the client's cache entry is still valid. HTTP/1.0 also includes a means for the server to indicate, via an "Expires" timestamp, that a response will be valid until that time; if so, a client may use a cached copy of the response until that time, without first validating it using a conditional retrieval.
HTTP/1.0[2]では、サーバは応答と共に「最後、変更された」タイムスタンプを提供するかもしれません。 クライアントがキャッシュエントリーにこの応答を格納して、次に、後で応答を再使用したいと思うなら、「以来変更されるなら」分野がそのタイムスタンプを含んでいる要求メッセージを伝えるかもしれません。 これは条件付きの検索として知られています。 条件付き要求を受けると、サーバが完全な応答で返答するかもしれませんか、またはリソースが変化していないなら、簡略化された回答を送るかもしれません、クライアントのキャッシュエントリーがまだ有効であることを示して。 また、HTTP/1.0はサーバが有効であることを応答がその時までなる「期限が切れ」タイムスタンプで示す手段を含んでいます。 そうだとすれば、クライアントはその時まで応答のキャッシュされたコピーを使用するかもしれません、最初に、有効にするのなしでそれ、条件付きの検索を使用します。
HTTP/1.1 [10] adds many new features to improve cache coherency and performance. However, it preserves the all-or-none model for responses to conditional retrievals: either the server indicates that the resource value has not changed at all, or it must transmit the entire current value.
HTTP/1.1[10]はキャッシュの一貫性を改良する多くの新機能と性能を加えます。 しかしながら、保存する、オール、なにも、条件付きのretrievalsへの応答には、モデル化してください: サーバが、リソース値が全く変化していないのを示すか、またはそれは全体の現行価値を伝えなければなりません。
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.
そして、常識が示される、(跡が確認する、)、しかしながら、ウェブリソースでさえあるときに、それは変化して、新しい例はしばしば実質的に古い方と同様です。 2つの例の間の違い、または「デルタ」を全体の新しい例の代わりにクライアントに送ることができるなら、古い例のキャッシュされたコピーを持っているクライアントは、新しいバージョンを構成するためにデルタを適用できるでしょうに。 有限帯域幅の世界では、応答サイズと遅れの減少がかなりであるかもしれません。
Mogul, et al. Standards Track [Page 3] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[3ページ]RFC3229デルタのコード化
One can think of deltas as a way to squeeze as much benefit as possible from client and proxy caches. Rather than treating an entire response as the "cache line", with deltas we can treat arbitrary pieces of a cached response as the replaceable unit, and avoid transferring pieces that have not changed.
人はクライアントとプロキシキャッシュからできるだけ多くの利益を絞り出す方法としてデルタを考えることができます。 「キャッシュ線」として全体の応答を扱うよりむしろ、私たちは、デルタで、キャッシュされた応答の任意の断片を取替え可能なユニットとして扱って、変化していない断片を移すのを避けることができます。
This document proposes a set of compatible extensions to HTTP/1.1 that allow clients and servers to use delta encoding with minimal overhead.
このドキュメントはクライアントとサーバが最小量のオーバーヘッドがあるデルタコード化を使用できるHTTP/1.1に1セットのコンパチブル拡大を提案します。
We assume that the reader is familiar with the HTTP/1.1 specification.
私たちは、読者がHTTP/1.1仕様に詳しいと思います。
1.1 Related research and proposals
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画像圧縮規格は時々の静止画像フレームを伝えますが、送られたフレームの大部分は隣接しているフレームからの変化としてコード化されます(単純化しすぎる)。 ソフトウェアバージョン制御装置のSCCSとRCS[27]システムはデルタとして中間的バージョンを表します。 SCCSはオリジナルバージョンから始まって、前進のデルタでその後のものをコード化しますが、RCSは逆のデルタとして彼らの後継者から旧バージョンをコード化します。 遅いリンク[17]の上にIPとTCPヘッダーを圧縮するためのジェーコブソンのテクニックは賢明で、非常に専門化しているフォームのデルタコード化を使用します。
In spite of this history, it appears to have taken several years before anyone thought of applying delta encoding to HTTP, perhaps because the development of HTTP caching has been somewhat haphazard. The first published suggestion for delta encoding appears to have been by Williams et al. in a paper about HTTP cache removal policies [30], but these authors did not elaborate on their design until later [29].
この歴史にもかかわらず、だれでも、HTTPへのデルタコード化を適用することを考える前に数年かかったように見えます、恐らくHTTPキャッシュの開発がいくらか行き当たりばったりであるので。 デルタコード化のための最初の発行された提案はHTTPキャッシュ取り外し方針[30]に関して論文にウィリアムズ他であったように見えましたが、これらの作者は後の[29]まで彼らのデザインについて詳しく説明しませんでした。
The WebExpress project [15] appears to be the first published description of an implementation of delta encoding for HTTP (which they call "differencing"). WebExpress is aimed specifically at wireless environments, and includes a number of orthogonal optimizations. Also, the WebExpress design does not propose changing the HTTP protocol itself, but rather uses a pair of interposed proxies to convert the HTTP message stream into an optimized form. The results reported for WebExpress differencing are impressive, but are limited to a few selected benchmarks.
WebExpressプロジェクト[15]はHTTP(彼らが「differencing」と呼ぶ)のためのデルタコード化の実現の最初の発行された記述であるように見えます。 WebExpressは特に無線の環境が目的とされて、多くの直交した最適化を含んでいます。 また、WebExpressデザインは、HTTPプロトコル自体を変えるよう提案しませんが、HTTPメッセージストリームを最適化されたフォームに変換するのにむしろ1組の挿入されたプロキシを使用します。 WebExpress differencingのために報告された結果は、印象的ですが、いくつかの選択されたベンチマークに制限されます。
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
Banga他 [1] 楽観的なデルタの使用について説明してください。(そこでは、遅いリンクのどちらかの端の層の挿入されたプロキシが、レイテンシを減少させるために共同します)。 クライアントサイドプロキシにリソースのキャッシュされたコピーがあるなら、サーバサイドプロキシが単にデルタを送ることができる、(304
Mogul, et al. Standards Track [Page 4] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[4ページ]RFC3229デルタのコード化
[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.
[Modified] 応答でない。) サーバサイドプロキシだけにキャッシュされたコピーがあるなら、それは楽観的にサーバサイドプロキシが起源サーバでいったんそれ自身のキャッシュエントリーを有効にすると(必要なら)デルタがあとに続いたクライアントサイドプロキシに(ことによると聞き古した)のコピーを送るかもしれません; 楽観的なデルタの使用は実際にデルタコード化と異なってネットワークの上に送られたバイト数を増加させます、起源サーバから「変更されなかった」応答を予期することによって潜在を改良する試みで。楽観的なデルタ論文は、WebExpress紙のようにHTTPプロトコル自体への変化を提案しないで、小さいセットの選択されたURLのためだけに結果を報告しました。
Mogul et al. [23] collected lengthy traces, at two different sites, of the full contents of HTTP messages, to quantify the potential benefits of delta-encoded responses. They showed that delta encoding can provide remarkable improvements in response-size and response- delay for an important subset of HTTP content types. They proposed a set of HTTP extensions, but without the level of detail required for a specification. Douglis et al. [8] used the same sets of full- content traces to quantify the rate at which resources change in the Web.
ムガール人他 [23]は、デルタでコード化された応答の潜在的利益を定量化するためにHTTPメッセージの完全なコンテンツの2つの異なったサイトに長い跡を集めました。 彼らは、デルタコード化がHTTP内容タイプの重要な部分集合のために応答サイズと応答遅れに顕著な改良を提供できるのを示しました。 1セットのHTTP拡大を提案しましたが、それらは仕様に必要である詳細のレベルなしでそうしました。 Douglis他 [8] どのリソースにレートを定量化するか同じ中古の完全な満足している跡はウェブで変化します。
The HTTP Distribution and Replication Protocol (DRP), proposed to W3C by Marimba, Netscape, Sun, Novell, and At Home, aims to provide a collection of new features for HTTP, to support "the efficient replication of data over HTTP" [13]. One aspect of the DRP proposal is the use of "differential downloading," which is essentially a form of delta encoding. The original DRP proposal uses a different approach than is described here, but a forthcoming revision of DRP will be revised to conform to the proposal in this document.
W3Cは、Marimba、Netscape、Sun、ノベル、およびAtホームでHTTP DistributionとReplicationプロトコル(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とマッケラス[28]は"rsync"アルゴリズムを説明します。(それは、デルタコード化と同様の何かを達成します)。 rsyncでは、クライアントは、一連の修理サイズのブロックにキャッシュエントリーを壊して、各ブロックにダイジェスト値を計算して、要求の一部としてダイジェスト値のシリーズをサーバに送ります。 起源サーバは、同じブロックベースの計算をして、ダイジェスト値が異なるそれらのブロックだけを返します。 私たちは、後で本書では説明された「例の操作」枠組みを使用するrsyncを支持するのが可能であるかもしれないと信じていますが、これはどんな詳細にも解決されていません。
2 Goals
2つの目標
The goals of this proposal are:
この提案の目標は以下の通りです。
1. Reduce the mean size of HTTP responses, thereby improving latency and network utilization.
1. HTTP応答の平均であるサイズを減少させて、その結果、潜在とネットワーク利用を改良してください。
Mogul, et al. Standards Track [Page 5] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[5ページ]RFC3229デルタのコード化
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.
- HTTP要求について数を減らすのは起源サーバに発信しました。
- Reducing the size of every HTTP message.
- あらゆるHTTPメッセージのサイズを減少させます。
- Increasing the cache-hit ratio of HTTP caches.
- HTTPキャッシュのキャッシュ・ヒット率を増加させます。
- Allowing excessively simplistic implementations of delta encoding.
- デルタコード化の過度に安易な実現を許します。
- Delta encoding of request messages, or of responses to methods other than GET.
- 要求メッセージ、またはGET以外のメソッドへの応答のデルタコード化。
Nothing in this specification specifically precludes the use of a delta encoding for the body of a PUT request. However, no mechanism currently exists for the client to discover if the server can interpret such messages, and so we do not attempt to specify how they might be used.
この仕様による何も明確にPUT要求のボディーのためにコード化されるデルタの使用を排除しません。 しかしながら、クライアントが、サーバがそのようなメッセージを解釈できるかどうか発見するようにメカニズムが全く現在存在しないので、私たちは、それらがどう使用されるかもしれないかを指定するのを試みません。
3 Terminology
3 用語
HTTP/1.1 [10] defines the following terms:
HTTP/1.1[10]は次の用語を定義します:
resource A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways.
リソースAネットワークデータ・オブジェクトかセクション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.
情報が要求か応答のペイロードとして移した実体。 実体は実体本体の形で実体ヘッダーフィールドと内容の形でmetainformationから成ります、セクション7で説明されるように。
Mogul, et al. Standards Track [Page 6] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[6ページ]RFC3229デルタのコード化
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.
異形Aリソースには、どんな与えられた瞬間にもそれに関連している1、または1以上、表現があるかもしれません。 それぞれのこれらの表現は'異形'と呼ばれます。'異形'という用語のUseは、リソースが満足している交渉を受けることがあるのを必ず含意するというわけではありません。
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は「特に複合実体のボディーのメッセージか部品の1つのどちらかのMIMEで定義されたヘッダーフィールドとコンテンツについて言及する」何かと「実体」を定義します。
In HTTP, however, a response message to a GET does not have a distinct and separate existence. Rather, it reflects the current state of a resource (or a variant, subject to a set of constraints). The HTTP/1.1 specification has no term to describe "the value that would be returned in response to a GET request at the current time for the selected variant of the specified resource." This leads to awkward wordings in the HTTP/1.1 specification in places where this concept is necessary.
しかしながら、HTTPでは、GETへの応答メッセージは異なって別々の存在を持っていません。 むしろ、それはリソース(または、1セットの規制を条件とした異形)の現状を反映します。 HTTP/1.1仕様には、「指定されたリソースの選択された異形のための現在の時間のGET要求に対応して返される値」について説明する用語が全くありません。 これはこの概念が必要である場所のHTTP/1.1仕様で厄介な言葉遣いに通じます。
To express this concept, we define a new term, for use in this document:
この概念を言い表すために、私たちは使用のために本書では新学期を定義します:
instance The entity that would be returned in a status-200 response to a GET request, at the current time, for the selected variant of the specified resource, with the application of zero or more content-codings, but without the application of any instance manipulations (see below) or transfer-codings.
ゼロか以上の満足しているコーディングであるアプリケーションにもかかわらず、どんなインスタンス操作(以下を見る)や転送コーディングの応用なしでも指定されたリソースの選択された異形のための現在の時間にGET要求への状態-200応答で返される実体を例証してください。
It is convenient to think of an entity tag, in HTTP/1.1, as being associated with an instance, rather than an entity. That is, for a given resource, two different response messages might include the same entity tag, but two different instances of the resource should never be associated with the same (strong) entity tag.
実体タグを考えるのは便利です、HTTP/1.1で、実体よりむしろインスタンスに関連しているとして。 すなわち、与えられたリソースに関しては、2つの異なった応答メッセージが同じ実体タグを含むかもしれませんが、リソースの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応答を意味するのに本書では「デルタ」という用語を非公式に使用するつもりです。
Mogul, et al. Standards Track [Page 7] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[7ページ]RFC3229デルタのコード化
More formally, delta encodings are members of a potentially larger class of transformations on instances, leading to this new term:
より正式に、この新学期まで導いて、デルタencodingsは潜在的により大きいクラスのインスタンスに関する変換のメンバーです:
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つ以上の応答メッセージでサーバからクライアントまで伝えられるインスタンスをもたらすかもしれない1つ以上のインスタンスにおけるインスタンス操作An操作。 例えば、範囲選択かデルタコード化。 インスタンス操作は、終わりから終わりであり、クライアントでしばしばキャッシュの使用にかかわります。
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.
仕様へのAccordingを内容でコード化して、「満足しているコード化値を、それがコード化変換であったのを示すか、または実体に適用できます」。 満足しているコーディングは、ドキュメントが圧縮されるのを許容するのに主として使用されるか、または別の方法で基本的なメディアタイプのアイデンティティを失うことなしで情報の損失なしで有効に変えられます。 「実体は、頻繁に、コード化形式で保存されて、直接伝えられて、受取人によって解読されるだけです。」 通常、満足しているコーディングは終わりから終わりへの変換です。 すなわち、送付者でいったん適用されると、究極の受取人以外に、それらは取り除かれません。 中間的サーバは適切な事情における内容コード化を当てはまるかもしれません。
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.)
仕様への転送コード化According、「転送コード化値は、それがコード化変換であったのを示すのに使用されるか、あることができるか、またはネットワークを通した「安全輸送」を確実にするために実体本体に当てられる必要があるかもしれません」。 「これは転送コード化がオリジナルの実体ではなく、メッセージの特性であるという点において満足しているコード化と異なっています。」 転送コーディングは明らかにホップごとの変換です。(この振舞いが外部的に目に見える機能に反しないなら、中間的プロキシは最適化としてメッセージの転送でコード化されたバージョンを保存するかもしれませんが。)
Mogul, et al. Standards Track [Page 8] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[8ページ]RFC3229デルタのコード化
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).
Rangeヘッダーを使用して、範囲An 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.
クライアントが発信を内容でコード化しながらaを受ける意欲に合図する、「コード化を受け入れる、」 ヘッダー、それが理解している内容コーディングのセットを記載します。 それはどの満足しているコーディングを好むかに関して任意に情報を含むかもしれません。 サーバが何かアイデンティティの非内容コード化を使用するなら、応答に「内容をコード化している」ヘッダーフィールドを含んでいます、それらの適用の順序におけるこれらの満足しているコーディングを記載して。
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.
RFC2068[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.
本書では、私たちは、インスタンス操作の使用をサポートするために新しくて、任意のメッセージヘッダーを加えます。 クライアントが発信することによってインスタンス操作を受ける意欲に合図する、「-、不-、」 ヘッダー(詳しく説明できないくらい長い「インスタンス操作を受け入れてください」に、短い)と、類似、「コード化を受け入れる、」 ヘッダー 同様に、サーバがそれが適用したインスタンス操作使用のセットを記載する、「不-、」 ヘッダー。
One must understand the relationship between these transformations in order to see how delta encoding applies to HTTP responses.
デルタコード化がどうHTTP応答に適用されるかを見るためにこれらの変換の間の関係を理解しなければなりません。
Conceptually, the various transformations are applied in the following sequence:
概念的に、様々な変換は以下の系列で適用されます:
1. Upon receiving a GET request, the server uses the URI in the request to identify the requested resource.
1. GET要求を受け取ると、サーバは要求されたリソースを特定するという要求でURIを使用します。
2. Optionally, it uses information from the request (and perhaps additional information) to select a variant of that resource.
2. 任意に、それはそのリソースの異形を選択するという要求(そして、恐らく追加情報)から情報を使用します。
3. At this point, the server may apply a non-identity content- coding to the instance, or one might have been inherent in its generation. This also results in a Content-Encoding header.
3. ここに、サーバが非のアイデンティティの満足しているコード化をインスタンスに当てはまるかもしれませんか、または1つは世代に固有であったかもしれません。 また、これはContentをコード化しているヘッダーをもたらします。
Mogul, et al. Standards Track [Page 9] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[9ページ]RFC3229デルタのコード化
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. そして、サーバはインスタンス操作を当てはまるかもしれません。 例えば、要求がRangeヘッダーを含んでいたなら、サーバは任意に範囲応答を起こすかもしれません、元のセットのヘッダー、Content-範囲ヘッダー、および(ことによるとコード化されています)のボディーからの適切な範囲から成って。 デルタencodingsはインスタンス操作であり、現在のところ、計算されます。
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. 次に、サーバは非のアイデンティティ転送コード化を当てはまるかもしれません。 オンである、-飛んでください、このステップで圧縮できました。 そうだとすれば、Transferをコード化しているヘッダーはメッセージに追加されます。
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.
以下に注意してください。 「Content-長さの実体ヘッダーフィールドは実体本体のサイズを示します。」と、HTTP/1.1仕様[10]のセクション14.13は言います。 言い換えれば、Content-長さはインスタンスか異形ではなく、実体の長さを測定します。 例えば、メッセージがデルタコード化であるなら、Content-長さは現在のインスタンスの長さではなく、デルタコード化の長さを与えます。
Mogul, et al. Standards Track [Page 10] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[10ページ]RFC3229デルタのコード化
Diagrammatically, the sequence is:
系列は図式的に、以下の通りです。
datatype operation leading to next datatype ======== ================================== resource | choose acceptable variant, if needed v variant | apply content-coding, if any v
次のデータ型式につながるデータ型式操作======== ================================== リソース| 異形に対して必要であるなら、許容できる異形を選んでください。| もしあれば内容でコード化しているvを適用してください。
| compute/assign entity tag v instance | apply instance manipulation, if any v (delta encoding, range selection, etc.) entity-body | apply transfer-coding, if any v message-body
| 実体タグvインスタンスを計算するか、または割り当ててください。| あらゆるv(デルタコード化、範囲選択など)実体本体であるならインスタンス操作を適用してください。| あらゆるvメッセージ本体であるなら転送コード化を適用してください。
This formalization of the HTTP message generation sequence has not previously been described. However, it is clear that Range selection needs to be done after the entity tag has been assigned and after any content-coding has been applied, and before any transfer-coding is applied. Therefore, this formalization is fully consistent with previous practice and specification.
HTTPメッセージ世代系列のこの形式化は以前に、説明されていません。 しかしながら、実体タグが割り当てられてどんな後にも内容をコード化している後に選択がされる必要があるRangeが適用されて、以前どんな転送コード化も適用されているのは、明確です。 したがって、この形式化は前の習慣と仕様と完全に一致しています。
4.1 Relationship between deltas and ranges
4.1 デルタと範囲との関係
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とデルタencodingsの両方がインスタンス操作のフォームであるなら、どれが最初に、適用されるべきですか? これはRangeがどう使用されているかによります。
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. aの未完熟終了の後に部分応答を終了するには、トランスミッションを通信させてください。
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
Rangeの最初の使用で、それはどんなデルタコード化の後にも適用されなければならないでしょう、意図している使用がデルタでコード化されたインスタンスの完全なコピーを回収することであるので。 Rangeの2番目の使用で、それは、そうでないので、どんなデルタコード化の前にも適用されなければならないでしょう。
Mogul, et al. Standards Track [Page 11] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[11ページ]RFC3229デルタのコード化
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).
Range要求で指定されたオフセットは無意味でしょう(一般に、クライアントは、インスタンスバイトが実体バイトまで相殺する地図をコード化するサーバのデルタがどのように相殺されるかを知ることができません)。
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つ以上のインスタンス操作が適用されるべきであるオーダーを指定するのを許容するためにメカニズムを必要とします。 容易に仕様の一部をこれに提供する、「-、不-、」 ヘッダー(セクション10.5.3を見る)、「1、不-、」 ヘッダー。そこでは、私たちが、サーバがそれらが記載されているオーダーにおけるインスタンス操作を当てはまるのを必要とします。 また、私たちは、クライアントが、デルタコード化の前または後に範囲選択をするかどうか指定するのを(他のインスタンス操作に関する注文で)許容するために登録されたインスタンス操作のセットで「範囲」リテラルを入れます。
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つ以上のインスタンス操作がどのオーダーで適用されたかを示すように、私たちはメカニズムを必要とします。 これが仕様の一部である、「不-、」 ヘッダー(セクション10.5.2を見ます):そこでは、私たちが同じである「内容をコード化している」ヘッダーに使用される習慣のに続きます。 「不-、」 ヘッダーは適用されたオーダーにおけるインスタンス操作を記載します(恐らく特別な「範囲」リテラルを含んでいて)。
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).
Rangesが圧縮に結合されるとき、同様の問題は起こります。 クライアントが圧縮されたメッセージの未完熟終了の後に部分応答を終了するのにRangeを使用しているなら、Rangeは圧縮の後に適用されなければならないでしょう。 内容コード化として圧縮できるので、これは変更されていないHTTP/1.1で可能です。 しかしながら、クライアントがインスタンスの選択されたセクションを入手するのにRangeを使用しているなら、通常、解凍された異形だけに関してオフセットを指定できるでしょう。 選択された部分が圧縮を保証できるくらい大きいなら、クライアントが圧縮された転送コード化を要求できますが、これは、ホップごとの変換であり、最も効率的なアプローチ(特に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.
私たちは、インスタンス操作(内容コード化か転送コード化と同じくらいよく)として圧縮の使用をサポートして、クライアントがRangeインスタンス操作の後に圧縮インスタンス操作をすると指定できる新しいメカニズムを使用することによって、この問題を解決できます。
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.
また、これで、クライアントは、デルタコード化の前または後に圧縮するかどうかを制御できます、いくつかの簡単なdifferencingアルゴリズム(UNIX「デフ」コマンドなどの)が、彼らの出力のポスト圧縮が最も良い結果をもたらすのを必要とするので。
Mogul, et al. Standards Track [Page 12] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[12ページ]RFC3229デルタのコード化
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を見てください。
5.1 Background: an overview of HTTP cache validation
5.1バックグラウンド: HTTPキャッシュ合法化の概要
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」ができます、「キャッシュvalidators」の2つのフォームの1つを使用して。 両方でHTTP/1.0とHTTP/1.1で利用可能な伝統的な形式では、クライアントは、サーバが応答に提供した「最終更新日」タイムスタンプ(もしあれば)をサーバに提示するのに「以来変更されるなら」要求ヘッダーを使用するかもしれません。 リソースのためのサーバのタイムスタンプが今まで変わっていないなら、それは304(Modifiedでない)のステータスコードによる応答を送るかもしれません。(ステータスコードはリソースのボディーを伝えません)。 タイムスタンプが変化したなら、通常、サーバは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秒間、二度変化するなら、変化は検出可能でないかもしれません。 したがって、また、HTTP/1.1で、サーバは実体タグに応答を提供できます。 実体タグはそれ自身の必要性に従ってサーバによって構成された不透明なストリングです。 プロトコル仕様は要件の最低限を実体タグに課します。 (特に、「強い」実体タグは、リソースの値が変化するかどうかを変えなければなりません。) この場合、クライアントは「なにも合っていないなら」要求ヘッダーを使用することで条件付き要求を送ることによって、キャッシュエントリーを有効にするかもしれません、キャッシュされた応答に関連している実体タグを贈って。 (プロトコルは実体タグを送る他のいくつかの方法を定義します、あれほど、「-、範囲、」 ヘッダーそうでなければ、必要な周遊旅行を短絡させるのに使用されて、 提示された実体タグがリソースのためのサーバの現在のタグに合っているなら、サーバは304(Modifiedでない)応答を送るべきです。 さもなければ、サーバはリソースの完本に伴う200(OK)応答を送るべきです。
In the existing HTTP protocol (HTTP/1.0 or HTTP/1.1), a client sending a conditional request can expect either of two responses:
既存のHTTPプロトコル(HTTP/1.0かHTTP/1.1)では、条件付き要求を送るクライアントは2つの応答を期待できます:
- status = 200 (OK), with a full copy of the resource, because the server's copy of the resource is presumably different from the client's cached copy.
- サーバのリソースのコピーがおそらくクライアントのキャッシュされたコピーと異なっているのでリソースの完全なコピーがある状態=200(OK)。
Mogul, et al. Standards Track [Page 13] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[13ページ]RFC3229デルタのコード化
- 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(Modifiedでない)。
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つのインスタンスがdifferencedされているかをどうにか指定しない、すなわち、クライアントはデルタを要求できません。 「新しい」インスタンスはそれとなく、サーバが無条件要求、および「古い」インスタンスのために返す現在のインスタンスが現在、クライアントのキャッシュにはあるものであるということです。 キャッシュvalidator(最後に時間か実体タグを変更する)は古いインスタンスのアイデンティティをサーバに伝えるのに使用されることです。
5.2 Requesting the transmission of deltas
5.2 デルタのトランスミッションを要求すること。
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提供します: または、条件付き要求ヘッダーの存在、(「以来、変更される」、「-、-なにもに、合ってください、」、)、条件付きであるとして要求をマークする、そのヘッダーの値は唯一、古いインスタンス(最後変更されたタイムスタンプ粒状の問題を無視する)を指定します。
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%のデルタは別として)を適用できるのを示す方法)を達成できます。 明確に、「-、不-、」 ヘッダー。 条件付き要求における、このリストの存在は、クライアントがデルタでコード化されたキャッシュアップデートを適用できるのを示します。
Mogul, et al. Standards Track [Page 14] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[14ページ]RFC3229デルタのコード化
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
foo.html HTTP/1.1が接待する/を手に入れてください: なにも合わせないbar.example.net If: "123xyz"、-、不-、: vcdiff、diffe、gzip
The meaning of this request is that:
この要求の意味は以下のことということです。
- The client wants to obtain the current value of /foo.html.
- クライアントは/foo.htmlの現行価値を得たがっています。
- It already has a cached response (instance) for that resource, whose entity tag is "123xyz".
- それには、そのリソースのためのキャッシュされた応答(インスタンス)が既にあります。(リソースの実体タグは"123xyz"です)。
- It is willing to accept delta-encoded updates using either of two formats, "diffe" (i.e., output from the UNIX "diff -e" command), and "vcdiff". (Encoding algorithms and formats, such as "vcdiff", are described in section 6.)
- それは、2つの形式、"diffe"(すなわち、UNIX「デフ-e」コマンドからの出力)、および"vcdiff"のどちらかを使用することでデルタでコード化されたアップデートを受け入れても構わないと思っています。 ("vcdiff"などのアルゴリズムをコード化して、形式はセクション6で説明されます。)
- It is willing to accept responses that have been compressed using "gzip," whether or not these are delta-encoded. (It might be useful to compress the output of "diff -e".) However, based on the mandatory ordering constraint specified in section 10.5.3, if both delta encoding and compression are applied, then this "A-IM" request header specifies that compression should be done last.
- それは、これらがデルタによってコード化されているか否かに関係なく、"gzip"を使用することで圧縮された応答を受け入れても構わないと思っています。 (「デフ-e」の出力を圧縮するのは役に立つかもしれません。) しかしながら、デルタコード化と圧縮の両方が適用されているなら義務的な注文に基づいて規制がセクション10.5.3で指定して、その時がこれである、「-、不-、」 ヘッダーが、最後に圧縮するべきであると指定するよう要求してください。
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(Modifiedでない)応答を返すべきです、伝統的なサーバであるだろうことのように。
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
私たちは、クライアントが、デルタを受け入れても構わないと思っているのを示しますが、サーバがこの形式のインスタンス操作をサポートしないと、サーバが単に要求のこの局面を無視することに注意します。 (HTTPがいつも実装が従う仕様によって必要とされないヘッダー、および仕様を無視する実装を許容する、「-、不-、」 サーバがそれが理解していないインスタンス操作を無視するのを許容する、) どちらもサーバであるなら全くA-IMヘッダーを実装しないか、またはいずれも実装しないで
Mogul, et al. Standards Track [Page 15] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[15ページ]RFC3229デルタのコード化
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.
A-IMヘッダーに記載されたインスタンス操作では、まるでクライアントがデルタでコード化された応答を要求していないかのように、行動します: サーバは状態-200応答を生成します。
5.3 Choice of delta algorithm and format
5.3 デルタアルゴリズムと形式の選択
The server is not required to transmit a delta-encoded response. For example, the result might be larger than the current size of the resource. The server might not be able to compute a delta for this type of resource (e.g., a compressed binary format); the server might not have sufficient CPU cycles for the delta computation; the server might not support any of the delta formats supported by the client; or, the network bandwidth might be high enough that the delay involved in computing the delta is not worth the delay avoided by sending a smaller response.
サーバは、デルタでコード化された応答を伝えるのに必要ではありません。 例えば、結果はリソースの現在のサイズより大きいかもしれません。 サーバはこのタイプに関するリソース(例えば、圧縮されたバイナリフォーマット)のためにデルタを計算できないかもしれません。 サーバはデルタ計算のための十分なCPUサイクルを過さないかもしれません。 サーバはクライアントによってサポートされたデルタ形式のいずれもサポートしないかもしれません。 または、ネットワーク回線容量はデルタを計算するのにかかわる遅れが、より小さい応答を送ることによって避けられた遅れの価値がないほど高いかもしれません。
However, if the server does want to compute a delta, and the set of encodings it supports has more than one encoding in common with the set offered by the client, which encoding should it use? This is mostly at the option of the server, although the client can express preferences using "Quality Values" (or "qvalues") in the "A-IM" header. The HTTP/1.1 specification [10] describes qvalues in more detail. (Clients may prefer one delta encoding format over another that generates a smaller encoding, if the decoding costs for the first format are lower and the client is resource-constrained.)
しかしながら、サーバがデルタを計算したがっていて、1つ以上がコード化されて、セットと共用してクライアントによって提供されて、それがサポートするencodingsのセットが計算したかったなら、それはどのコード化を使用するべきですか? ほとんどサーバの選択にはこれがあります、クライアントが中で「上質の値」(または、"qvalues")を使用することで好みを言い表すことができますが「-、不-、」 ヘッダー。 HTTP/1.1仕様[10]はさらに詳細にqvaluesについて説明します。 (クライアントは、より小さいコード化を生成する別のものより1つのデルタコード化形式を好むかもしれません、最初の形式のための解読コストが低く、クライアントがリソースで強制的であるなら。)
Server implementations have a number of possible approaches. For example, if CPU cycles are plentiful and network bandwidth is scarce, the server might compute each of the possible encodings and then send the smallest result. Or the server might use heuristics to choose an encoding format, based on things such as the content-type of the resource, the current size of the resource, and the expected amount of change between instances of the resource.
サーバ実装には、多くの可能なアプローチがあります。 例えば、CPUサイクルが豊富であり、ネットワーク回線容量が不十分であるなら、サーバは、それぞれの可能なencodingsを計算して、次に、最も小さい結果を送るかもしれません。 または、サーバはコード化形式を選ぶのに発見的教授法を使用するかもしれません、リソースのcontent typeなどのものに基づいて、リソースのインスタンスの間のリソース、および予想された量の変化の現在のサイズ。
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.
内部的にサーバにデルタをキャッシュするのが得になるかもしれないことに注意してください、リソースが変更の間の数人の異なったデルタ有能なクライアントによって通常要求されるなら。 この場合デルタを計算する費用が多くの応答の上で清算されるかもしれないので、サーバは、より高価な計算を使用するかもしれません。
5.4 Identification of delta-encoded responses
5.4 デルタでコード化された応答の識別
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に指定された応答ヘッダ
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
しかしながら、デルタでコード化された応答がデルタを認識していない中間的(プロキシ)キャッシュを通して流れるなら、このアプローチの安易な応用は深刻な問題を引き起こすでしょう。
Mogul, et al. Standards Track [Page 16] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[16ページ]RFC3229デルタのコード化
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ステータスコードを使用することで特定されるよう提案します。 続く議論における特異性のために、私たちは226の(現在、割り当てられません)のコードを使用するつもりです、「不-使用された」理由句で。 (私たちは「操作が使用したインスタンス」という言葉をスペルアウトする際に利益を全く見ません、これが不要なバイトの送信を必要として、このReason-句が人間のユーザによって通常見られるはずがないので。) このアプローチのための何らかの先例があります: HTTP/1.1仕様はリソースのサブ範囲の送信のために206(部分的なContent)ステータスコードを紹介します。 既存のプロキシは、明らかに未知のステータスコードによる応答を進めて、それらをキャッシュするのを試みません。
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のキャッシュ、当時の使用が「以下をキャッシュで制御する」ということでしょう。 より現代のキャッシュが保存するのを許容する「最大時代」(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.
私たちはデルタコード化のサポートの一部と追加ステータスコードを定義するのに気が重かったです。 しかしながら、私たちはHTTP/1.0のキャッシュ実装の配布しているベースと互換性があったままで残る他のどんな効率的な方法も見ません。
5.5 Guaranteeing cache safety
5.5 キャッシュ安全を保証すること。
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のプロキシ実装も意識していませんが、応答がキャッシュするのを明らかに許容するExpiresかCache-コントロールヘッダーフィールドを運ぶなら、HTTP/1.1仕様はこの振舞いを許容します。 226(IM Used)応答がそのようなヘッダーを運ぶとき、これは問題を提示するでしょう。
Mogul, et al. Standards Track [Page 17] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[17ページ]RFC3229デルタのコード化
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仕様からCache Control Extensionsメカニズムを利用することです。 私たちが新しいキャッシュ指示を定義する、「不-、」、「店がありません」キャッシュ指示がIMとA-IMヘッダーへの仕様に従う実装によって無視されるかもしれないのを示す。
For example, this response:
例えば、この応答:
HTTP/1.1 226 IM Used ETag: "489uhw" IM: vcdiff Date: Tue, 25 Nov 1997 18:30:05 GMT Cache-Control: no-store, im, max-age=30
HTTP/1.1 226は不-ETagを使用しました: "489uhw"、不-、: vcdiff日付: グリニッジ標準時1997年11月25日火曜日18時30分5秒のキャッシュ制御: 店がない、不-、最大時代=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仕様に従うキャッシュによって保存されてください、(どれがそれを述べるか、最大時代キャッシュ指示、「応答が「キャッシュ-可能」であることを[…]含意する、ある他のまた、より制限しているキャッシュ指示も存在している、」、)でなければならない。 しかしながら、不-キャッシュ指示(すなわち、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
異なります: なにも合っていないなら-、不-
in status-226 responses. We have discovered at least one scenario where this does not prevent a proxy cache that does not implement IM and A-IM from incorrectly "validating" a cached 226 response.
状態-226の応答で。 私たちはこれが、IMとA-IMを実装しないプロキシキャッシュが不当にキャッシュされた226応答を「有効にすること」を防がない少なくとも1つのシナリオを発見しました。
5.6 Transmission of delta-encoded responses
5.6 デルタでコード化された応答の送信
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 Used)のステータスコードを運びます。
2. It carries an "IM" response-header field, indicating which delta encoding is used in this response.
2. 運ぶ、「不-、」 どのデルタコード化がこの応答に使用されるかを示す応答ヘッダ分野。
Mogul, et al. Standards Track [Page 18] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[18ページ]RFC3229デルタのコード化
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は不-ETagを使用しました: "489uhw"、不-、: vcdiff日付: グリニッジ標準時1997年11月25日火曜日18時30分5秒
...
...
(We do not show the actual contents of the response body, since this is a binary format.)
(私たちはこれがバイナリフォーマットであるのに応答本体の実際のコンテンツを示しません。)
Note: the Etag header in a 226 response with a delta encoding provides the entity tag of the current instance of the resource variant. It is not meaningful to associate an entity tag with the delta value, which is not an instance.
以下に注意してください。 デルタがコード化されている226応答におけるEtagヘッダーはリソース異形の現在のインスタンスの実体タグを提供します。 実体タグをデルタ値に関連づけるのは重要ではありません。(デルタ値はインスタンスではありません)。
5.7 Examples of requests combining Range and delta encoding
5.7 Rangeを結合する要求とデルタコード化に関する例
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
foo.html HTTP/1.1が接待する/を手に入れてください: なにも合わせないbar.example.net If: "123xyz"、-、不-、: vcdiff、diffe、gzip
and the server either responds with a 304 (Not Modified) response, or with the appropriate delta encoding.
そして、サーバは304(Modifiedでない)応答、または適切なデルタコード化で反応します。
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
foo.html HTTP/1.1が接待する/を手に入れてください: なにも合わせないbar.example.net If: "123xyz"、-、不-、: vcdiff、diffe、gzip、範囲Range: バイトは0-99と等しいです。
Mogul, et al. Standards Track [Page 19] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[19ページ]RFC3229デルタのコード化
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バイトより短いなら、全体のデルタコード化を返します。) 「範囲」トークンが中に最後に現れる、「-、不-、」 ヘッダー、これは他のインスタンス操作の後にあらゆる範囲選択を適用するように発生源サーバに言います。
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-範囲メカニズムとデルタコード化との相互作用はいくらか複雑です。 (-及んでください、手段、非公式に、「実体が変わりがないなら、私が逃している部分を私に送ってください; さもなければ、全体の新しい実体を私に送ってください」、) ここに、この組み合わせの使用をはっきりさせるべきである例があります。
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: 「A」、-、不-、: 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は不-Etagを使用しました: 「B」、不-、: vcdiff日付: グリニッジ標準時1997年11月25日火曜日18時30分5秒のコンテンツの長さ: 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バイトを検索したがっています。 したがって、それは発信するべきです:
Mogul, et al. Standards Track [Page 20] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[20ページ]RFC3229デルタのコード化
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: 「A」、-及んでください、: 「B」、-、不-、: vcdiff、範囲Range: バイト=900、-
This rather elaborate request has a well-defined meaning, which depends on the current entity tag Tcur of the instance when the server receives the request:
このかなり入念な要求には、明確な意味があります:(サーバが要求を受け取るとき、意味はインスタンスの現在の実体タグTcurによります)。
Tcur = "A" (i.e., for some reason, the instance has reverted to the value already in the client's cache). The server should return a 304 (Not Modified) response, as required by the HTTP/1.1 specification for "If-None- Match".
Tcurは「A」と等しいです(すなわち、ある理由で、インスタンスは既にクライアントのキャッシュにおける値に戻りました)。 サーバが必要に応じてHTTP/1.1仕様で304(Modifiedでない)応答を返すべきである、「-、-なにもに、合ってください、」
Tcur = "B" (i.e., the instance has not changed again). The HTTP/1.1 specification for "If-None-Match", in this case, is that the header field is ignored (by a server that does not understand delta encoding). Therefore, this is equivalent to the client's previous request, except that the Range selection is applied after the vcdiff instance manipulation (if both are to be applied). So the (delta-aware) server again computes the delta between the "A" instance and the "B" instance (or uses a cached computation of the delta), then applies the Range selection, and returns a 226 (IM Used) response, with an message-body containing bytes 900 to 999 of the result of the vcdiff encoding, with an "IM:vcdiff,range" response header.
Tcurは「B」と等しいです(すなわち、インスタンスは再び変化していません)。 「なにも合っていない」なら、この場合、それはヘッダーフィールドです。HTTP/1.1仕様、無視されます(デルタがコード化されるのを理解していないサーバで)。 したがって、これはクライアントの前の要求に同等です、Range選択がvcdiffインスタンス操作の後に適用されるのを除いて(両方が適用されているつもりであるなら)。 : vcdiff、及んでください。(デルタ意識する)のサーバと226(不-使用される)応答、900〜メッセージ本体がバイトを含んでいるvcdiffコード化の999の結果を再び「A」インスタンスと「B」インスタンス(または、デルタのキャッシュされた計算を使用する)の間のデルタを計算して、次に、範囲選択を当てはまって、返すそう、「不-、」 応答ヘッダ。
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」と等しいです(すなわち、インスタンスは再び変化しました)。 再び「なにも合っていないなら」これが相当している手段のためのこの場合HTTP/1.1仕様、現在のインスタンスのための無条件要求。 仕様、「-及んでください、」 サーバが全体の現在のインスタンスを返すのが必要です。 しかしながら、デルタ意識しているサーバが「なにも合っていないなら」分野によって説明された「A」インスタンスと現在の(「C」)インスタンスの間のデルタを組み立てて、226(不-使用される)応答を返すことができる、「不-、: 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
要求がいたクライアントが含まれていない、「なにもであるなら、合ってください」 ヘッダーフィールド、サーバはデルタを計算できませんでした、全体のインスタンスが既にどれに利用可能であったかを知っていないでしょう、したがって
Mogul, et al. Standards Track [Page 21] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[21ページ]RFC3229デルタのコード化
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.
クライアント。 要求が含んでいなかった、「-及んでください、:、」 「「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」インスタンスのためのキャッシュエントリーがあると仮定してください。そうすれば、それは既に、最初の900バイトのa新しいインスタンス「B」(恐らく中止になっている転送の結果としての)を受けました。 今、クライアントが全体の現在のインスタンスを受けたがっているので、この要求を送るかもしれません:
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: 「A」、-及んでください、: 「B」、-、不-、: vcdiff Range、及んでください: バイト=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.
及んでください、vcdiffです。しかしながら、Tcurが「B」と等しいなら、サーバがこの場合226(不-使用される)応答を使用することで最初にインスタンス「A」と「B」の両方から指定された範囲(終わりまでのバイト900)を選択して、次に、これらの範囲(vcdiffを使用する)の間のデルタコード化を計算して、次に、結果を伝えるべきである、「不-、:、」 応答ヘッダ。
6 Encoding algorithms and formats
6 アルゴリズムと形式をコード化すること。
A number of delta encoding algorithms and formats have been described in the literature:
アルゴリズムをコード化する多くのデルタと形式は文学で説明されます:
diff -e The UNIX "diff" program is ubiquitously available, and is relatively fast for both encoding and decoding (decoding is actually done using the "ed" program). However, the size of the resulting deltas is relatively large. This algorithm can only be used on text-format files.
コード化するUNIX「デフ」プログラムが遍在して利用可能であり、比較的ともに速いデフ-eと解読(解読は実際に「教育」プログラムを使用し終わっています)。 しかしながら、結果として起こるデルタのサイズは比較的大きいです。 テキスト形式ファイルの上でこのアルゴリズムを使用できるだけです。
diff -e | gzip Running the output of "diff" through a compression algorithm such as "gzip" [5] (or, perhaps better, "deflate" [7, 6]) yields a more compact encoding, but the costs of encoding and decoding are much higher than for "diff" by itself. This algorithm can only be used on text-format files.
デフ-e| gzip Running、"gzip"[5]など(「空気を抜いてください」であるほうがよい[7、6])の圧縮アルゴリズムによる「デフ」の出力が、よりコンパクトなコード化をもたらしますが、コード化と解読のコストは「デフ」よりはるかにそれ自体で高いです。 テキスト形式ファイルの上でこのアルゴリズムを使用できるだけです。
Mogul, et al. Standards Track [Page 22] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[22ページ]RFC3229デルタのコード化
vcdiff (vdelta) The algorithm that generates the "vcdiff" format [19, 20] inherently compresses its output, and generally produces smaller results than the combination of "diff" and "gzip". The algorithm also runs much faster, and can be applied to binary-format input. The "vcdiff" format is based on previous work on an algorithm named "vdelta." (Note that the "vcdiff" format can be used either for delta encoding or as a compressed format, so two different instance- manipulation values would have to be registered in order to distinguish these two uses, should its use as a compressed format be adopted.) The most recent published study suggests that "vdelta" is the best overall delta algorithm [16].
vcdiff、(vdelta) 本来"vcdiff"が形式[19、20]であると生成するアルゴリズムは、出力を圧縮して、一般に、「デフ」と"gzip"の組み合わせより小さい結果を生みます。 アルゴリズムも、はるかに速く動いて、バイナリフォーマット入力に適用できます。 "vcdiff"形式は"vdelta"というアルゴリズムで前の仕事に基づいています。 (2つの異なったインスタンス操作値がこれらの2つの用途を区別するために示されなければならないためにデルタコード化か圧縮形式として"vcdiff"形式を使用できることに注意してください、圧縮形式としての使用が採用されるなら。) 最新の発行された研究は、"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.
私たちの提案は、クライアントとサーバ作成者が最も適切な1つ(s)を選ぶようどんな特定のアルゴリズムや書式も推薦しませんが、むしろ奨励します。 しかしながら、過度に長さの可能性を避ける、「-、不-、」 ヘッダー、私たちは「お勧め」のセットのデルタ形式を汎用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.
私たちは、典型的なイメージencodingsにおける使用に、適切なアルゴリズムをコード化するデルタについて工夫するのが可能であるべきであると疑います、GIFやJPEGのように。 vdeltaとの実験は多くの可能性[23]を示していませんが、これらの実験が既にこれらのencodingsの圧縮形の直接上でvdeltaを使用したので、これは単に示します。 しかしながら、イメージの二次元本質を意識しているアルゴリズムをコード化するデルタについて工夫するのが必要であるかもしれません。 私たちには、何らかの期待があります。可能です、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."
リソースの変更の間の時間がこれが、クライアントキャッシュにおける応答のための典型的な追い立て時間ほどクライアントの条件付き要求で示された「古いインスタンス」が最新の先のインスタンスを示さないかもしれないことを意味しないということであるなら。 これはリソースのいくつの古いインスタンスがサーバによってもしあれば維持されるべきであるかに関する疑問を挙げます。 これらの古いインスタンス「ベースインスタンス」と、私たちは呼びます。
Mogul, et al. Standards Track [Page 23] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[23ページ]RFC3229デルタのコード化
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.
- サーバは先のインスタンスの部分集合だけを保存するかもしれません。 この種類の部分集合を決定するLeast Recently Used(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.
これらのアプローチのいずれも必ず追加議定書サポートを必要とするというわけではありません。 しかしながら、サーバアドミニストレータが先のインスタンスの部分集合だけを保存したいのですが、サーバができるだけ頻繁にデルタを使用することで応じたいなら、クライアントは何らかの追加情報を必要とします。 さもなければ、「なにも合っていないなら」クライアントのヘッダーはサーバで保存されなかったベースインスタンスを指定するかもしれません、適切なベースインスタンスがクライアントのキャッシュで保持されますが。
We identify two additional protocol changes to help solve this problem.
私たちは、この問題を解決するのを助けるために2回の追加議定書変化を特定します。
7.1 Multiple entity tags in the If-None-Match header
7.1 なにも合わせないIfヘッダーの複数の実体タグ
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.
私たちが今までのところ出した例は「なにも合っていないなら」ヘッダーの1個の実体タグだけを示していますが、HTTP/1.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
クライアントがキャッシュにおけるリソースの1つ以上のインスタンスを保ったと仮定してください。 それはいます、また、最新のインスタンスを保つだけではなく、1以上のコピーを優先的に頼りにします、無効のインスタンス。 または(あるいはまた、十分なデルタを保有するかもしれない。
Mogul, et al. Standards Track [Page 24] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[24ページ]RFC3229デルタのコード化
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:
より古いインスタンスを再建する逆さのデルタ情報。) この場合、それは、それがデルタを適用できたインスタンスについてすべてに関するサーバを言うのに条件付き要求を使用するかもしれません。 例えば、クライアントは発信するかもしれません:
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: "123xyz"、"337pey""489uhw"、-、不-、: 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は不-ETagを使用しました: 「1acl059"、不-、:、」 vcdiffデルタ-基地: "337pey"日付: グリニッジ標準時1997年11月25日火曜日18時30分5秒
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.
もちろん、サーバがクライアントによって特定される先のインスタンスの1つ以上を保有したなら、これは戻るために最適のデルタを選ぶという問題を複雑にするかもしれません、今、サーバにはデルタ形式だけではなく、使用するベースインスタンスの選択があるので。
7.2 Hints for managing the client cache
7.2 クライアントキャッシュを管理するためのヒント
Support for multiple entity tags in choosing the base instance implies that a client might benefit from storing multiple old instances of a resource in its cache. A client with finite space would not want to keep all old instances, so it must manage its cache for maximal effectiveness by saving those instances most likely to be useful for future deltas. Although this could be accomplished using information purely local to the client (e.g., an LRU algorithm), certain "hint" information from the server could improve the client's ability to manage its cache. The use of hints for improving Web cache performance has been described previously [4, 22].
ベースインスタンスを選ぶことにおける複数の実体タグのサポートは、クライアントがリソースの複数の古いインスタンスを蓄えるのでキャッシュのためになるかもしれないのを含意します。 有限スペースをもっているクライアントがすべての古いインスタンスを保ちたがっているというわけではないだろうので、それは最大限度の有効性のために将来のデルタの役に立つ最も傾向があるそれらのインスタンスを保存することによって、キャッシュを管理しなければなりません。 クライアント(例えば、LRUアルゴリズム)にとっての、純粋にローカルの情報を使用することでこれを達成できるでしょうが、サーバからのある「ヒント」情報はキャッシュを管理するクライアントの能力を改良するかもしれません。 ヒントのウェブキャッシュ性能を向上させる使用は以前に[4、22]、説明されます。
Mogul, et al. Standards Track [Page 25] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[25ページ]RFC3229デルタのコード化
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はETagを承認します: "337pey"日付: グリニッジ標準時1997年11月25日火曜日18時30分5秒のキャッシュ制御: 保有します。
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は不-ETagを使用しました: 「1acl059"日付:」 グリニッジ標準時1997年11月25日火曜日18時30分5秒のキャッシュ制御: IMを保有してください: vcdiffデルタ-基地: "337pey"
The "retain" directive includes an optional timeout parameter, which the server can use if it expects to delete an old base instance at a particular time. For example,
「保有」指示は任意のタイムアウトパラメタを含んでいます。(特定の時に古いベースインスタンスを削除すると予想するなら、サーバはそれを使用できます)。 例えば
HTTP/1.1 200 OK ETag: "337pey" Date: Tue, 25 Nov 1997 18:30:05 GMT Cache-Control: retain=3600
HTTP/1.1 200はETagを承認します: "337pey"日付: グリニッジ標準時1997年11月25日火曜日18時30分5秒のキャッシュ制御: =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
サーバがヒントをクライアントに提供できる別の状況は、サーバが一般に、デルタメカニズムをサポートするところですが、特定のリソースのためのデルタでコード化された応答を提供しないつもりです。 「=の0インチの指示を保有してください、そして、クライアントがこのベースインスタンス(そしてこのリソースのための含意で)を使用することでデルタでコード化された応答を得るのを試みる要求ヘッダーバイトを浪費するべきでないのを示すこと」をaに送ります。 また、それは、聞き古したであるなった後にクライアントがこのインスタンスにキャッシュスペースを浪費しないのを示します。 to
Mogul, et al. Standards Track [Page 26] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[26ページ]RFC3229デルタのコード化
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インチを保有してください、デルタでコード化された応答を得るのを試みる要求以外に」送りません。
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.
「保有」指示が「最大時代」指示と直交していることに注意してください。 「最大時代」指示は、どれくらい長いキャッシュエントリーが新鮮なままで(すなわち、再合法化のために発生源サーバに連絡しないで、使用できます)残っているかを示します。 「保有」指示はクライアントAFTERへの関心では、キャッシュエントリーが聞き古したであるなったということです。
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.
- デルタでコード化された応答を進めることに加えて、プロキシがそれを保存して、次に、「なにも合っていないなら」コンパチブル分野(すなわち、1番目が応答を引き出したという要求の対応する分野のスーパーセットかキャッシュされた応答に「デルタ-基地」値を含んでいるもののどちらかであるもの)、およびaは互換性があった状態でその後の要求に答えるのにそれを使用するかもしれない、「不-、」 応答ヘッダ分野(応答に使用される実際のデルタコード化形式を含んでいるもの) もちろん、そのような用途はキャッシュエントリーの正当性に関して他のHTTP規則のすべてを受けることがあります。
- In addition to forwarding a delta-encoded response, the proxy might apply the delta to the appropriate entry in its own cache, which could then be used for later responses (even from non-delta-capable clients).
- デルタでコード化された応答を進めることに加えて、プロキシはそれ自身のキャッシュにおける適切なエントリーにデルタを適用するかもしれません。(次に、後の応答(できる非デルタクライアントさえからの)にキャッシュを使用できました)。
- When the proxy receives a conditional request from a delta- capable client, and the proxy has a complete copy of an up-to- date ("fresh," in HTTP/1.1 terminology) response in its cache, it could generate a delta locally and return it to the requesting client.
- プロキシがデルタの有能なクライアントから条件付き要求を受けて、プロキシにキャッシュにおける上から日付(HTTP/1.1用語で「新鮮な」)への応答の完本があるとき、それは、局所的にデルタを生成して、要求しているクライアントにそれを返すかもしれません。
- When the proxy receives a request from a non-delta-capable client, it might convert this into a delta request before forwarding it to the server, and then (after applying a
- プロキシができる非デルタクライアントから要求を受け取るとき、サーバ、およびその時までそれを進める前にデルタ要求にこれを変換するかもしれない、(後にaを適用すること。
Mogul, et al. Standards Track [Page 27] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[27ページ]RFC3229デルタのコード化
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).
または、クライアントへのいっぱいのボディー応答を返すだろう、(状態があるa応答は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 Authenticationメカニズム[11]は同様のメッセージダイジェスト関数を提供します。 これらのメカニズムのどちらもいくつかのメッセージの上に送られた1セットのデータをカバーすることへのどんな設備もしません、デルタでコード化された応答(さらに言えば、Range応答)を適用するという結果のためにそうであるように。
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]で提案されます。 人は、Digest Authenticationメカニズム、または何かより強いものを使用して、まだ改ざんに対してデルタメッセージを保護していたがっているかもしれません。
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].
この仕様、キーワード“MUST"、「必須NOT」“SHOULD"で「」 「5月」はRFC2119[3]で説明されるように解釈されることになっているべきです。
10.1 Protocol parameter specifications
10.1 プロトコルパラメタ仕様
This specification defines a new HTTP parameter type, an instance- manipulation:
この仕様は新しいHTTPパラメータの型、インスタンス操作を定義します:
Mogul, et al. Standards Track [Page 28] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[28ページ]RFC3229デルタのコード化
instance-manipulation = token [imparams]
インスタンス操作はトークンと等しいです。[imparams]
imparams = ";" imparam-name [ "=" ( token | quoted-string ) ] imparam-name = token
「imparams=」;、」 imparam-名前[「=」(トークン| 引用文字列)]imparam-名前=トークン
Note that the imparam-name MUST NOT be "q", to avoid ambiguity with the use of qvalues (see [10]).
imparam-名前がqvaluesの使用であいまいさを避けるためには「q」であるはずがないと述べてください。([10])を見てください。
The set of instance-manipulation values is initially:
初めは、インスタンス操作値のセットは以下の通りです。
- vcdiff A delta using the "vcdiff" encoding format [19, 20].
- "vcdiff"コード化形式[19、20]を使用するvcdiff Aデルタ。
- diffe The output of the UNIX "diff -e" command [26].
- diffe、UNIX「デフ-e」コマンド[26]の出力。
- gdiff The GDIFF encoding format [14].
- gdiff、GDIFFコード化形式[14]。
- gzip Same definition as the HTTP "gzip" content-coding.
- gzip Same定義HTTP"gzip"内容コード化を。
- deflate Same definition as the HTTP "deflate" content-coding.
- Same定義に「空気を抜いてください」というHTTPの満足しているコード化を空気を抜かせてください。
- range A token indicating that the result is partial content, as the result of a range selection.
- 範囲選択の結果として結果が部分的な内容であることを示す範囲Aトークン。
- identity A token used only in the A-IM header (not in the IM header), to indicate whether or not the identity instance-manipulation is acceptable.
- アイデンティティインスタンス操作が許容できるかどうかを示すのにA-IMヘッダー(IMヘッダーでないところの)だけで使用されるアイデンティティAトークン。
For convenience in the rest of this specification, we define a subset of instance-manipulation values as delta-coding values:
この仕様の残りにおける便宜のために、私たちはインスタンス操作値の部分集合をデルタをコード化する値と定義します:
delta-coding = "vcdiff" | "diffe" | "gdiff" | token
デルタをコード化する="vcdiff"| "diffe"| "gdiff"| トークン
Future instance-manipulation values might also be included in this list.
また、将来のインスタンス操作値はこのリストに含まれるかもしれません。
Mogul, et al. Standards Track [Page 29] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[29ページ]RFC3229デルタのコード化
10.2 IANA Considerations
10.2 IANA問題
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]).
インターネットAssigned民数記Authority(IANA)は名前スペース例えば、操作値を管理します。 RFC、または他の同輩によって見直されて、永久的で、容易に利用可能な参照に値とそれらの意味を記録しなければなりません、詳細に十分な独立している実装の間の相互運用性は可能です。 これらの規制を条件とした名前課題はFirst Come、First Servedです。(RFC2434[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 Status Code Registryに挿入します。(RFC2817[18])を見てください。 このコードの仕様に関してセクション10.4.1を見てください。
10.3 Basic requirements for delta-encoded responses
10.3 デルタでコード化された応答のための基本の要件
A server MAY send a delta-encoded response if all of these conditions are true:
これらの状態のすべてが本当であるなら、サーバはデルタでコード化された応答を送るかもしれません:
1. The server would be able to send a 200 (OK) response for the request.
1. サーバは要求のための200(OK)応答を送ることができるでしょう。
2. The client's request includes an A-IM header field listing at least one delta-coding.
2. クライアントの要求はA-IMヘッダーフィールドリスト少なくとも1デルタコード化を含んでいます。
3. The client's request includes an If-None-Match header field listing at least one valid entity tag for an instance of the Request-URI (a "base instance").
3. クライアントの要求はRequest-URI(「ベースインスタンス」)のインスタンスのために少なくとも1個の有効な実体タグを記載するなにも合わせないIfヘッダーフィールドを含んでいます。
A delta-encoded response:
デルタでコード化された応答:
- MUST carry a status code of 226 (IM Used).
- 226(IM Used)のステータスコードを運ばなければなりません。
- 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.
- ベースインスタンスの実体タグを記載するデルタ-基地のヘッダーフィールドを含むかもしれません。
10.4 Status code specifications
10.4 ステータスコード仕様
The following new status code is defined for HTTP.
以下の新しいステータスコードはHTTPのために定義されます。
Mogul, et al. Standards Track [Page 30] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[30ページ]RFC3229デルタのコード化
10.4.1 226 IM Used
10.4.1 226 不-使用されています。
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つ以上のインスタンス操作の結果の表現です。 結合するのによるこの応答以外に、実際の現在のインスタンスは他の前の、または、今後の応答で利用可能でないかもしれません、特定のインスタンス操作において、適切です。 そうだとすれば、結果として起こるインスタンスのヘッダーは状態-226応答と他のインスタンスからヘッダーを結合するという結果です、.3のセクション13.5HTTP/1.1仕様[10]で約束を守って。
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満了メカニズムとどんなCache-コントロールヘッダーを条件としたセクション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のステータスコードで受けられた応答はキャッシュによってベースインスタンスのためのキャッシュエントリーに関連して使用されて、現在のインスタンスのためのキャッシュエントリーを作成するかもしれません。
10.5 Header specifications
10.5 ヘッダー仕様
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で議論した専門用語の混乱のために、何人かの実体ヘッダーが実体より適切にインスタンスに関連しています。)
10.5.1 Delta-Base
10.5.1 デルタ-基地
The Delta-Base entity-header field is used in a delta-encoded response to specify the entity tag of the base instance.
デルタ-基地の実体ヘッダーフィールドは、ベースインスタンスの実体タグを指定するのにデルタでコード化された応答に使用されます。
Delta-Base = "Delta-Base" ":" entity-tag
「デルタ-基地=「デルタ-基地」」:、」 実体タグ
A Delta-Base header field MUST be included in a response with an IM header that includes a delta-coding, if the request included more than one entity tag in its If-None-Match header field.
デルタコード化を含んでいるIMヘッダーによる応答にデルタ-基地のヘッダーフィールドを含まなければなりません、要求がなにも合わせないIfヘッダーフィールドに1個以上の実体タグを含んでいたなら。
Any response with an IM header that includes a delta-coding MAY include a Delta-Base header.
デルタコード化を含んでいるIMヘッダーによるどんな応答もデルタ-基地のヘッダーを含むかもしれません。
Mogul, et al. Standards Track [Page 31] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[31ページ]RFC3229デルタのコード化
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.
私たちがデルタでコード化された応答がそうしなければならない他のケースを意識していないか、SHOULDはデルタ-基地のヘッダーを含んでいますが、または私たちは徹底的であるか正式な分析をしていません。 作成者はあらゆるデルタでコード化された応答にデルタ-基地のヘッダーを含むとは賢明であるかもしれません。
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分野で与えられた実体タグであるデルタ-基地のヘッダーを加えるかもしれません(その分野がちょうど1個の実体タグを記載する場合にだけ)。
10.5.2 IM
10.5.2、不-
The IM response-header field is used to indicate the instance- manipulations, if any, that have been applied to the instance represented by the response. Typical instance manipulations include delta encoding and compression.
IM応答ヘッダ分野は、もしあれば応答で表されたインスタンスに適用されたインスタンス操作を示すのに使用されます。 典型的なインスタンス操作はデルタコード化と圧縮を含んでいます。
IM = "IM" ":" #(instance-manipulation)
「不-=、「不-、」、」、:、」 #(インスタンス操作)
Instance-manipulations are defined in section 10.1.
インスタンス操作はセクション10.1で定義されます。
As a special case, if the instance-manipulations include both range selection and at least one other non-identity instance-manipulation, the IM header field MUST be used to indicate the order in which all of these instance-manipulations, including range selection, were applied. If the IM header lists the "range" instance-manipulation, the response MUST include either a Content-Range header or a multipart/byteranges Content-Type in which each part contains a Content-Range header. (See section 10.10 for specific discussion of combining delta encoding and multipart/byteranges.)
特殊なものとして、インスタンス操作が範囲選択と他の少なくとも1つの非のアイデンティティインスタンス操作の両方を含んでいるなら、範囲選択を含むこれらのインスタンス操作のすべてが適用されたオーダーを示すのにIMヘッダーフィールドを使用しなければなりません。 IMヘッダーが「範囲」インスタンス操作を記載するなら、応答は各部分がContent-範囲ヘッダーを含むContent-範囲ヘッダーか複合/byterangesコンテントタイプのどちらかを含まなければなりません。 (デルタコード化と複合/byterangesを結合する特定の議論に関してセクション10.10を見てください。)
Responses that include an IM header MUST carry a response status code of 226 (IM Used), as specified in section 10.4.1.
IMヘッダーを含んでいる応答は226(IM Used)の応答ステータスコードを運ばなければなりません、セクション10.4.1で指定されるように。
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].
「範囲」インスタンス操作だけを記載するなら、サーバSHOULDはIMヘッダーを省略します。 通常、応答ステータスコード206(部分的なContent)と共にHTTP/1.1[10]によって指定されるようにそのような応答を送るでしょう。
Examples of the use of the IM header include:
IMヘッダーの使用に関する例は:
IM: vcdiff
不-、: vcdiff
This example indicates that the entity-body is a delta encoding of the instance, using the vcdiff encoding.
この例は、実体本体がvcdiffコード化を使用して、インスタンスをコード化するデルタであることを示します。
IM: diffe, deflate, range
不-、: diffe、空気を抜いてください、そして、及んでください。
Mogul, et al. Standards Track [Page 32] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[32ページ]RFC3229デルタのコード化
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
不-、: 範囲、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.
キャッシュされた応答がIMヘッダーフィールドを含んでいるなら、その後の要求に答えるという1つの要求に対して受けられた応答を使用するキャッシュはセクション10.6で約束を守らなければなりません。
10.5.3 A-IM
10.5.3、-、不-
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要求ヘッダーフィールドは、Acceptと同様ですが、応答で許容できるインスタンス操作(セクション10.1)を制限します。 セクション10.5.2で指定されるように、応答は複数のインスタンス操作を適用するという結果であるかもしれません。
A-IM = "A-IM" ":" #( instance-manipulation [ ";" "q" "=" qvalue ] )
「-、不-、等しさ、「-、不-、」、」、:、」 #(インスタンス操作、[「」、;、「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つ以上のデルタをコード化する値を含んでいるとき、要求はなにも合わせないIfヘッダーフィールドを含まなければなりません、要求URIのための先の応答から1個以上の実体タグを記載して。
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のqvalueは「許容できないこと」を意味します。) インスタンス操作が要求における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との許容できるインスタンス操作は好まれます。
Mogul, et al. Standards Track [Page 33] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[33ページ]RFC3229デルタのコード化
3. The "identity" instance-manipulation is always acceptable, unless specifically refused because the A-IM field includes "identity;q=0".
3. A-IMがインクルードをさばくので明確に拒否されて、「アイデンティティ; qは何0インチも等しくない」場合、「アイデンティティ」インスタンス操作はいつも許容できます。
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分野が要求に存在しているなら、サーバSHOULDは406(Acceptableでない)ステータスコードによる誤り応答を送ります。
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.
応答が1つ以上のインスタンス操作を使用するなら、それらが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入力しているインスタンス操作も応答に適用するSHOULDが選択の如何にかかわらずインスタンス操作を適用するためには、そうであるかどうかに関するサーバの選択。 (入力されるように2つの異価を取るので、2入力しているインスタンス操作はデルタコーディングを含んでいます。 圧縮と「範囲」インスタンス操作は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
-、不-、: 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
-、不-、: 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
-、不-、: vcdiff、diffe、gzip
This example means that the client will accept a delta encoding in either vcdiff or diffe format, and will accept the output of the delta encoding compressed with gzip. It also means that the client will accept a gzip compression of the instance, without any delta encoding, because A-IM provides no way to insist that gzip be used only if diffe is used.
この例は、クライアントがvcdiffかdiffe形式のどちらかでコード化されるデルタを受け入れて、gzipで圧縮されたデルタコード化の出力を受け入れることを意味します。 また、それは、クライアントがインスタンスのgzip圧縮を受け入れることを意味します、少しもデルタコード化なしで、A-IMがdiffeが使用されている場合にだけgzipが使用されると主張する方法を全く提供しないので。
Mogul, et al. Standards Track [Page 34] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[34ページ]RFC3229デルタのコード化
It is left to the server implementor to choose useful combinations of acceptable instance-manipulations (for example, following diffe by gzip is useful, but following vcdiff by gzip probably is not useful).
それが許容できるインスタンス操作の役に立つ組み合わせを選ぶのがサーバ作成者に残されます(例えば、gzipをdiffeに続けるのは役に立ちますが、gzipをvcdiffに続けるのはたぶん役に立ちません)。
10.6 Caching rules for 226 responses
10.6 226の応答のための規則をキャッシュすること。
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 Used)応答を受けるとき、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応答として保存されて、Partial Contentのために規則をキャッシュする正常なHTTPによると、使用しなければなりません。
3. It MAY store the status-226 (IM Used) response as a cache entry.
3. それはキャッシュエントリーとして状態-226(IM Used)応答を保存するかもしれません。
A status-226 cache entry MUST NOT be used in response to a subsequent request under any of these conditions (a cache that never stores status-226 responses may ignore these tests):
これらの状態のどれかでのその後の要求に対応して状態-226キャッシュエントリーを使用してはいけません(状態-226の応答を決して保存しないキャッシュはこれらのテストを無視するかもしれません):
1. If any of the instance-manipulation values from the IM header field in the cached response do not appear in the subsequent request's A-IM header field. The comparison between the headers is done using an exact match on each instance- manipulation value including any associated imparams values (see section 10.1).
1. キャッシュされた応答におけるIMヘッダーフィールドからのインスタンス操作値のいずれもその後の要求のA-IMヘッダーフィールドに現れないなら。 ヘッダーでの比較はどんな関連imparams値も含んでいて、それぞれのインスタンス操作価値で完全な一致を使用し終わっています(セクション10.1を見てください)。
2. If the order of instance-manipulation values appearing in the cached IM header field differs from the order of that set of instance-manipulations in the A-IM header field of the subsequent request.
2. インスタンス操作の注文がキャッシュされたIMで排臨を評価するなら、ヘッダーフィールドはその後の要求のA-IMヘッダーフィールドにおける、そのセットのインスタンス操作の注文と異なっています。
3. If the cache implementation is not aware of, or is not at least conditionally compliant with, the specification of any of the instance-manipulation values in the cached IM header field.
3. キャッシュ実装が意識していない、条件付きに少なくとも言いなりになります、インスタンス操作のどれかの仕様がキャッシュでIMヘッダーフィールドを評価するということではありません。
Mogul, et al. Standards Track [Page 35] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[35ページ]RFC3229デルタのコード化
Note: This rule allows for extending the set of instance- manipulations without causing deployed cache implementations to commit errors. The specification of new instance-manipulations may include additional caching rules to improve cache-hit rates in cognizant implementations.
以下に注意してください。 この規則は、誤りを犯すためにキャッシュ実装であると配布された引き起こすのなしでインスタンス操作のセットを広げると考慮します。 新しいインスタンス操作の仕様は、認識力がある実装でキャッシュヒット率を改良するために追加キャッシュ規則を含むかもしれません。
4. If any of the instance-manipulation values in the cached IM header field is a delta-coding, and the cache entry includes a Delta-Base header field, and that Delta-Base entity tag is not one of the entity tags listed in an If-None-Match header field of the subsequent request.
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ヘッダーフィールドはその後の要求のなにも合わせないIfヘッダーフィールドに合っていません。
If the IM header field of the cached response includes the "range" instance-manipulation, then a status-226 cache entry MUST NOT be used in response to a subsequent request if the cached response is inconsistent with the Range header field value(s) in the request, as would be the case for a cached 206 (Partial Content) response.
キャッシュされた応答のIMヘッダーフィールドが「範囲」インスタンス操作を含んでいるなら、キャッシュされた応答が要求におけるRangeヘッダーフィールド価値に反するなら、その後の要求に対応して状態-226キャッシュエントリーを使用してはいけません、キャッシュされた206(部分的なContent)応答のためにそうであるように。
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.
さらなる分析が必要であるかもしれません。
10.7 Rules for deltas in the presence of content-codings
満足しているコーディングがあるときデルタのための10.7の規則
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.
内容でコード化されたインスタンスがあるデルタコード化の使用は何らかのわずかな複雑さを加えます。 クライアント(恐らくプロキシ)がその新しい応答とaのコード化された応答、どちらかまたは両方がキャッシュしたデルタを受けたとき、前の応答は満足しているコーディングであるのに非のアイデンティティを持っているかもしれません。 私たちは、クライアントがサーバの応答を理解できることができない状況を防ぐためにサーバとクライアントに規則を指定します。
Mogul, et al. Standards Track [Page 36] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[36ページ]RFC3229デルタのコード化
10.7.1 Rules for generating deltas in the presence of content-codings
10.7.1 満足しているコーディングがあるときデルタを生成するための規則
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.
サーバが、いつデルタでコード化された応答、満足しているコーディングのリストがサーバであると生成するかがデルタを生成しなかったならサーバが使用した満足しているコーディングのリストの接頭語がコード化であったならSHOULDを使用します(すなわち、応答のContentをコード化しているヘッダーフィールドの値)。
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).
この要件で、プロセスの間、どんな満足しているコーディングも適用する必要はなくて、デルタでコード化された応答を受けるクライアントはキャッシュされたベースインスタンスにデルタを適用できます(クライアントがもちろんいくつかの満足しているコーディングを解読しなければならないかもしれませんが)。
10.7.2 Rules for applying deltas in the presence of content-codings
10.7.2 満足しているコーディングがあるときデルタを適用するための規則
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. 新しい(デルタ)応答とキャッシュされた応答に異なった満足しているコーディングがあるなら、デルタを適用する前に、クライアントはデルタ応答としてキャッシュされた同じくらいが結果にあるまでの応答からの満足しているコーディングの1セット以上の満足しているコーディングを解読します。
3. If a proxy or cache is forwarding the result of applying the delta response to a cached base instance response, or later forwards this result from a cache entry, the forwarded response MUST carry the same Content-Encoding header field as the new (delta) response (and so it must be content-encoded as indicated by that header field).
3. プロキシかキャッシュがキャッシュされたベース例の応答にデルタ応答を適用するという結果を進めているか、または後でキャッシュエントリーからこの結果を進めるなら、進められた応答は新しい(デルタ)応答と同じContentをコード化しているヘッダーフィールドを運ばなければなりません(したがって、それはそのヘッダーフィールドによって示されるように内容でコード化していなければなりません)。
The intent of these rules (and in particular, rule #3) is that the results are always consistent with the rule that the entity tag is associated with the result of the content-coding, and that any recipient after the application of the delta-coding receives exactly the same response it would have received as a status-200 response from the origin server (without any delta-coding).
これらの規則(特に、#3、を統治する)の意図は実体タグが内容をコード化しているという結果に関連しているという結果がいつも規則と一致していて、デルタコード化のアプリケーションがそれが持っているまさに同じ応答を受けた後にどんな受取人も状態-200応答として起源サーバ(少しもデルタコード化のない)から受信したということです。
Mogul, et al. Standards Track [Page 37] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[37ページ]RFC3229デルタのコード化
10.7.3 Examples for using A-IM, IM, and content-codings
10.7.3 A-IM、IM、および満足しているコーディングを使用するための例
Suppose a client, with an empty cache, sends this request:
クライアントが空のキャッシュと共にこの要求を送ると仮定してください:
GET /foo.html HTTP/1.1 Host: example.com Accept-encoding: gzip
foo.html HTTP/1.1が接待する/を手に入れてください: example.com Acceptをコード化しています: gzip
and the origin server responds with:
そして、起源サーバは以下で反応します。
HTTP/1.1 200 OK Date: Wed, 24 Dec 1997 14:00:00 GMT Etag: "abc" Content-encoding: gzip
HTTP/1.1 200OK日付: グリニッジ標準時1997年12月24日水曜日14時0分0秒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
foo.html HTTP/1.1が接待する/を手に入れてください: なにも合わせないexample.com If: 「abcに、」コード化を受け入れます: 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つを選ぶかもしれません。 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は不-日付:を使用でした グリニッジ標準時1997年12月24日水曜日14時1分0秒Etag: 「クールな」デルタ-ベース: 以下を内容でコード化する"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_デルタ(GZIP(foo.html; "abc")、GZIP(foo.html; 「クール」))の結果でしょう。 クライアントは新しいキャッシュエントリーとして実体GZIP(foo.html; 「クール」)を格納するでしょう、前のキャッシュエントリーにデルタを適用することによってその実体を回復した後に。
The server's other alternative would be to compute the delta from the uncompressed values, returning:
サーバの他の代替手段は以下を返して、解凍された値からデルタを計算するだろうことです。
Mogul, et al. Standards Track [Page 38] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[38ページ]RFC3229デルタのコード化
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は不-日付:を使用でした グリニッジ標準時1997年12月24日水曜日14時1分0秒のデルタ-ベース: "abc"Etag: "ghi"、不-、: 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_デルタ(foo.html; GUNZIP(GZIP(foo.html; "abcする"である))、"ghiする"である)、または、より単にVCDIFF_デルタ(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時1分0秒の)の新しい値には同じ基本的なファイルの圧縮された例からの異なった実体タグがなければならないことに注意してください。
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
foo.html HTTP/1.1が接待する/を手に入れてください: なにも合わせないexample.com If: 「abcに、」コード化を受け入れます: 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-コード化とA-IMヘッダーにgzipを記載します、サーバがデルタコード化を支持しないなら、クライアントが圧縮(内容コード化としての)の恩恵を少なくとも達成したがっているので。 しかしながら、サーバがdiffeデルタコード化を支持するなら、結果をクライアントは圧縮されたがっています、そして、例操作としてこれを終わらなければなりません。
A server that does support diffe might reply:
diffeを支持するサーバは返答するかもしれません:
HTTP/1.1 226 IM Used Date: Wed, 24 Dec 1997 14:01:00 GMT Delta-base: "abc" Etag: "ghi" IM: diffe, gzip
HTTP/1.1 226は不-日付:を使用でした グリニッジ標準時1997年12月24日水曜日14時1分0秒のデルタ-ベース: "abc"Etag: "ghi"、不-、: 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_デルタ(foo.html; GUNZIP(GZIP(foo.html; "abcする"である))、"ghiする"である))、または、より単にGZIP(DIFFE_デルタ(foo.html; "abc"、foo.html; "ghi"))の結果でしょう。 したがって、クライアントは新しいキャッシュエントリーとして実体foo.htmlを格納するでしょう; この場合gzip圧縮が内容コード化ではなく、例の操作であるので、組み立て直された応答を格納するか、または進めるとき、それを保有しないで、"ghi"(少しも内容コード化や圧縮のない)。
Mogul, et al. Standards Track [Page 39] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[39ページ]RFC3229デルタのコード化
10.8 New Cache-Control directives
10.8 新しいCache-コントロール指示
We define two new cache-directives (see section 14.9 of RFC 2616 [10] for the specification of cache-directive).
私たちは2つの新しいキャッシュ指示を定義します(キャッシュ指示の仕様のためのRFC2616[10]のセクション14.9を見てください)。
10.8.1 Retain directive
10.8.1 指示を保有してください。
The set of cache-response-directive values is augmented to include the retain directive.
キャッシュ応答指示値のセットが含むように増大する、指示を保有してください。
cache-response-directive = ... | "retain" [ "=" delta-seconds ]
キャッシュ応答指示=… | 「保有」[「=」デルタ秒]
A retain directive is always a "hint" from a server to a client; it never specifies a mandatory action for the recipient.
Aが保有する、サーバからクライアントまでいつも指示は「ヒント」です。 それは義務的な動作を受取人に決して指定しません。
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".
aの存在は指示を保有します。デルタ有能なクライアントがキャッシュにおける応答における例、スペースの可能にすることを保有するべきであるのを示して、デルタでコード化された応答に未来の要求で対応する実体タグを使用するべきです。 すなわち、サーバは、ベース例として対応する例を使用することでデルタでコード化された応答を提供しそうです。 それの或るものがクライアントがリソースのいくつかの例を検索して、キャッシュしたなら「保有」でマークされる含意といくつか、そして、中で「保有」でマークされなかった例をキャッシュするポイントが全くありません。
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.
aデルタ秒が評価する指示のインクルードを保有してください、そして、次に、サーバは秒の指定された数の後にベース例として対応する例を使用するのを止めそうです。 その間隔が終わった後にクライアントはデルタのコード化された応答に今後の要求で対応する実体タグを使用しません。 間隔は応答が発生するのでクライアントが計算で応答のAgeを入れるべきである時間から測定されます。
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.
aデルタ秒が評価するゼロの指示のインクルードを保有してください、そして、aクライアントSHOULD NOTはデルタでコード化された応答に今後の要求で対応する実体タグを使用します。
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インチの指示を保有してください」であると考えることを勧めます。
10.8.2 IM directive
10.8.2 IM指示
The set of cache-response-directive values is augmented to include the im directive.
キャッシュ応答指示値のセットは、不-指示を含むように増大します。
Mogul, et al. Standards Track [Page 40] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[40ページ]RFC3229デルタのコード化
cache-response-directive = ... | "im"
キャッシュ応答指示=… | 「不-、」
A cache that complies with the specification for the IM header, the A-IM header, and the 226 response-status code SHOULD ignore a no- store cache-directive if an im directive is present in the same response. All other implementations MUST ignore the im directive (i.e., MUST observe a no-store directive, if present).
不-指示が同じ応答で存在しているなら、IMヘッダーのために仕様に従うキャッシュ、A-IMヘッダー、および226応答ステータスコードSHOULDはいいえ店キャッシュ指示を無視します。 他のすべての実現が不-指示(すなわち、指示の、そして、現在のどんな店も観測してはいけない)を無視しなければなりません。
10.9 Use of compression with delta encoding
10.9 デルタコード化による圧縮の使用
The application of data compression to the diffe and gdiff delta codings has been shown to greatly reduce the size of the resulting message bodies, in many cases. (The vcdiff coding, on the other hand, is inherently compressed and does not benefit from further compression.) Therefore, it is strongly recommended that implementations that support the diffe and/or gdiff delta codings also support the gzip and/or deflate compression codings. (The deflate coding provides a more compact result.) However, this is not a requirement for the use of delta encoding, primarily because the CPU-time costs associated with compression and decompression may be excessive in some environments.
diffeとgdiffデルタコーディングへのデータ圧縮の適用は結果として起こるメッセージ本体のサイズを大いに減少させるために示されました、多くの場合。 (vcdiffコード化は、他方では、本来圧縮されて、さらなる圧縮の利益を得ません。) したがって、diffeを支持する実現、そして/または、gdiffデルタコーディングがまた、gzipを支持する、そして/または、圧縮コーディングに空気を抜かせることが強く勧められます。 コード化しながら、空気を抜いてください。(よりコンパクトな結果を提供する、) しかしながら、これはデルタコード化の使用のための要件ではありません、主として圧縮と減圧に関連しているCPU時間コストがいくつかの環境で過度であるかもしれないので。
A client that supports both delta encoding and compression as instance-manipulations signals this by, for example
例えば、例操作がこれを示すようにデルタコード化と圧縮の両方を支持するクライアント
A-IM: diffe, deflate
-、不-、: diffe、空気を抜いてください。
The ordering rule stated in section 10.5.3 requires, if the server uses both instance-manipulations in the response, that compression be applied to the result of the delta encoding, rather than vice versa. I.e., the response in this case would include
サーバが応答における両方の例操作を使用するならセクション10.5.3で述べられた注文規則が、圧縮がむしろデルタコード化の結果に適用されるのを必要とする、逆もまた同様です。 すなわち、この場合、応答は包含するでしょう。
IM: diffe, deflate
不-、: diffe、空気を抜いてください。
Note that a client might accept compression either as a content- coding or as an instance-manipulation. For example:
クライアントが内容コード化として、または、例操作として圧縮を認めるかもしれないことに注意してください。 例えば:
Accept-Encoding: gzip A-IM: gzip, gdiff
コード化を受け入れます: gzip A-IM: gzip、gdiff
In this example, the server may apply the gzip compression, either as a content-coding or as an instance-manipulation, before delta encoding. Remember that the entity tag is assigned after content- coding but before instance-manipulation, so this choice does affect the semantics of delta encoding.
この例では、サーバはgzip圧縮を当てはまるかもしれません、どちらか内容でコード化するか、またはデルタの前での例操作としてコード化として。 実体タグが内容コード化の後に割り当てられますが、したがって、例操作の前にこの選択がデルタコード化の意味論に影響するのを覚えていてください。
Mogul, et al. Standards Track [Page 41] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[41ページ]RFC3229デルタのコード化
10.10 Delta encoding and multipart/byteranges
10.10 デルタのコード化していて複合の/byteranges
A client may request multiple, non-contiguous byte ranges in a single request. The server's response uses the "multipart/byteranges" media type (section 19.2 of [10]) to convey multiple ranges in a response. If a multipart/byteranges response is delta encoded (i.e, uses a delta-coding as an instance-manipulation), the delta-related headers are associated with the entire response, not with the individual parts. (This is because there is only one base instance and one current instance involved.) A delta-encoded response with multiple ranges MUST use the same delta-coding for all of the ranges.
クライアントは、複数の、そして、非隣接のバイトがただ一つの要求のねらいを定めるよう要求するかもしれません。 サーバの応答は「複合/byteranges」メディアタイプを使用します。(倍数を伝えるセクション19.2の[10])は応答のねらいを定めます。 複合/byteranges応答がコード化されたデルタ(i.e、例操作としての用途aデルタコード化)であるなら、デルタ関連のヘッダーは個々の部品ではなく、全体の応答に関連しています。 (これは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.
サーバが、複合/のために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.
複合/byteranges応答が範囲選択の前にデルタコード化を使用すると、A-IMとIMヘッダーフィールドは「範囲」の前に文字通りでデルタコード化を記載します。 (これがメッセージ送信の未完熟終了の後に部分応答を得るために取られたアプローチであると思い出してください。) サーバ初がベース例と現在の例の違い(デルタ)を表すバイトの系列を発生させて、次に、指定された範囲のバイトを選択して、複合/の一部のそのような各範囲を伝えるので、byterangesメディアはタイプされます。
When a multipart/byteranges response uses a delta-coding after a range selection, the A-IM and IM header fields list the delta-coding after the "range" literal. (Recall that this is the approach taken to obtain an updated version just of selected sections of an instance.) The server first selects the specified ranges from the current instance, and also selects the same specified ranges from the base instance. (Some of these selected ranges might be the empty sequence, if the instance is not long enough.) The server then generates the individual differences (deltas) between the pairs of ranges, and transmits each such difference in a part of the multipart/byteranges media type.
複合/byteranges応答が範囲選択の後にデルタコード化を使用すると、A-IMとIMヘッダーフィールドは「範囲」の後に文字通りでデルタコード化を記載します。 (これがまさしく例の選択されたセクションのアップデートされたバージョンを得るために取られたアプローチであると思い出してください。) サーバは、最初に現在の例から指定された範囲を選択して、また、ベース例から同じ指定された範囲を選択します。 (例が十分長くないなら、これらの選択された範囲のいくつかが空の系列であるかもしれません。) サーバが次に、範囲の組の間で個人差を発生させて(デルタ)、複合/の一部でそのような各違いを伝えるので、byterangesメディアはタイプされます。
11 Quantifying the protocol overhead
11 プロトコルオーバーヘッドを定量化すること。
The proposed protocol changes increase the size of the HTTP message headers slightly. In the simplest case, a conditional request (i.e., one for a URI for which the client already has a cache entry) would include one more header, e.g.:
提案されたプロトコル変化はHTTPメッセージヘッダーのサイズをわずかに増加させます。 最も簡単な場合では、条件付き要求(すなわち、クライアントが既にキャッシュエントリーを持っているURIのためのもの)は例えばもうひとつのヘッダーを含んでいるでしょう:
A-IM:vcdiff
-、不-、: vcdiff
Mogul, et al. Standards Track [Page 42] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[42ページ]RFC3229デルタのコード化
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).
クライアントにはデルタでコード化された応答にベースとして使用する既存のキャッシュエントリーがなければならないので、決して発信しない、「-、不-、:、」 無条件要求のための"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.:
デルタによってコード化された応答はわずかに長いヘッダーを運びます。 最も簡単な場合では、応答は例えばもうひとつのヘッダーを運びます:
IM:vcdiff
不-、: 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.
コード化がそれで支払うデルタが数1,000バイト[23]を救うと、シミュレーションはそれを示します。 したがって、12数バイトを応答ヘッダに加えると、メッセージ本体サイズにおける貯蓄はほとんど取り除かれるべきではありません。
Finally, the use of the "retain" Cache-Control directive might cause some additional overhead. Some server heuristics might be successful in limiting the use of these headers to situations where they would probably optimize future responses. Neither of these headers is necessary for the simpler uses of delta encoding.
最終的に、「保有」Cache-コントロール指示の使用は何らかの追加オーバーヘッドを引き起こすかもしれません。 いくつかのサーバ発見的教授法がこれらのヘッダーの使用をそれらがたぶん今後の応答を最適化する状況に制限するのに成功しているかもしれません。 これらのヘッダーのどちらもデルタコード化の、より簡単な用途に必要ではありません。
Mogul, et al. Standards Track [Page 43] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[43ページ]RFC3229デルタのコード化
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はデルタがアルゴリズムと形式をコード化することの選択における大きな指導を提供しました。 アイザックGoldstandとマイク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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
15 References
15の参照箇所
1. Gaurav Banga, Fred Douglis, and Michael Rabinovich. Optimistic Deltas for WWW Latency Reduction. Proc. 1997 USENIX Technical Conference, Anaheim, CA, January, 1997, pp. 289-303.
1. Gaurav Banga、フレッドDouglis、およびマイケル・ラビノビチ。 WWW潜在減少のための楽観的なデルタ。 Proc。 1997年のUSENIX Technicalコンファレンス、アナハイム(カリフォルニア)1997年1月、ページ 289-303.
2. Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2. バーナーズ・リー、T.、フィールディング、R.、およびH.Frystyk、「ハイパーテキストはプロトコルを移します--HTTP/1インチ、RFC1945、1996年5月。」
3. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
3. ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Mogul, et al. Standards Track [Page 44] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[44ページ]RFC3229デルタのコード化
4. Edith Cohen, Balachander Krishnamurthy, and Jennifer Rexford. Improving End-to-End Performance of the Web Using Server Volumes and Proxy Filters. Proc. SIGCOMM '98, September, 1998, pp. 241- 253.
4. イーディス・コーエン、Balachander Krishnamurthy、およびジェニファーRexford。 サーバボリュームとプロキシフィルタを使用することで終わりから終わりへのウェブの性能を向上させます。 Proc。 SIGCOMM98年、1998年9月、ページ 241- 253.
5. Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
5. ドイツ語、P.、「GZIPは1996年5月に書式仕様バージョン4.3インチ、RFC1952をファイルします」。
6. Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
6. ドイツ語、P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、1996インチ年5月。
7. Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
7. ドイツ語、P.、およびJ-L。 ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、1996インチ年5月。
8. Fred Douglis, Anja Feldmann, Balachander Krishnamurthy, and Jeffrey Mogul. Rate of Change and Other Metrics: a Live Study of the World Wide Web. Proc. Symposium on Internet Technologies and Systems, USENIX, Monterey, CA, December, 1997, pp. 147-158.
8. フレッドDouglis、アーニャ・フェルドマン、Balachander Krishnamurthy、およびジェフリー・ムガール人。 増減率と他の測定基準: WWWのライブ研究。 Proc。 インターネットTechnologiesとSystems、USENIX、モントレーカリフォルニア1997年12月、ページに関するシンポジウム 147-158.
9. Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
9. フィールディング、R.、Gettys、J.、ムガール人、J.、ニールセン、H.、およびT.Bernersリー、「HTTP/1.1インチ、RFC2068、1997年ハイパーテキスト転送プロトコル--1月。」
10. Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
10. フィールディング、R.、Gettys、J.、ムガール人、J.、ニールセン、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
11. Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Luotonen, L. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authnetication", RFC 2617, June 1999.
11. フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.、Luotonen、L.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセスAuthnetication」、1999年6月のRFC2617。
12. Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
12. N.とN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
13. Arthur van Hoff, John Giannandrea, Mark Hapner, Steve Carter, and Milo Medin. The HTTP Distribution and Replication Protocol. Technical Report NOTE-DRP, World Wide Web Consortium, August, 1997.
13. アーサー・バンホフ、ジョンGiannandrea、マークHapner、スティーブ・カーター、およびミロ・メディン。 HTTP分配と模写は議定書を作ります。 技術報告書注意-DRP、ワールドワイドウェブコンソーシアム、1997年8月。
14. Arthur van Hoff and Jonathan Payne. Generic Diff Format Specification. Technical Report NOTE-GDIFF, World Wide Web Consortium, August, 1997.
14. アーサー・バンホフとジョナサン・ペイン。 一般的なデフ書式仕様。 技術報告書注意-GDIFF、ワールドワイドウェブコンソーシアム、1997年8月。
Mogul, et al. Standards Track [Page 45] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[45ページ]RFC3229デルタのコード化
15. Barron C. Housel and David B. Lindquist. WebExpress: A System for Optimizing Web Browsing in a Wireless Environment. Proc. 2nd Annual Intl. Conf. on Mobile Computing and Networking, ACM, Rye, New York, November, 1996, pp. 108-116.
15. バロンC.Houselとデヴィッド・B.リンドキスト。 WebExpress: 無線の環境におけるウェブ閲覧を最適化するシステム。 Proc。 第2年に一度のIntl。 ConfモバイルComputingとNetworking、ACM、Rye、ニューヨーク1996年11月、ページに関して 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.狩り、Kiem-Phong Vo、およびウォルター・F.ティチー。 実証的である、柔らかい状態でデルタアルゴリズムIEEEを研究してください。 コンフィグMaint。 ワークショップ、1996。
17. Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
17. 1990年2月のジェーコブソン対「低速連続のリンクへのTCP/IPヘッダーを圧縮すること」でのRFC1144
18. Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
18. 「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」Khare、R.、およびS.ローレンス。
19. David G. Korn and Kiem-Phong Vo. A Generic Differencing and Compression Data Format. Technical Report HA1630000-021899-02TM, AT&T Labs - Research, February, 1999.
19. デヴィッド・G.コルンとKiem-Phong Vo。 一般的なDifferencingと圧縮データの形式。 技術報告書HA1630000-021899-02TM、AT&T研究室--1999年2月に、研究してください。
20. Korn, D. and K. Vo, "The VCDIFF Generic Differencing and Compression Data Format", Work in Progress.
20. 「VCDIFFの一般的なDifferencingと圧縮データの形式」というコルン、D.、およびK.Voは進行中で働いています。
21. Merriam-Webster. Webster's Seventh New Collegiate Dictionary. G. & C. Merriam Co., Springfield, MA, 1963.
21. メリアム-ウェブスター。 ウェブスターの第7新しい大学生用辞典。 G。 C.メリアム社、スプリングフィールド(MA)1963
22. Jeffrey C. Mogul. Hinted caching in the Web. Proc. Seventh ACM SIGOPS European Workshop, Connemara, Ireland, September, 1996, pp. 103-108.
22. ジェフリー・C.ムガール人。 ウェブにおけるキャッシュについて暗示しました。 Proc。 Workshop、コネマラ(アイルランド)1996年9月のヨーロッパの第7ACM SIGOPS、ページ 103-108.
23. Jeffrey C. Mogul, Fred Douglis, Anja Feldmann, and Balachander Krishnamurthy. Potential benefits of delta encoding and data compression for HTTP. Research Report 97/4, DECWRL, July, 1997.
23. ジェフリー・C.ムガール人、フレッドDouglis、アーニャ・フェルドマン、およびBalachander Krishnamurthy。 HTTPのためのデルタコード化とデータ圧縮の潜在的利益。 1997年7月にレポート97/4、DECWRLについて研究してください。
24. Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", RFC 3230, January 2002.
24. ムガール人、J.、およびA.は2002年1月にホフ、「HTTPにおける例のダイジェスト」、RFC3230をバンに積みます。
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問題部に書くためのガイドライン」BCP26、1998年10月のRFC2434。
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. TheOpenGroup。 ただ一つのUNIX仕様、2--6VolがUNIX98に設定するバージョン。 1997年2月に数のT912、TheOpenGroupを記録してください。
Mogul, et al. Standards Track [Page 46] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[46ページ]RFC3229デルタのコード化
27. W. Tichy. "RCS - A System For Version Control". Software - Practice and Experience 15, 7 (July 1985), 637-654.
27. W。 ティチー。 「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. アンドリューTridgellとポール・マッケラス。 rsyncアルゴリズム。 技術報告書TR Cs96-05、コンピュータサイエンス学部、オーストラリア国立大学、1996年6月。
29. Stephen Williams. Personal communication. http://ei.cs.vt.edu/~williams/DIFF/prelim.html.
29. スティーブン・ウィリアムズ個人的なコミュニケーション http://ei.cs.vt.edu/~williams/DIFF/prelim.html 。
30. Stephen Williams, Marc Abrams, Charles R. Standridge, Ghaleb Abdulla, and Edward A. Fox. Removal Policies in Network Caches for World-Wide Web Documents. Proc. SIGCOMM '96, Stanford, CA, August, 1996, pp. 293-305.
30. スティーブン・ウィリアムズ、マーク・エーブラムズ、チャールズR.Standridge、Ghalebアブドゥラ、およびエドワードA.フォックス。 WWWドキュメントのためのネットワークキャッシュにおける取り外し方針。 Proc。 SIGCOMM96年、スタンフォード、カリフォルニア、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.
Avenueパロアルト、ジェフリー・C.の要人の西洋の研究所コンパックコンピュータ社250の大学カリフォルニア 94305、米国
Phone: 1 650 617 3304 (email preferred) EMail: JeffMogul@acm.org
以下に電話をしてください。 1 650 617 3304(好まれたメール)EMail: JeffMogul@acm.org
Balachander Krishnamurthy AT&T Labs - Research 180 Park Ave, Room D-229 Florham Park, NJ 07932-0971, U.S.A.
Balachander Krishnamurthy AT&T研究室--研究180公園Ave、部屋D-229 Florham公園、ニュージャージー07932-0971、米国
EMail: bala@research.att.com
メール: bala@research.att.com
Fred Douglis AT&T Labs - Research 180 Park Ave, Room B-137 Florham Park, NJ 07932-0971, U.S.A.
フレッドDouglis AT&T研究室--研究180公園Ave、部屋B-137 Florham公園、ニュージャージー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
Saarbruecken、ドイツコンピュータサイエンス部の不-Stadtwaldのアーニャフェルドマン大学、Geb。 36.1 ジマー310D-66123 Saarbruecken、ドイツ
EMail: anja@cs.uni-sb.de
メール: anja@cs.uni-sb.de
Mogul, et al. Standards Track [Page 47] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[47ページ]RFC3229デルタのコード化
Yaron Y. Goland
ヤロンY.Goland
Email: yaron@goland.org
メール: yaron@goland.org
Arthur van Hoff Marimba, Inc. 440 Clyde Avenue Mountain View, CA 94043, U.S.A.
マウンテンビュー、アーサーバンホフマリンバ社440クライドAvenueカリフォルニア 94043、米国
Phone: 1 650 930 5283 EMail: avh@marimba.com
以下に電話をしてください。 1 5283年の650 930メール: avh@marimba.com
Daniel M. Hellerstein Economic Research Service, USDA 1909 Franwall Ave, Wheaton MD 20902
ダニエルM.Hellerstein経済調査部、USDA1909Franwall Ave、ウィートンMD 20902
Phone: 1 202 694-5613 or 1 301 649-4728 EMail: danielh@crosslink.net or webmaster@srehttp.org
以下に電話をしてください。 1 202 694-5613か1 301 649-4728メール: danielh@crosslink.net かウェブマスター@srehttp.org
Mogul, et al. Standards Track [Page 48] RFC 3229 Delta encoding in HTTP January 2002
ムガール人、他 HTTP2002年1月の規格Track[48ページ]RFC3229デルタのコード化
17 Full Copyright Statement
17 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Mogul, et al. Standards Track [Page 49]
ムガール人、他 標準化過程[49ページ]
一覧
スポンサーリンク