OAuthサービス提供者

サーバー (HTTP)

[17] HTTP要求受信してHTTP応答を作成・送信するプログラムを、 (サーバー) (server) といいます。

仕様書

意味

[162] Webサーバー (Web server) は、 Webサーバーです。ほとんどすべての場合、プロトコルとして HTTP実装したもののことを指しています。

[163] WebサーバーHTTPサーバーは、ほとんど同義として用いられますが、 一般的な文脈では Webサーバー、特に HTTP について扱うときのみ HTTPサーバーと呼ぶことが多そうです。

[14] HTTP (サーバー) (server) は、 HTTP要求に対してHTTP応答送信することによってサービスを提供するため接続受理するプログラムです。 >>13

[19] は、起源鯖であることもあれば、トンネル関門のような中間器であることもあります。

[131] HTTP 視点ではブラックボックスで、どのように要求を処理して応答を生成するかは自由です。 自身が直接処理しても構いません (起源鯖) し、他のに処理を委ねても構いません (中間器)。

C
クライアント
S
C -> S
要求
#S#
何らかの処理
S -> C
応答

[132] HTTP を利用するプロトコル (WebDAVOAuth など) によっては、 の構成や動作に更に制限や要件が規定されています。

[134] ある(広義の)が入口にあたる関門 (逆串 (reverse proxy) ) とその先の実際ので構成される場合、 後者をアプリケーション鯖 (application server) バックエンド (backend) と呼ぶことがあります。

C
クライアント
P
逆串
A
アプリケーション鯖
C -> P
要求
P -> A
要求
#A#
アプリケーション固有の処理
A -> P
応答
P -> C
応答

[133] 要求を処理するために他のプログラムコンポーネントに処理を委ねることもよくあります。 HTTP 視点ではそれらも含めての一部であり、内部の構成や APIが自由に決められます。そのような API の中には標準化されているものもあり (CGIISAPIWSGIPSGI など)、その場合は HTTP 処理を行う部分を、 アプリケーション固有の処理を行う部分をスクリプトアプリケーションなどと呼びます。 ミドルウェアなどその他のコンポーネントが組み合わさる場合もあります。

C
クライアント
S
A
アプリケーション
C -> S
要求
S -> A
呼び出し
#A#
アプリケーション固有の処理
A -> S
結果
S -> C
応答

[2]

'server'
The application program that invokes the script in order to service requests from the client.
(server)
クライアントからの要求に対してサービスを提供するためスクリプトを呼び出す応用プログラム
RFC 3875 - The Common Gateway Interface (CGI) Version 1.1 ( 版) http://tools.ietf.org/html/rfc3875#section-1.4

処理

[45] HTTPサーバーの処理について、仕様書はある部分は順序や細かな要件を定めつつ、 別の部分は曖昧にしており、また別の部分は何も規定されていなかったりします。

[170] プロトコルとしての動作に大きな影響のない事項 (例えば認証エラー 401 と未対応メソッドのエラー 405 の両方に該当するとき、どちらを返すべきか) は、サーバーの判断に委ねられています。 相互運用性に関わる事項 (例えば内容符号化転送符号化の適用順序) は明確に定められています。


[173] HTTPサーバーは、HTTPクライアントとの間のHTTP接続を流れるデータを、 HTTP接続の処理によって順次処理していくことが期待されます。

[21] 応答ヘッダーの受信完了の通知を受けて、HTTP要求要求を処理しなければなりません。

[40] 次のようにします。

  1. [22] 応答を、要求要求検査を適用した結果に設定します。
  2. [24] 応答null でなければ、
    1. [23] 応答を送信します。
  3. [167] それ以外で、 要求メソッドCONNECTTRACE の場合、
    1. [27] 要求メソッドの操作を実行します。
  4. [28] それ以外の場合、
    1. [176] 処理器を、要求要求対象に関する処理の選択の結果に設定します。
    2. [168] 要求について処理器を実行します。

[25] ここで、要求検査とは、受信した要求に対してサーバー全体の制約を検査する、 サーバーの実装や設定に依存した操作です。 応答を返すか、問題がなければ null を返します。

