13.1.1 Cache Correctness

A correct cache MUST respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see sections 13.2.5, 13.2.6, and 13.12) which meets one of the following conditions:

• 1. It has been checked for equivalence with what the origin server would have returned by revalidating the response with the origin server (section 13.3);
• 2. It is "fresh enough" (see section 13.2). In the default case, this means it meets the least restrictive freshness requirement of the client, origin server, and cache (see section 14.9); if the origin server so specifies, it is the freshness requirement of the origin server alone.

正しいキャッシュは、要求に対して、その要求に対して適切である、 条件

• 応答を起源鯖で再検証したら起源鯖が返すであろうものとの同等性を検査していること
• 「十分新しい」こと。既定の場合では、これはクライアント, 起源鯖, およびキャッシュの最低制限新鮮性要件を満たすことを意味します。 起源鯖がそう指定していれば、これは起源鯖の新鮮性要件だけです。

のうちの一つを満たす、 そのキャッシュが持つ一番新しい応答でもって応答しなければなりません。

• 4. 3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or error (4xx or 5xx) response message.

• 適切な 304 (未修正), 305 (串再指向), または誤り (4xx または 5xx) 応答メッセージである。

If the cache can not communicate with the origin server, then a correct cache SHOULD respond as above if the response can be correctly served from the cache; if not it MUST return an error or warning indicating that there was a communication failure.

キャッシュが起源鯖と通信できない場合には、正しいキャッシュは、 応答をキャッシュから正しく支給することができるなら、 上述のように応答するべきです。できないなら、 キャッシュは通信に失敗したことを示す誤りまたは警告を返さなければなりません。

If a cache receives a response (either an entire response, or a 304 (Not Modified) response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache SHOULD forward it to the requesting client without adding a new Warning (but without removing any existing Warning headers). A cache SHOULD NOT attempt to revalidate a response simply because that response became stale in transit; this might lead to an infinite loop. An user agent that receives a stale response without a Warning MAY display a warning indication to the user.

キャッシュが通常なら要求しているクライアントに転送するところの応答 (完全な応答か、または 304 (未修正) 応答のいずれか) を受信した場合で、受信した応答が既に新鮮でない時には、 キャッシュは新しい Warning を追加せずに (しかし既存の Warning 頭を削除することはなしに) 要求しているクライアントにこれを転送するべきです。 キャッシュは、単にこの応答は輸送の途中に腐敗したのですから、 これを再検証しようと試みるべきではありません。 そうすると無限循環に陥るかもしれません。 Warning のない腐った応答を受信した利用者エージェントは利用者に警告を表示して構いません。

13.1.2 Warnings

Whenever a cache returns a response that is neither first-hand nor "fresh enough" (in the sense of condition 2 in section 13.1.1), it must MUST attach a warning to that effect, using a Warning response-header general-header. The Warning header and the currently defined warnings are described in section 14.46. This The warning allows clients to take appropriate action.]]

キャッシュが初手 (直接) でも「十分新鮮」 (13.1.1 の条件 2 の意味で。) でもない応答を返す時はいつも、その施行に警告を Warning 応答一般頭を使って添付しなければなりません。Warning 頭および現在定義されている警告は 14.46 で説明しています。この警告はクライアントが適切な動作を取ることを可能とします。

Warnings may MAY be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguish these responses from true failures.

警告は、他の、キャッシュ関係やその他の目的に使っても構いません。 誤り状態符号ではなく警告を使うことで、その応答を真の失敗から区別します。

Warnings are assigned numbers between 0 and 99 three digit warn-codes. This specification defines the code numbers and meanings of each currently assigned warnings, allowing a client or cache to take automated action in some (but not all) cases. The first digit indicates whether the Warning MUST or MUST NOT be deleted from a stored cache entry after a successful revalidation:

警告には0〜99 の間の数字3桁警告符号を割当てます。この仕様書は符号番号とそれぞれの現在割当てられている警告の意味を定義し、クライアントやキャッシュが幾つかの (しかし全てではない) 場合に自動動作を取ることを可能とします。 最初の数字は Warning を成功裏再検証の後に蓄積キャッシュ項目から削除しなければならないかまたは削除してはならないかを示します。

