[2]

'server'

The application program that invokes the script in order to service requests from the client.

鯖server

クライアントからの要求に対してサービスを提供するためスクリプトを呼び出す応用プログラム。

server

An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.

サーバー

応答を送り返すことで要求を service するために接続を受け入れる応用プログラム。 任意のプログラムがクライアントとサーバーのどちらにもなることができます。これらの用語を使用するときには、一般的なそのプログラムの能力ではなく、特定の接続についてのプログラムの施す役割にのみ言及します。同様に、サーバーは各要求の性質による動作の切り替えで起源サーバー、串、関門あるいはトンネルとして動作するかもしれません。

HTTP/1.1 supports a number of different transformations on the body of a value:

HTTP/1.1 は値の本体についての数々の異なる変形に対応しています。

Content-coding

According to the specification, "Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only decoded by the recipient." Content-codings are normally end-to-end transformations; i.e., once applied at the sender, they are not removed except at the ultimate recipient. An intermediate server may apply a content-coding, in appropriate circumstances.

内容符号化

仕様書によれば、「内容符号化値は実体に適用されている、またはすることのできる符号化変形を示します。内容符号化は主として中の媒体型の同一性を失ったり情報を損失したりすることなしに、文書を圧縮したり、その他有用に変形することを認めるために使用します。よく、実体は符号化形で蓄積され、直接転送され、受信者によってのみ復号されます」。 内容符号化は通常末端対末端変形です。すなわち、ひとたび送信者のところで適用したら、最後の受信者以外では取り除きません。中間鯖は適切な場面においては内容符号化を適用しても構いません。

Transfer-coding

According to the specification, "Transfer coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer coding is a property of the message, not of the original entity." Transfer-codings are explicitly hop-by-hop transformations (although, as an optimization, an intermediate proxy may store the transfer-coded version of a message if this behavior is not inconsistent with its externally visible function.)

転送符号化

仕様書によれば、「転送符号化値はネットワークを通じた『安全な転送』を確保するために entity-body に適用されている、または適用することのできる、または適用する必要があるかもしれない符号化変形を示すために使用します。これは内容符号化とは異なり、転送符号化はメッセージの特性であってもとの実体の特性ではありません」。 転送符号化は陽にホップ毎変形です (が、最適化として、中間串はその振る舞いが外部から可視の関数と不整合でなければ、メッセージの転送符号化版を蓄積しても構いません)。

Ranges

An HTTP client, using the Range header, may request that the server return one or more subranges of the instance, rather than the entire instance value. HTTP/1.1 only supports byte-ranges, although there is some possibility that future extensions will allow for other kinds of range-specifiers (such as chapters of a document).

範囲

HTTP クライアントは、 Range 頭を使用して、鯖に実現値の全体ではなく、実現値の部分範囲を一つ以上返すように要求することができます。 HTTP/1.1 はバイト範囲のみに対応していますが、 将来の拡張が他の種類の範囲指定子を (この文書の後の章のように) 認める余地があります。

A client signals its willingness to receive a content-coding by sending an "Accept-Encoding" header, listing the set of content-codings that it understands. It may optionally include information about which content-codings it prefers. If a server uses any non-identity content-coding(s), it includes a "Content-Encoding" header field in the response, listing these content-codings in their order of application.

クライアントは内容符号化を受信する意志を Accept-Encoding 頭に自分の理解する内容符号化の集合を列挙することによって通知します。 クライアントは任意でどの内容符号化を好むかについての情報を含めることもできます。鯖が非同一内容符号化(群)を使用する場合は、応答で Content-Encoding 頭欄を使用して、 内容符号化を適用した順に列挙します。

RFC 2068 [9] did not include an analogous mechanism for negotiating the use of transfer-codings, although it does include an analogous "Transfer-Encoding" header for marking the response. A new "TE" header has since been added to HTTP/1.1 [10], analogous to the "Accept-Encoding" header.

RFC 2068 は同様に転送符号化の使用について応答に印をつける Transfer-Encoding 頭を含んでいましたが、折衝のための相当する仕組みは含んでいませんでした。 その後 Accept-Encoding 頭欄に相当する新しい TE 頭が HTTP/1.1 に追加されています。

In this document, we add new, optional message headers to support the use of instance manipulations. A client signals its willingness to receive an instance-manipulation by sending an "A-IM" header (short for "Accept-Instance-Manipulation", which is far too long to spell out), analogous to the "Accept-Encoding" header. Similarly, a server lists the set of instance-manipulations it has applied using an "IM" header.