[174] 例えば次のような検査を行うことが期待されます。

[175] 状態符号の選択方法は 4xx を参照。

[177] 要求要求対象に関する処理の選択は、 要求要求対象が指すもの、つまり対象資源に基づき適切な処理を選択するサーバーの実装や設定に依存した処理です。 Webアプリケーション開発の現場ではルーティングと呼ばれることがあります。

[169] 選択された処理は、要求について適切な応答を作成し、送信することが期待されます。

[36] HTTP仕様書が想定する典型的な処理は、次のようなもののようです。

  1. [178] 応答を、要求対象資源依存の要求検査を適用した結果に設定します。
  2. [179] 応答null でなければ、
    1. [180] 応答を送信し、ここで停止します。
  3. [34] 要求キャッシュによって処理可能なら、
    1. [42] 要求に対応するキャッシュ項目を使って応答し、ここで停止します。
  4. [29] 起源鯖で、対象資源に関する内容折衝が適用される場合、 内容折衝により返す表現を選択します。
  5. [32] 必要に応じて内容符号化を適用します >>30
  6. [37] 実体タグを決定します >>30
  7. [26] 条件付き要求が適用される場合、
    1. [147] 要求に事前条件が指定されていれば、 起源鯖であり要求メソッド条件付き要求として適切である場合、 その条件を確認します >>20, >>58。 (条件付き要求を参照。)
    2. [148] 要求に事前条件が指定されていない場合で、 対象資源について非条件付要求を受け付けたくない場合、 428 応答を返します。
  8. [31] 要求メソッドで指定された操作を実行します。
  9. [35] 必要なら実現値操作を適用します >>30 (実現値操作を参照)。
    1. [33] 範囲要求なら、結果の適切な部分を 206 応答として返します。 (範囲要求を参照。)

[181] ここで、対象資源依存の要求検査とは、 受信した要求に対して対象資源によって規定される制約を検査する、 処理器に依存した操作です。 応答を返すか、問題がなければ null を返します。

[182] 例えば次のような検査を行うことが期待されます。

[187] 状態符号の選択方法は 4xx を参照。

[39] 応答応答の送信は、次のようにします。

  1. [44] 応答に対し、必要なら転送符号化を適用します >>30
  2. [41] 応答を送信します。

アプリケーションサーバーAPI

[138] HTTPサーバーアプリケーションとの間の API やサーバー拡張には次のものがあります。

[139] その他 HTTPサーバーの動作の記述に次のものが使われます。

HTTP サーバーの終了

[149] HTTPサーバーを綺麗に終了させるには少し慎重さが必要です。 graceful な終了 (close, shutdown, stop, terminate / 再起動 restart) と呼ばれています。

HTTP/2 の場合、

[151] まず、新規のHTTP接続の受け付けを停止する必要があります。

[150] アイドル状態HTTP接続があれば、これを切断する必要があります。

[159] 応答送信済みで要求受信待ち中なら、 応用がこれを受信している限りにおいて、中断できません。 応用が処理し終えているか、中断するべきと判断したか、 サーバーが設定したタイムアウトに達したなら、接続を切断できます。

[152] 応答を未送信なら、次に送信する応答Connection: close を送信した方が良さそうです。

[153] 応答を未送信または応答を送信中で、これを中断するべきと判断できるなら、 これを直ちに切断できます。

[154] 応答を未送信または応答を送信中で、中断するべきと判断できないなら、 応答の送信を完了次第、直ちに切断する必要があります。 (次の要求が送信されてくる可能性もありますが、 無視しなければなりません。)

[155] 通常の HTTP の場合、中断するべきかどうかは応用が判断するしかありません。 基本的には中断するべきではなさそうですが、タイムアウトを設定した方が良いかもしれません。

[156] WebSocket の場合、中断するべきかどうかは応用が判断するしかありません。 それがかなわない場合は中断するべきです。 Closeフレーム (状態符号 1001) を送信して直ちに接続を閉じるべきかもしれませんし、 それもせずに切断してしまっても良いかもしれません。 中断しない場合でも、タイムアウトを設定した方が良いかもしれません。