Warnings also carry a warning text. The text may MAY be in any appropriate natural language (perhaps based on the client's Accept headers), and include an optional OPTIONAL indication of what character set is used.

警告は警告文も運びます。文は任意の自然言語文 (たぶんクライアントの Accept 頭に基づく。) で記述子手構いませんし、 どの文字集合が使われているかの任意選択の表示を含めても構いません。

Multiple warnings may MAY be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number. For example, a server may might provide the same warning with texts in both English and Basque.

複数の警告を一つの応答に (起源鯖がであれ、キャッシュがであれ、) 添付して構いません。これには複数の警告が同じ符号番号である場合も含みます。 たとえば、鯖は英語とバスク語の両方で同じ警告を提供するかもしれません。

When multiple warnings are attached to a response, it may might not be practical or reasonable to display all of them to the user. This version of HTTP does not specify strict priority rules for deciding which warnings to display and in what order, but does suggest some heuristics.

複数の警告が一つの応答に添付されている時は、 その全てを利用者に表示するのは実用的・合理的ではないかもしれません。 この版の HTTP は、どの警告をどの順で表示するかを決める厳密な優先規則は規定しませんが、 少しばかり発見的方法を提案しておきます。

13.1.3 Cache-control Mechanisms

The basic cache mechanisms in HTTP/1.1 (server-specified expiration times and validators) are implicit directives to caches. In some cases, a server or client may might need to provide explicit directives to the HTTP caches. We use the Cache-Control header for this purpose.

HTTP/1.1 の基本キャッシュ機構 (鯖指定満期時刻・検証子) はキャッシュに対する暗示的指令です。場合によっては、 鯖またはクライアントは HTTP キャッシュに明示的に指令を提供する必要があるかもしれません。

The Cache-Control header allows a client or server to transmit a variety of directives in either requests or responses. These directives typically override the default caching algorithms. As a general rule, if there is any apparent conflict between header values, the most restrictive interpretation should be is applied (that is, the one that is most likely to preserve semantic transparency). However, in some cases, Cache-Control cache-control directives are explicitly specified as weakening the approximation of semantic transparency (for example, "max-stale" or "public").

Cache-Control 頭を使ってクライアントまたは鯖が要求または応答で種々の指令を伝えることができます。 そうした指令は、典型的に、既定のキャッシュ付け算法を上書きします。 一般的規則として、頭値間に明白な衝突があったら、 もっとも制限的な解釈 (すなわち、意味的透過性をもっとも保持しそうなもの) を適用します。 しかし、場合によっては、 cache-control 指令は意味的透過性の近似を弱めるために陽に指定することがあります (たとえば、 max-stale や public)。

The Cache-Control cache-control directives are described in detail in section 14.9.

cache-control 指令は14.9節で詳しく説明しています。

13.1.4 Explicit User Agent Warnings

Many user agents make it possible for users to override the basic caching mechanisms. For example, the user agent may might allow the user to specify that cached entities (even explicitly stale ones) are never validated. Or the user agent might habitually add "Cache-Control: max-stale=3600" to every request. The user agent should have to explicitly request SHOULD NOT default to either non-transparent behavior, or behavior that results in abnormally ineffective caching, but MAY be explicitly configured to do so by an explicit action of the user.

ほとんどの利用者エージェントは基本キャッシュ付け機構を利用者が上書きすることを可能としています。 たとえば、利用者エージェントは利用者がキャッシュした項目を (陽に腐敗しているものであっても) 決して検証しないように指定することを認めているかもしれません。 あるいは利用者エージェントはすべての要求にいつも Cache-Control: max-stale=3600 を加えるかもしれません。利用者エージェントは非等価動作または異常に非効率なキャッシュ付け結果になる動作を陽に要求しなければならないべきです既定とするべきではありませんが、利用者の明示的動作によって陽にそうするように設定しても構いません。

If the user has overridden the basic caching mechanisms, the user agent should SHOULD explicitly indicate to the user whenever this results in the display of information that might not meet the server's transparency requirements (in particular, if the displayed entity is known to be stale). Since the protocol normally allows the user agent to determine if responses are stale or not, this indication need only be displayed when this actually happens. The indication need not be a dialog box; it could be an icon (for example, a picture of a rotting fish) or some other visual indicator.

利用者が基本キャッシュ付け機構を上書きしている場合は、 利用者エージェントは、これが鯖の透過性要件に合致しないかもしれない情報を表示することになるとき (特に、表示する実体が腐っていると分かっているとき) には常に、 利用者に陽に示すべきです。 HTTP は通常利用者エージェントが応答が腐っているかどうかを決定することを認めていますから、 この標示はこれが実際に起こったときにのみ表示する必要があります。 標示は対話箱 (ダイアログ・ボックス) である必要はありません。 アイコン (たとえば、腐った魚の絵) や他の視覚的標識でもかまいません。

If the user has overridden the caching mechanisms in a way that would abnormally reduce the effectiveness of caches, the user agent should SHOULD continually display an indication indicate this state to the user (for example, by a display of a picture of currency in flames) so that the user does not inadvertently consume excess resources or suffer from excessive latency.

利用者がキャッシュの効率を異常に削減するようにキャッシュ付け機構を上書きしている場合は、 利用者エージェントはこの状態を利用者に継続的に (たとえば、燃えているお金の絵の表示で) 示すべきです。 そうすれば利用者が不注意で資源を過剰に消費したり、 過剰に待たされることがなくなります。

13.1.5 Exceptions to the Rules and Warnings

In some cases, the operator of a cache may MAY choose to configure it to return stale responses even when not requested by clients. This decision should ought not be made lightly, but may be necessary for reasons of availability or performance, especially when the cache is poorly connected to the origin server. Whenever a cache returns a stale response, it MUST mark it as such (using a Warning header). This allows enabling the client software to alert the user that there might be a potential problem.

場合によっては、キャッシュの運用者はクライアントからそう要求されていない場合であっても腐った応答を返すように設定することを選んでも構いません。 この決定は簡単に行うべきではありませんが、利用可能性や効率の理由から、 特にキャッシュと起源鯖の接続が貧しいときには、必要かもしれません。 キャッシュが腐った応答を返すときには、常に、そのように (Warning 頭を使って) マークしなければなりません。 こうすることでクライアント・ソフトウェアは利用者に問題のある可能性を警告できます。

It also allows the user agent to take steps to obtain a first-hand or fresh response. For this reason, a cache SHOULD NOT return a stale response if the client explicitly requests a first-hand or fresh one, unless it is impossible to comply for technical or policy reasons.

また、利用者エージェントが初手応答や新鮮応答を獲る手順を踏むことも可能になります。この理由から、キャッシュは、 クライアントが陽に初手応答や新鮮応答を要求しているときには、 技術的あるいは方針上の理由によって応じることが不可能な場合を除き、 腐った応答を返すべきではありません。

13.1.6 Client-controlled Behavior

While the origin server (and to a lesser extent, intermediate caches, by their contribution to the age of a response) are the primary source of expiration information, in some cases the client may might need to control a cache's decision about whether to return a cached response without validating it. Clients do this using several directives of the Cache-Control header.

起源鯖 (と、応答の齢の設定により、それより少程度ですが中間キャッシュ) は満期情報の一次情報源ですから、場合によってはクライアントはキャッシュした応答を検証せずに返すかどうかのキャッシュの決定を制御する必要があるかもしれません。 クライアントは Cache-Control 頭の幾つかの指令を使ってこれを行います。

A client's request may MAY specify the maximum age it is willing to accept of an unvalidated response; specifying a value of zero forces the cache(s) to revalidate all responses. A client may MAY also specify the minimum time remaining before a response expires. Both of these options increase constraints on the behavior of caches, and so cannot further relax the cache's approximation of semantic transparency.

クライアントの要求は検証していない応答を受入れる意思がある最大の齢を指定して構いません。 零という値を指定するとキャッシュ(群)がすべての応答を再検証することを強制します。 クライアントは応答の満期前に残っている最小時間を指定しても構いません。 両選択肢はキャッシュの動作の制約を増しますから、 キャッシュの意味的透過性の近似を更に緩和することはできません。

A client may MAY] also specify that it will accept stale responses, up to some maximum amount of staleness. This loosens the constraints on the caches, and so may might] violate the origin server's specified constraints on semantic transparency, but may might] be necessary to support disconnected operation, or high availability in the face of poor connectivity.

クライアントは、最大腐敗量を引上げることで、腐った応答を受入れることも指定して構いません。 これはキャッシュの制約を緩めますから、意味的透過性についての起源鯖の指定した制約に反するかもしれませんが、 非接続操作や貧しい接続性で高い利用可能性を支援するために必要かもしれません。

13.2.1 Server-Specified Expiration

HTTP caching works best when caches can entirely avoid making requests to the origin server. The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future, indicating that a response may MAY be used to satisfy subsequent requests. In other words, a cache can return a fresh response without first contacting the server.