この文書では、実現値操作の使用に対応するための新しい任意のメッセージ頭を追加します。 クライアントは、実現値操作を受信する意志を A-IM 頭 (Accept-Instance-Manipulation では綴るのが長すぎるので、その省略) を送信することによって通知できます。同様に、鯖は IM 頭を使用して適用している実現値操作の集合を列挙します。

One must understand the relationship between these transformations in order to see how delta encoding applies to HTTP responses.

差分符号化が HTTP 応答にどう適用されるのかを見るためにはこれらの変形の関係を理解しなければなりません。

Conceptually, the various transformations are applied in the following sequence:

概念的には、種々の変形は次の順序で適用します。

1. 1. Upon receiving a GET request, the server uses the URI in the request to identify the requested resource.
2. 2. Optionally, it uses information from the request (and perhaps additional information) to select a variant of that resource.
3. 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.
4. 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.
5. 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.
6. 6. The result of the fifth step becomes the entity, consisting of entity headers and an entity body.
7. 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.
8. 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.

1. GET 要求の受信に際して、鯖は要求された資源の識別のために要求中の URI を使用する。
2. 任意で、要求からの情報 (とおそらく追加情報) をその資源の変体の選択のために使用する。
3. この時点で、鯖は非同一内容符号化を実現値に適用してもよいし、そもそも生成の時から適用されているかもしれない。これは Content-Encoding 頭欄に反映する。
4. 要求が処理される時点で、最初の三段階の結果は実現値である。 実現値は本体 (空のこともある。) と場合によってはいくつかの実現値頭を含む。 実体札は、あれば、この時点で割り当てる。つまり、 実体札は実現値に関連付けられるのであり、実体に関連付けられるのではない。
5. 鯖はそれから実現値操作を適用してもよい。 例えば、要求が Range 頭を含むなら、 鯖は任意選択でもとの頭の集合と Content-Range 頭と (符号化されているかもしれない) 本体からの適切な範囲(群)を含んだ範囲応答を生産してもよい。差分符号化は実現値操作であり、この段階で計算する。
6. 五番目の段階の結果は実体となり、実体頭と実体本体を含む。
7. 鯖はそれから非同一転送符号化を適用してもよい。 その場での圧縮はこの段階で行うことができる。その場合、 Transfer-Encoding 頭がメッセージに加えられる。
8. 七番目の段階の結果はメッセージであり、メッセージ本体 (実体本体の転送符号化版) と実体頭と追加の応答頭および一般頭を含む。

Note: Section 14.13 of the HTTP/1.1 specification [10] says "The Content-Length entity-header field indicates the size of the entity-body." In other words, Content-Length measures the length of an entity, not of an instance or of a variant. For example, if the message is a delta encoding, Content-Length gives the length of the delta encoding, not the length of the current instance.

注意: HTTP/1.1 仕様書の 14.13 節は「Content-Length 実体頭欄は entity-body の寸法を示します」 と述べています。言い換えれば、 Content-Length は実現値や変体の長さではなく、実体の長さを測ります。 例えば、メッセージが差分符号化されているなら、 Content-Length は現在実現値の長さではなく、 差分符号化の長さを与えます。

Diagrammatically, the sequence is:

図にすると次のようになります。

       datatype        operation leading to next datatype
       ========        ==================================
       resource
                   |   choose acceptable variant, if needed
                   v
       variant
                   |   apply content-coding, if any
                   v
                   |   compute/assign entity tag
                   v
       instance
                   |   apply instance manipulation, if any
                   v      (delta encoding, range selection, etc.)
       entity-body
                   |   apply transfer-coding, if any
                   v
       message-body

       データ型        次のデータ型への演算
       ========        ==================================
       資源
                   |   必要なら、受入れ可能変体を選択
                   v
       変体
                   |   あれば、内容符号化を適用
                   v
                   |   実体札を計算・割当て
                   v
       実現値
                   |   あれば、実現値操作を適用
                   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 選択を実体札を割当てた後で内容符号化を適用した後で転送符号化は適用する前に行う必要があることは明らかです。 従って、この公式かは完全に従来の慣習および仕様と整合します。

Web Server

A program that accepts connections in order to service HTTP requests by sending HTTP responses.