[157] CONNECT の場合、中断するべきかどうか判断する方法はないので、 直ちに接続を閉じるのが良さそうです。

[161] クライアントは、サーバーが書き込み側を閉じても直ちにそれに反応して接続を閉じないかもしれません。 通常動作中はそれを待っても良いかもしれませんが、サーバーを終了させたい時は、 クライアントが接続を閉じるのを待たずに直ちに強制切断するべきかもしれません。

[158] HTTP接続が閉じられ、それを処理する応用が完了するか、 応用を中断できる場合で中断したなら、サーバー全体を終了できます。

HTTP サーバーの実装

[145] HTTPサーバーは沢山の実装があります。

[188] Webサイトホスティングサービスも参照。

WebDAV に関する要件

[47] WebDAV に従う資源に関しては、次のようにエラーの検査を行います。

  1. [48] 必要があれば、認証に関するエラーを返します >>46
  2. [56] 要求payload body がある場合、
    1. [55] 要求メソッドの定義上これを無視することになっている場合、 415 応答を返します >>54
    2. [50] XML を指定することになっている場合、
      1. [57] 整形式 XML 1.0 文書でなければ、 400 を返します >>51
      2. [52] 整形式であっても怪しい内容を含んでいれば、 400 を返して構いません >>51
  3. [49] 必要があれば、その他のエラーを返します。

[53] WebDAV は、XML 1.0XML名前空間 1.0 に対応しなければなりません >>51

[60] WebDAV は、 WebDAVXML文書 (死特性以外) の未知の要素属性、既知ながら想定されていない場所で使われている要素属性について、 無視して処理しなければなりません >>59

[61] 処理指令は無視するべきです >>59

CGI に関する要件

[4] CGI に関して、クライアントからの要求CGIスクリプトに伝達するに当たり、 プロトコルトランスポート層認証セキュリティーを実装するのはの責任です。 更にそれ以上のデータ型やプロトコルの変換などを行なっても構いません。 >>3

[5] CGI の仕様に従ってクライアント要求を変換して CGIスクリプトに提供しなければなりません。逆にCGIスクリプトの結果を、 たとえそれが CGI の仕様に適合しなかったとしても、 関係するプロトコルに適合するよう変形する必要があります。 >>3

[6] 認証を適用する場合にあっては、要求がそれをすべて通過しない限り CGIスクリプトを実行してはなりません>>3

[7] また次のことについて明確にすることが推奨されています >>8:

OAuth 1.0 鯖 (サービス提供者)

[67] (サーバー) (server) は、 OAuth認証された要求を受理できる能力のあるHTTP鯖です >>62

[63] 元々はサービス提供者 (service provider) ともいいました >>62

[68] は、次のエンドポイントを持ちます。

[69] もちろん、その他に OAuth を利用する APIエンドポイントも持ちます。

OAuth 2.0 鯖

[64] OAuth 2.0 では資源鯖認可鯖に分けられています。

それぞれの項を参照。

[66] 資源鯖認可鯖の相互作用は OAuth 仕様の範囲外とされています。 資源鯖認可鯖は同じであっても構いません。 一つの認可鯖に複数の資源鯖が対応していても構いません。 >>65

[71] サービス提供者は、フィッシングの防止のために資源所有者を啓蒙したり、 正しい Webサイトであると簡単に確認できる方法を用意したりするべきです >>70

WebSocket サーバー

[142] TCPTCP over TLS によってポートlisten し、 WebSocketクライアントからの接続を待つものを WebSocketサーバーといいます。

[141] WebSocketサーバー側の処理は、負荷分散器逆プロキシなどで分担して行うこともあります。 その場合、TCP接続の終端を行う部分から要求を処理して応答するものまですべて含めて、 サーバー (server) といいます。 >>140

[143] WebSocketサーバーは、次のような処理を実装する必要があります。

歴史