HTTP キャッシュ付けは、キャッシュが起源鯖に要求を行うことを完全に避けることができれば最もよく働きます。 要求を避けるための第一の機構は、起源鯖が明示的に未来の満期時刻を提供し、 応答が後続の要求を満足するために使用して構わないと示します。 言い換えれば、キャッシュは最初に鯖に接触せずに新鮮んじゃ応答を返すことができます。

Our expectation is that servers will assign future explicit expiration times to responses in the belief that the entity is not likely to change, in a semantically significant way, before the expiration time is reached. This normally preserves semantic transparency, as long as the server's expiration times are carefully chosen.

鯖は、将来のある満期時刻に達するまでに実体が意味的に重大に変更されそうにないと信じて、 応答に陽に満期時刻を割当てることを期待しています。 これは、通常、鯖の満期時刻は注意深く選んだものなので、意味的透過性を護ります。

The expiration mechanism applies only to responses taken from a cache and not to first-hand responses forwarded immediately to the requesting client.

満期機構はキャッシュから取った応答にのみ適用し、要求しているクライアントに即座に転送される初手応答には適用しません。

If an origin server wishes to force a semantically transparent cache to validate every request, it may MAY assign an explicit expiration time in the past. This means that the response is always stale, and so the cache SHOULD validate it before using it for subsequent requests. See section 14.9.4 for a more restrictive way to force revalidation.

起源鯖が意味的等価キャッシュに要求毎に検証を強いたいのであれば、 過去の満期時刻を陽に割当てて構いません。これは、 その応答が常に腐敗しており、キャッシュは後続要求にこれを用いる前に検証するべきであることを意味します。 再検証を強いるより制限的な方法については19.9.4節をご覧下さい。

If an origin server wishes to force any HTTP/1.1 cache, no matter how it is configured, to validate every request, it should SHOULD use the "must-revalidate" Cache-Control cache-control directive (see section 14.9).

起源鯖が、どう設定されている HTTP/1.1 キャッシュにも要求毎に検証することを強いたいのなら、 must-revalidate キャッシュ制御指令を使用するべきです。

Servers specify explicit expiration times using either the Expires header, or the max-age directive of the Cache-Control header.

鯖は、 Expires 頭または Cache-Control 頭の max-age 指令を用いて陽に満期時刻を指定します。

An expiration time cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource is initiated. See section 13.13 for an explanation of the difference between caches and history mechanisms.

満期時刻は利用者エージェントにその表示を更新させたり資源を再読込みさせたりするために使用することはできません。 満期時刻の意味はキャッシュ付け機構にのみ適用され、 キャッシュ付け機構は資源に対する新しい要求が初期化された時にのみその資源の満期状態を検査する必要があります。 13.13節のキャッシュと履歴機構の違いの説明をご覧下さい。

13.2.2 Heuristic Expiration

Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on their results. Since heuristic expiration times may might compromise semantic transparency, they should be ought to used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible.

起源鯖は常に満期時刻を陽に提供するのではありませんから、 HTTP キャッシュは典型的に発見的満期時刻を割当てます。 他の頭欄値 (たとえば Last-Modified 時刻) を使ってそれっぽい満期時刻を見積もる算法を使います。 HTTP/1.1 仕様書は特定の算法を提供しませんが、 その結果の最悪の場合の制約は課します。発見的満期時刻は意味的透過性を曲げるかもしれませんから、 慎重に利用するべきであり、起源鯖も可能な限り満期時刻を陽に提供するよう勧めます。

13.2.3 Age Calculations

In order to know if a cached entry is fresh, a cache needs to know if its age exceeds its freshness lifetime. We discuss how to calculate the latter in section 13.2.4; this section describes how to calculate the age of a response or cache entry.

キャッシュした項目が新鮮かどうかを知るために、 キャッシュはその齢が新鮮寿命を超えているかを知る必要があります。 後者の計算方法は13.2.4で議論します。この節では応答やキャッシュ項目の齢の計算方法を記述します。

In this discussion, we use the term "now" to mean "the current value of the clock at the host performing the calculation." Hosts that use HTTP, but especially hosts running origin servers and caches, should SHOULD use NTP [28] or some similar protocol to synchronize their clocks to a globally accurate time standard.

この議論において、「今」という用語を、「計算を行うホストの時計の現在値」 の意味で使います。 HTTP を使用するホスト、特に起源鯖やキャッシュが動いているホストは、 時計を大域的に正確な時刻表準と同期させる、 NTP や同様のプロトコルを使用するべきです。

Also note that HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response was generated (see section 14.18). We use the term "date_value" to denote the value of the Date header, in a form appropriate for arithmetic operations.

HTTP/1.1 は起源鯖が応答毎に可能であればその応答が生成された時刻を与える Date 頭を送信することも要求します。 date_value という用語は、算術演算に適当な形式の Date 頭の値を指して使います。

HTTP/1.1 uses the Age response-header to help convey the estimated age information between caches of the response message when obtained from a cache. The Age header field value is the sender's cache's estimate of the amount of time since the response was generated at or revalidated by the origin server. In the case of a cached response that has been revalidated with the origin server, the Age value is based on the time of revalidation, not of the original response.

HTTP/1.1 は、キャッシュ間で応答メッセージをキャッシュから得たときにその齢の見積もりを伝達するのを助ける Age 応答頭を使用します。 Age 欄値は起源鯖で応答が生成または再検証されてからの時間量のキャッシュの見積もりです。起源鯖で再検証したキャッシュした応答の場合は、 Age 値は起源応答の時刻ではなく、再検証の時刻に基づきます。

In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus the amount of time it has been in transit along network paths.

本質的に、 Age 値は応答が応答が起源鯖からの経路上のキャッシュそれぞれに滞在した時間の和に、 ネットワーク経路に沿って転送された時間量を足したものです。

We use the term "age_value" to denote the value of the Age header, in a form appropriate for arithmetic operations.

age_value という用語は、算術演算に適当な形式の Age 頭の値を指して使います。

A response's age can be calculated in two entirely independent ways:

• 1. now minus date_value, if the local clock is reasonably well synchronized to the origin server's clock. If the result is negative, the result is replaced by zero.
• 2. age_value, if all of the caches along the response path implement HTTP/1.1.

応答の齢は二つのまったく独立な方法で計算できます。

• 今引く date_value、ただし局所時計が起源鯖の時計と十分よく同期されている場合。 結果が負であれば、結果を零で置換する。
• age_value、ただし応答経路上のキャッシュがすべて HTTP/1.1 を実装している場合。

Given that we have two independent ways to compute the age of a response when it is received, we can combine these as

• corrected_received_age = max(now - date_value, age_value)

応答を受信した時にその齢を計算する二つの独立な方法があったとして、 それを

• corrected_received_age = max(今 − date_value, age_value)

and as long as we have either nearly synchronized clocks or all-HTTP/1.1 paths, one gets a reliable (conservative) result.

のように組合せることができます。 そして、同期時計を持っているか、またはすべて HTTP/1.1 の経路を持っていれば、 当てになる (保守的な) 結果が得られます。

Because of network-imposed delays, some significant interval may might pass from between the time that a server generates a response and the time it is received at the next outbound cache or client. If uncorrected, this delay could result in improperly low ages.

ネットワークによる遅延のため、鯖が応答を生成した時刻と次の外向きキャッシュ・クライアントが受信した時刻は大きな差があり得ます。 修正が行われなければ、この遅延のせいで不適切に小さな齢となりかねません。

Because the request that resulted in the returned Age value must have been initiated prior to that Age value's generation, we can correct for delays imposed by the network by recording the time at which the request was initiated. Then, when an Age value is received, it MUST be interpreted relative to the time the request was initiated, not the time that the response was received. This algorithm results in conservative behavior no matter how much delay is experienced. So, we compute:

• corrected_initial_age = corrected_received_age + (now - request_time)

返される Age 値になる要求はその Age 値の生成の前に初期化されていなければなりませんから、 その要求を初期化した時刻を記録しておくことでネットワークによる遅延を修正できます。 Age 値を受信した時、この値は、応答を受信した時刻ではなく、 要求が初期化された時刻に対するものとして解釈しなければなりません。 この算法により、どれだけの遅延があろうとも、 保守的に振舞った結果が得られます。ですから、

• corrected_initial_age = corrected_received_age + (今 − request_time)

where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.

と計算できます。ここで、 request_time はこの応答を引出した要求を送った (局所時計による) 時刻です。

Summary of age calculation algorithm, when a cache receives a response:

      /*
       * age_value
       *      is the value of Age: header received by the cache with
       *              this response.
       * date_value
       *      is the value of the origin server's Date: header
       * request_time
       *      is the (local) time when the cache made the request
       *              that resulted in this cached response
       * response_time
       *      is the (local) time when the cache received the
       *              response
        * now
        *      is the current (local) time
        */
       apparent_age = max(0, response_time - date_value);
       corrected_received_age = max(apparent_age, age_value);
       response_delay = response_time - request_time;
       corrected_initial_age = corrected_received_age + response_delay;
       resident_time = now - response_time;
       current_age   = corrected_initial_age + resident_time;

齢計算算法をまとめると、キャッシュが応答を受信した時、

齢値

キャッシュがこの応答で受信した Age: 頭の値。

日付値

起源鯖の Date: 頭の値。

要求時刻

このキャッシュした応答となった要求をキャッシュが行った(局所)時刻。

応答時刻

キャッシュが応答を受信した(局所)時刻。

今

現在(局所)時刻

• 見かけの齢 = 最大 (0, 応答時刻 − 日付値);
• 正しい受信齢 = 最大 (見かけの齢, 齢値);
• 応答遅延 = 応答時刻 − 要求時刻;
• 正しい初期齢 = 正しい受信齢 + 応答遅延;
• 滞在時間 = 今 − 応答時刻;
• 現在齢 = 正しい初期齢 + 滞在時間;

13.2.4 Expiration Calculations

In order to decide whether a response is fresh or stale, we need to compare its freshness lifetime to its age. The age is calculated as described in section 13.2.3; this section describes how to calculate the freshness lifetime, and to determine if a response has expired. In the discussion below, the values can be represented in any form appropriate for arithmetic operations.

応答が新鮮か腐っているかを決めるためには、 応答の齢に対する新鮮寿命を計算する必要があります。 齢は13.2.3節で説明したように計算します。 この節はどう新鮮寿命を計算し、応答が満期であるかを決定するかを説明します。 以後の議論で、値は算術演算に適当な任意の形式で表現できます。

We use the term "expires_value" to denote the value of the Expires header. We use the term "max_age_value" to denote an appropriate value of the number of seconds carried by the "max-age" directive of the Cache-Control header in a response (see section 14.10 14.9.3).

用語「満期値」は、 Expires 頭の値を示します。 用語「最大齢値」は、応答の Cache-Control 頭の max-age 指令により伝達される秒数の適切な値を示します。

The max-age directive takes priority over Expires, so if max-age is present in a response, the calculation is simply:

• freshness_lifetime = max_age_value

max-age 指令は Expires より優先しますから、 max-age が応答にある場合は、計算は単純です。

• 新鮮寿命 = 最大齢値

Otherwise, if Expires is present in the response, the calculation is:

• freshness_lifetime = expires_value - date_value

そうでなければ、 Expires が応答にあれば、 計算は次のようになります。

• 新鮮寿命 = 満期値 − 日付値

Note that neither of these calculations is vulnerable to clock skew, since all of the information comes from the origin server.

どちらの計算も、すべての情報は起源鯖から来たものですから、 時計のずれに脆弱ではないことに注意してください。

If neither none of Expires, nor Cache-Control: max-age, or Cache-Control: s-maxage (see section 14.9.3) appears in the response, and the response does not include other restrictions on caching, the cache MAY compute a freshness lifetime using a heuristic. If the value is greater than 24 hours, the The cache must MUST attach Warning 113 to any response whose age is more than 24 hours if such warning has not already been added.

Expires, Cache-Control: max-age, Cache-Control: s-maxage のいずれもが応答になく、 応答がキャッシュ付けについての他の制限を含んでいなければ、 キャッシュは新鮮寿命を発見的に計算して構いません。 値が24時間より大きいなら、 キャッシュは齢が24時間を超す応答に Warning 113 を (既に追加されていなければ) 添付しなければなりません。

Also, if the response does have a Last-Modified time, the heuristic expiration value SHOULD be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.

また、応答が Last-Modified 時刻を持てば、 発見的満期値はその時刻からの時間の何割かを超すべきではありません。 その割合の典型的な設定は10%でしょう。

The calculation to determine if a response has expired is quite simple:

• response_is_fresh = (freshness_lifetime > current_age)

応答が満期しているかどうかの決定の計算はきわめて単純で、

• 応答は新鮮 = (新鮮寿命 > 現在齢)

です。

13.2.5 Disambiguating Expiration Values