[1] HTTP (RFC1945 1.2, RFC2068 1.3, RFC2616 1.3)
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 するために接続を受け入れる応用プログラム。 任意のプログラムがクライアントサーバーのどちらにもなることができます。これらの用語を使用するときには、一般的なそのプログラムの能力ではなく、特定の接続についてのプログラムの施す役割にのみ言及します。同様に、サーバーは各要求の性質による動作の切り替えで起源サーバー関門あるいはトンネルとして動作するかもしれません。
[38] RFC 3229 (差分符号化) 4 The HTTP message-generation sequence

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 選択を実体札を割当てた後で内容符号化を適用した後で転送符号化は適用する前に行う必要があることは明らかです。 従って、この公式かは完全に従来の慣習および仕様と整合します。

4.1 Relationship between deltas and ranges

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.

Range と差分符号化の両方が実現値操作を形成する時は、 どちらを先に適用するべきでしょうか。 これはどう Range を使用するのかによります。

Ranges are used for two main purposes, at the discretion of the requesting client:

Range は要求するクライアントの裁量により、 二つの目的で使用されます。

  • 1. to complete a partial response after a premature termination of a message transmission.
  • 2. to obtain just selected sections of an instance.
  • メッセージ転送の早すぎる終端の後に部分応答を完了するため
  • 実現値の選択した節をただ得るため

In the first use of Range, it would have to be applied after any delta encoding, since the intended use is to recover an intact copy of the delta-encoded instance. In the second use of Range, it would have to be applied before any delta encoding, because otherwise the offsets specified in the Range request would be meaningless (the client generally cannot know how a server's delta encoding maps instance byte offsets to entity byte offsets).

最初の Range の用法では、 意図した使用法が差分符号化実現値の完全な複製の回復のためですから、 差分符号化の後に適用しなければならないでしょう。 二番目の Range の用法では、 差分符号化の前に適用しなければ 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.

従って、クライアントが二つ以上の実現値操作をどの順番で適用するかを指定するための仕組みが必要です。 これは A-IM 頭の指定の位置部として簡単に提供します。 鯖は実現値操作を A-IM 頭に列挙された順序で適用する必要があります。また、実現値操作の登録集合に range 表記も含めることで、クライアントが (他の実現値操作との順序により) 差分符号化の前後いずれに範囲選択を行うのかを指定することができます。

We also need a mechanism for the server to indicate in which order two or more instance-manipulations have been applied; this is part of the specification of the "IM" header (see section 10.5.2), where we follow the same practice used for the "Content-Encoding" header: the "IM" header lists the instance-manipulations in the order that were applied (including, perhaps, the special "range" literal).

また、鯖がどの順序で二つ以上の実現値操作を適用しているのかを示す仕組みも必要です。これは IM 頭の指定の一部とし、 Content-Encoding 頭で使用しているのと同じ方法を使います。 IM 頭は実現値操作を適用した順に (おそらく特別な range 表記も含めて) 列挙します。

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).

同様の問題が Range を圧縮と組み合わせる時にも起こります。 クライアントが圧縮メッセージの早すぎる終端の後に部分応答を完了するために 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.

これは、 (UNIX diff 命令のような) 単純差異算法は最善の結果を得るために出力を後から圧縮することが必要ですので、 クライアントが差分符号化の前後いずれで圧縮を行うのかを制御することも認めます。

関連

[15] 多くの場合、起源鯖として機能します。

[16] に対して、要求を送信するものをクライアントといいます。

[18] は、要求に関しては受信者応答に関しては送信者となります。

メモ

[144] 2015年Webサーバアーキテクチャ序論 - ゆううきブログ (y_uuki 著, 版) http://yuuki.hatenablog.com/entry/2015-webserver-architecture

[160] net/http: add built-in graceful shutdown support to Server · Issue #4674 · golang/go () https://github.com/golang/go/issues/4674

[43] Web Annotation Protocol () https://w3c.github.io/web-annotation/protocol/wd/#dfn-resource

Web Server

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

[172] サーバーによって (エンドポイントによって) は処理に時間がかかって応答の末尾まで返し終わるのに非常に時間がかかることがあります。 クライアントは十分長い時間待つ必要がありますが、短いタイムアウトを設定していて変更不能なものもあります。