Because expiration values are assigned optimistically, it is possible for two caches to contain fresh values for the same resource that are different.

満期値は楽天的に割当てられますから、二つのキャッシュが同じ資源の異なった新鮮値を持っていることがあり得ます。

If a client performing a retrieval receives a non-first-hand response for a request that was already fresh in its own cache, and the Date header in its existing cache entry is newer than the Date on the new response, then the client MAY ignore the response. If so, it MAY retry the request with a "Cache-Control: max-age=0" directive (see section 14.9), to force a check with the origin server.

取出しを行うクライアントが、要求に対する非初手応答を受け取った時で、 自身のキャッシュで既に新鮮であった場合で、 その既存のキャッシュ項目の Date 頭が新しい応答の Date よりも新しい時には、 クライアントはその応答を無視して構いません。 そうする場合には、起源鯖での検査を強制するため、 Cache-Control: max-age=0 指令つきで要求を再試行して構いません。

If a cache has two fresh responses for the same representation with different validators, it MUST use the one with the more recent Date header. This situation may might arise because the cache is pooling responses from other caches, or because a client has asked for a reload or a revalidation of an apparently fresh cache entry.

キャッシュが同じ表現で異なる検証子の二つの新鮮な応答を持っている時は、 Date 頭のより新しい方を使わなければなりません。 この状況は、キャッシュが他のキャッシュからの応答を溜めている場合や、 クライアントが明らかに新鮮なキャッシュ項目の再読込みや再検証を依頼している場合に起こり得ます。

13.2.6 Disambiguating Multiple Responses

Because a client may might be receiving responses via multiple paths, so that some responses flow through one set of caches and other responses flow through a different set of caches, a client may might receive responses in an order different from that in which the origin server sent them. We would like the client to use the most recently generated response, even if older responses are still apparently fresh.

クライアントは応答を複数の経路から受信するかもしれませんから、 ある応答はあるキャッシュの集合を通じて流れ、 他の応答は異なるキャッシュの集合を通じて流れ、 クライアントは起源鯖が送信したものとは異なる順番で応答を受信するかもしれません。 クライアントは、古い方の応答が明らかにまだ新鮮であったとしても、 一番新しく生成された応答を使用してほしいです。

Neither the entity tag nor the expiration value can impose an ordering on responses, since it is possible that a later response intentionally carries an earlier expiration time. However, the HTTP/1.1 specification requires the transmission of Date headers on every response, and the Date values are ordered to a granularity of one second. The Date values are ordered to a granularity of one second.

実体札も満期値も、応答の順序を示すことはできません。 後の応答が意図的に早い満期時刻を伝えることが可能であるからです。しかし、 HTTP/1.1 仕様書は各応答で Date 頭を転送することを要求しており、 Date 値は一秒の粒度で順序付けられています。 Date 値は一秒の粒度で順序付けられています。

When a client tries to revalidate a cache entry, and the response it receives contains a Date header that appears to be older than the one for the existing entry, then the client SHOULD repeat the request unconditionally, and include

クライアントがキャッシュ項目の再検証を試みる時で、 その受信した応答が既存の項目のものよりも古い Date 頭を含んでいる時には、クライアントは要求を非条件付で、 中間キャッシュがその複製を直接起源鯖に検証することを強制するために

• Cache-Control: max-age=0

to force any intermediate caches to validate their copies directly with the origin server, or

を、または中間キャッシュが起源鯖から新しい複製を得ることを強制するために

• Cache-Control: no-cache

to force any intermediate caches to obtain a new copy from the origin server.

を含めて繰り返すべきです。

If the Date values are equal, then the client may MAY use either response (or may MAY, if it is being extremely prudent, request a new response). Servers MUST NOT depend on clients being able to choose deterministically between responses generated during the same second, if their expiration times overlap.

Date 値が等しければ、クライアントはどちらの応答を使っても構いません (し、極めて慎重にするのであれば、新しい応答を要求しても構いません)。 鯖は、クライアントが同じ秒に生成された応答を、満期時刻が重なっている時、 決定的に選ぶことができるのに依存してはなりません。

13.3.1 Last-modified Last-Modified Dates

The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered to be valid if the entity has not been modified since the Last-Modified value.

Last-Modified 実体頭欄値はしばしばキャッシュ検証子として使われます。 単純な言葉で言えば、キャッシュ項目はその実体が Last-Modified 値から修正されていなければ妥当と考えられます。

13.3.2 Entity Tag Cache Validators

The ETag entity-header response-header field value, an entity tag, provides for an "opaque" cache validator. This may might allow more reliable validation in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, or where the origin server wishes to avoid certain paradoxes that may might arise from the use of modification dates.

ETag 応答頭欄値である実体札は、 「不透明」なキャッシュ検証子を提供します。これで、 修正日を蓄積するのが不便である状況、 HTTP 日付値の一秒単位の解像度が十分でない状況や起点鯖が修正日の使用によって起こり得るある種の逆接を避けたいと思う状況でより当てになる検証を行えます。

Entity Tags are described in section 3.11. The headers used with entity tags are described in sections 14.20, 14.25, 14.19, 14.24, 14.26 and 14.43 14.44.

実体札は3.11節で説明しています。 実体札を使う頭は各節で説明しています。

13.3.3 Weak and Strong Validators

Since both origin servers and caches will compare two validators to decide if they represent the same or different entities, one normally would expect that if the entity (the entity-body or any entity-headers) changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong validator."

起点鯖とキャッシュの両者が2つの検証子を比較して同じ実体をあらわしているのか異なる実体をあらわしているのかを決めますから、 実体 (entity-body または entity-header のどれか) が何らかの形で変更されたら、関連付けられた検証子も変わるであろうことが通常期待できます。 これが真であるとき、この検証子を強い検証子と呼びます。

However, there may might be cases when a server prefers to change the validator only on semantically significant changes, and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator."

しかし、鯖が意味的に有意な変更においてのみ検証子を変更し、 実体の意味のない側面での変更の時には検証子は変更しないようにしたい場合というのもあるかもしれません。 資源が変更されたときに必ずしも変更されない検証子は弱い検証子です。

Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.

実体札は通常「強い検証子」ですが、 HTTP は実体札が「弱い」 ものであると札付けする仕組みを用意しています。 強い検証子は実体のほんのわずかな変更でも必ず変わるもので、 弱い値は実態の意味の変更の時には必ず変わるものと考えることができます。 あるいは、強い検証子は特定の実体の識別子の一部であり、 弱い検証子は意味的に等価な実体群の集合の識別子の一部であると考えることもできます。

Note: One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.

注意: 強い検証子の一つの例は、実体が変更されるたびに増える、 安定した記憶装置上の整数です。

An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible that the resource may might be modified twice during a single second.

実体の修正時刻は、一秒の粒度で表現されていれば、 弱い検証子とすることができます。といいますのは、 資源が一秒の間に二度修正されるかもしれないからです。

Support for weak validators is optional;. However however, weak validators allow for more efficient caching of equivalent objects; for example, a hit counter on a site is probably good enough if it is updated every few days or weeks, and any value during that period is likely "good enough" to be equivalent.

弱い検証子への対応は任意です。しかし、 弱い検証子で等価な物体のより効率的なキャッシュ付けが可能になります。 たとえば、サイトの打撃計数器は、何日間か何週間かごとに更新されて、 その期間中の値がすべて等価であるのに「十分良い」ようであれば、 おそらく弱い検証子で十分良いでしょう。

A "use" of a validator is either when a client generates a request and includes the validator in a validating header field, or when a server compares two validators.

検証子の「使用」は、クライアントが要求を生成し、 検証子を検証頭欄に含めるときか、または鯖が2つの検証子を比較するときのいずれかです。

Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality of an entity. For example, either kind is usable for a conditional GET of a full entity. However, only a strong validator is usable for a sub-range retrieval, since otherwise the client may might end up with an internally inconsistent entity.

強い検証子は任意の文脈で使用可能です。 弱い検証子は実体の実際の同等性に依存しない文脈でのみ使用可能です。たとえば、 完全な実体の条件付 GET ではどちらの種類も使用可能です。 しかし、部分範囲取出しでは、 弱い検証子を使うとクライアントが内部的に不整合な実体を得てしまうことになるかもしれませんから、 強い検証子だけが使用可能です。

The only function that the HTTP/1.1 protocol defines on validators is comparison. There are two validator comparison functions, depending on whether the comparison context allows the use of weak validators or not:

• o - The strong comparison function: in order to be considered equal, both validators must MUST be identical in every way, and neither may both MUST NOT be weak.
• o - The weak comparison function: in order to be considered equal, both validators must MUST be identical in every way, but either or both of them may MAY be tagged as "weak" without affecting the result.

HTTP/1.1 プロトコルが検証子について定義する関数は比較だけです。 検証子比較関数は、比較する文脈が弱い検証子を認めているかどうかによって2種類あります。

• 強い比較関数: 等しいと考えられるためには、 両方の検証子がすべてにおいて同一でなければなりませんし、 両者共に弱い検証子であってはなりません。
• 弱い比較関数: 等しいと考えられるためには、 両方の検証子がすべてにおいて同一でなければなりませんが、 検証子の一方または両方が「弱い」と札付けされていても構いませんで、 これは結果には影響しません。

An entity tag is strong unless it is explicitly tagged as weak. Section 3.11 gives the syntax for entity tags.

実体札は、陽に弱いと札付けされていない限り強い検証子です。 実体札の構文は3.11節で与えています。

A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules:

• o - The validator is being compared by an origin server to the actual current validator for the entity and,
• o - That origin server reliably knows that the associated entity did not change twice during the second covered by the presented validator.

Last-Modified 時刻は、要求で検証子として使われるときは、 次の規則を用いて強いと演繹することが可能でない限り、暗に弱いものとします。

• 検証子が起点鯖によって実体の現在の実際の値と比較し、
• 起点鯖は関連付けられた実体が示された検証子の覆う範囲で一秒間に二度変更されていないと確実に知っている場合

or

• o - The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header, because the client has a cache entry for the associated entity, and
• o - That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
• o - The presented Last-Modified time is at least 60 seconds before the Date value.

または

• 検証子はクライアントが If-Modified-Since または If-Unmodified-Since 頭で使用しているものである場合 (クライアントは関連付けられた実体のキャッシュ項目を持っているから)、および
• キャッシュ項目が Date 値を含んでおり、 それが起点鯖のもとの応答を送った時刻を与えており、かつ
• 示された Last-Modified 時刻は Date 値の最低60秒前である

or

• o - The validator is being compared by an intermediate cache to the validator stored in its cache entry for the entity, and
• o - That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
• o - The presented Last-Modified time is at least 60 seconds before the Date value.

または

• 検証子はその実体のキャッシュ項目に蓄積された検証子に対して中間キャッシュで比較され、かつ
• そのキャッシュ項目は Date 値を含んでおり、 それが起点鯖のもとの応答の時刻を与えており、かつ
• 示された Last-Modified 時刻は Date 値の最低60秒前である

This method relies on the fact that if two different responses were sent by the origin server during the same second, but both had the same Last-Modified time, then at least one of those responses would have a Date value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks, or at somewhat different times during the preparation of the response. An implementation may MAY use a value larger than 60 seconds, if it is believed that 60 seconds is too short.

この方式は、起点鯖が同じ秒の間に2つの異なる応答を送ったとした場合に、 その2つの応答の少なくても一つは Last-Modified 時刻と等しい Date 値を持っているであろうという事実に拠っています。 勝手な60秒の制限は、 Date 値と Last-Modified 値が異なる時計で生成しているか、または応答の準備の過程で何か異なる時刻を使っている可能性からです。 実装は、60秒が短すぎると信ずる場合には、60秒より大きな値を使って構いません。

If a client wishes to perform a sub-range retrieval on a value for which it has only a Last-Modified time and no opaque validator, it may MAY do this only if the Last-Modified time is strong in the sense described here.

クライアントが Last-Modified 時刻のみを持っていて不透明検証子を持っていない値の部分範囲取出しを行おうと思っているときは、 これを Last-Modified 時刻がここで説明した意味で強いときのみ行って構いません。

A cache or origin server receiving a cache-conditional request, other than a full-body GET request, MUST use the strong comparison function to evaluate the condition.

完全本体 GET 要求ではない条件付要求を受信したキャッシュや起点鯖は、 状況を評価するために強い比較関数を使用しなければなりません。

These rules allow HTTP/1.1 caches and clients to safely perform sub-range retrievals on values that have been obtained from HTTP/1.0 servers.

これらの規則によって、 HTTP/1.1 のキャッシュと串が安全に HTTP/1.0 鯖から得た値について部分範囲取出しを行うことができます。

13.3.4 Rules for When to Use Entity Tags and Last-modified Last-Modified Dates

We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types should ought to be used, and for what purposes.

種々の検証子の種類をいつ、どのように使用するべきであるのかについて起点鯖、 クライアント、キャッシュに規則と勧告を示します。

HTTP/1.1 origin servers:

• o - SHOULD send an entity tag validator unless it is not feasible to generate one.
• o - MAY send a weak entity tag instead of a strong entity tag, if performance considerations support the use of weak entity tags, or if it is unfeasible to send a strong entity tag.
• o - SHOULD send a Last-Modified value if it is feasible to send one, unless the risk of a breakdown in semantic transparency that could result from using this date in an If-Modified-Since header would lead to serious problems.

HTTP/1.1 起点鯖は、

• 実体札検証子を生成できない場合を除いて、送信するべきです。
• 効率を考えると弱い実体札を使用した方が良いか、 または強い実体札を送信することができない場合には、 強い実体札の代わりに弱い実体札を送信しても構いません。
• Last-Modified 値を送信することができる時には、 意味的透過性を壊してしまって If-Modified-Since 頭でその日付を使うと大きな問題を招きかねない虞のある場合を除き、 Last-Modified 値を送信するべきです。

In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity tag and a Last-Modified value.

言い換えれば、 HTTP/1.1 起点鯖の望ましい振る舞いは、 強い実体札と Last-Modified 値の両方を送信することです。

In order to be legal, a strong entity tag MUST change whenever the associated entity value changes in any way. A weak entity tag SHOULD change whenever the associated entity changes in a semantically significant way.

強い実体札は、関連付けられた実体値が何らかの形で変更されたときには必ず変更しなければ合法ではありません。 弱い実体札は関連付けられた実体が意味的に重大な変更があったときには必ず変更するべきです。

Note: in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries may might persist for arbitrarily long periods, regardless of expiration times, so it may might be inappropriate to expect that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the past.

注意: 意味的に等価なキャッシュ付けを行うために、 起点鯖は特定の強い実体札値を2つの異なる実体に再利用したり、 特定の弱い実体札値を2つの意味的に異なる実体に再利用したりすることを避けなければなりません。 キャッシュ項目は満期時刻にかかわらず任意の期間持続しているかもしれませんから、 キャッシュが過去のいつかの時点で得た検証子を使って項目を検証しようとすることはなかろうと期待することは不適切です。

HTTP/1.1 clients:

• o - If an entity tag has been provided by the origin server, MUST use that entity tag in any cache-conditional request (using If-Match or If-None-Match).
• o - If only a Last-Modified value has been provided by the origin server, SHOULD use that value in non-subrange cache-conditional requests (using If-Modified-Since).
• o - If only a Last-Modified value has been provided by an HTTP/1.0 origin server, MAY use that value in subrange cache-conditional requests (using If-Unmodified-Since:). The user agent should SHOULD provide a way to disable this, in case of difficulty.
• o - If both an entity tag and a Last-Modified value have been provided by the origin server, SHOULD use both validators in cache-conditional requests. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.

HTTP/1.1 クライアントは、

• 実体札が起点鯖により提供されている場合は、その実体札を (If-Match や If-None-Match を使った) すべてのキャッシュ条件付要求に使用しなければなりません。
• Last-Modified 値だけが起点鯖により提供されている場合は、その値を (If-Modified-Since を使った) 非部分範囲キャッシュ条件付要求に使用しなければなりません。
• Last-Modified 値だけが HTTP/1.0 起点鯖により提供されている場合は、 その値を (If-Unmodified-Since: を使った) 部分範囲キャッシュ条件付要求で使って構いません。 利用者エージェントは、支障がある場合のため、これを無効化する方法を提供するべきです。
• 実体札と Last-Modified 値の両方が起点鯖により提供されている場合は、 両方の検証子をキャッシュ条件付要求で使用するべきです。 こうすることで HTTP/1.1 キャッシュと HTTP/1.1 キャッシュの両方が適当に応答できます。

A note on rationale: Note: The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative assumptions about the validators they receive.

注意: これらの規則の裏にある一般原則は、 HTTP/1.1 の鯖とクライアントは応答と要求で利用できる冗長でないできるだけ多くの情報を転送するべきということです。 この情報を受信した HTTP/1.1 システムは、 受信した検証子についての最も保守的な過程を行います。

HTTP/1.0 clients and caches will ignore entity tags. Generally, last-modified values received or used by these systems will support transparent and efficient caching, and so HTTP/1.1 origin servers should provide Last-Modified values. In those rare cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then HTTP/1.1 origin servers should not provide one.

HTTP/1.0 のクライアントとキャッシュは実体札を無視します。 通常、これらのシステムが受信または使用する last-modified 値は透明で有効なキャッシュ付けを支援しますから、 HTTP/1.1 起点鯖は Last-Modified 値を提供するべきです。 HTTP/1.0 システムが Last-Modified 値を使用していて重大な問題になり得るという稀な場合には、 HTTP/1.1 起点鯖は Last-Modified を提供するべきではありません。

13.3.5 Non-validating Conditionals

The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality would open up a can of worms. Thus, comparisons of any other headers (except Last-Modified, for compatibility with HTTP/1.0) are never used for purposes of validating a cache entry.

実体札の裏にある原則は、サービス著者だけが適切なキャッシュ検証機構を選択できるだけ十部よく資源の意味を知っており、 バイト等価性以上の複雑な検証子比較関数の仕様が害虫の缶を開けることになるでろうということです。 従って、他の頭 (HTTP/1.0 との互換性のため Last-Modified を除く。) の比較がキャッシュ項目の検証の目的で使用されることは決してありません。

13.5.1 End-to-end and Hop-by-hop Headers

For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories:

キャッシュと非キャッシュ付け串の振舞いを定義するために、 HTTP 頭群を2種類に分けます。

• o - End-to-end headers, which must be are transmitted to the ultimate recipient of a request or response. End-to-end headers in responses must MUST be stored as part of a cache entry and MUST be transmitted in any response formed from a cache entry.
• o - Hop-by-hop headers, which are meaningful only for a single transport-level connection, and are not stored by caches or forwarded by proxies.

末端対末端頭

要求や応答の最終受領者に転送されます。 応答中の末端対末端頭群はキャッシュ項目の一部として蓄積しなければなりませんし、 キャッシュ項目から形成されるいかなる応答でも転送しなければなりません。

ホップ毎頭

単一の輸送層接続でのみ意味があり、 キャッシュに蓄積されたり串により転送されたりしません。

The following HTTP/1.1 headers are hop-by-hop headers:

次の HTTP/1.1 頭群はホップ毎頭です。

• o - Connection
• o - Keep-Alive
• o Public
• o - Proxy-Authenticate
• - Proxy-Authorization
• - TE
• - Trailers {Errata で修正}
• o - Transfer-Encoding
• o - Upgrade

All other headers defined by HTTP/1.1 are end-to-end headers.

HTTP/1.1 で定義している他のすべての頭は末端対末端頭です。

13.5.2 Non-modifiable Headers

Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers. A cache or non-caching transparent proxy SHOULD NOT modify an end-to-end header unless the definition of that header requires or specifically allows that.

HTTP/1.1 プロトコルのいくつかの機能、たとえば要約認証は、 ある種の末端対末端頭の値に依存します。 透過串が末端対末端頭を修正することは、 その頭の定義が要求しているか、または認めると規定している場合を除き、 するべきではありません。

A cache or non-caching transparent proxy MUST NOT modify or add any of the following fields in a response that contains the no-transform Cache-Control directive, or in any request request or response, and it MUST NOT add any of these fields if not already present:

透過串は、要求や応答の次のいずれの欄をも修正してはなりませんし、 既に存在する場合にはいずれも追加してはなりません。

• o - Content-Encoding
• o Content-Length
• o - Content-Range
• o - Content-Type

A cache or non-caching non-transparent proxy MAY modify or add these fields in a response to a message that does not include no-transform, but if it does so, it MUST add a Warning 214 (Transformation applied) if one does not already appear in the response message (see section 14.46).

非透過串は、これらの欄を no-transform を含まないメッセージに追加したり修正したりしても構いませんが、 そうする場合には Warning 214 (変形適用済み) を (メッセージに既に存在しなければ) 追加しなければなりません。

Warning: unnecessary modification of end-to-end headers may might cause authentication failures if stronger authentication mechanisms are introduced in later versions of HTTP. Such authentication mechanisms may MAY rely on the values of header fields not listed here.

警告: 末端対末端頭の不必要な修正は、 新しい版の HTTP で強めの認証機構が導入された場合に認証が失敗することとなるかもしれません。 そのような認証機構はここに列していない頭欄の値に依存しても構いません。

13.5.3 Combining Headers

When a cache makes a validating request to a server, and the server provides a 304 (Not Modified) response or a 206 (Partial Content) response, the cache must then constructs a response to send to the requesting client.

キャッシュが要求を鯖に検証させる時で、 鯖が 304 (未修正) 応答または 206 (部分内容) 応答を提供した時には、キャッシュは、 要求しているクライアントに送信する応答を構築することとなります。

If the status code is 304 (Not Modified), the The cache uses the entity-body stored in the cache entry as the entity-body of this outgoing response. The end-to-end headers stored in the cache entry are used for the constructed response, except that any end-to-end headers provided in the 304 response MUST replace the corresponding headers from the cache entry. Unless the cache decides to remove the cache entry, it MUST also replace the end-to-end headers stored with the cache entry with corresponding headers received in the incoming response. If the status code is 206 (Partial Content) and the ETag or Last-Modified headers match exactly, the cache MAY combine the contents stored in the cache entry with the new contents received in the response and use the result as the entity-body of this outgoing response, (see 13.5.4).

状態符号が 304 (未修正) の時は、 キャッシュはキャッシュ項目に蓄積されている entity-body をこの外行きの応答の entity-body として使います。 状態符号が 206 (部分内容) で ETag 頭か Last-Modified 頭がキャッシュ項目に蓄積されている内容と正確に一致する場合は、 キャッシュはそのキャッシュ項目に蓄積されている内容を応答で受信した新しい内容と結合してこの外行きの応答の entity-body として使って構いません。

In other words, the set of end-to-end headers received in the incoming response overrides all corresponding end-to-end headers stored with the cache entry (except for stored Warning headers with warn-code 1xx, which are deleted even if not overridden). The cache may add Warning headers (see section 14.45) to this set.

言換えれば、受取った応答で受信した末端対末端頭の集合はすべてキャッシュ項目に蓄積されている対応する末端体末端頭で上書きします (但し Warning 頭で warn-code が 1xx の場合は、上書きしなくても削除します)。

Note: this rule allows an origin server to use a 304 (Not Modified) or a 206 (Partial Content) response to update any header associated with a previous response for the same entity or sub-ranges thereof, although it might not always be meaningful or correct to do so. This rule does not allow an origin server to use a 304 (not Not Modified) or a 206 (Partial Content) response to entirely delete a header that it had provided with a previous response.

参考: この規則は、同じ実体 (または同じ部分範囲) についての以前の応答に関連付けられた頭を更新するために起点鯖が 304 (未修正) 応答や 206 (部分内容) 応答を使うことができるようにしています。但し、 そうすることが常に意味のある正しいことであるとは限りません。 この規則は、以前の応答で提供した頭を完全に削除するために 304 (未修正) 応答や 206 (部分内容) 応答を使うことは認めていません。

13.5.4 Combining Byte Ranges

A response may might transfer only a subrange of the bytes of an entity-body, either because the request included one or more Range specifications, or because a connection was broken prematurely. After several such transfers, a cache may might have received several ranges of the same entity-body.

応答は、要求が一つ以上の Range 指定を含んでいるためか、 または接続が早いうちに壊れてしまったために、 entity-body のバイト列の一部の範囲だけしか転送しないかもしれません。 このような転送が幾つか行われた後には、キャッシュは、 同じ entity-body の幾つかの範囲を受信しているかもしれません。

If a cache has a stored non-empty set of subranges for an entity, and an incoming response transfers another subrange, the cache MAY combine the new subrange with the existing set if both the following conditions are met:

• o - Both the incoming response and the cache entry must have a cache validator.
• o - The two cache validators must match using the strong comparison function (see section 13.3.3).

キャッシュがある実体の部分範囲の空ではない集合を蓄積している場合で、 到着中の応答が他の部分範囲を転送している場合には、 キャッシュは次の条件を満たす時、 新しい部分範囲を既存の集合と結合して構いません。

• 到着中の応答とキャッシュ項目の両方がキャッシュ検証子を持つ。
• 2つのキャッシュ検証子が強い比較関数を使って一致する。

If either requirement is not meant met, the cache must MUST use only the most recent partial response (based on the Date values transmitted with every response, and using the incoming response if these values are equal or missing), and must MUST discard the other partial information.

いずれかの要件を満たさない時は、キャッシュは、 新しい (各応答で転送される Date 値に基づき、その値が等しいか欠けている時には到着中の応答を使います。) 方の部分応答だけを使わなければなりません。 他の部分情報は捨てなければなりません。