この文書は、2009/08/19 時点のDraft Specs - ReverseHTTPをkoshigoeが私的に翻訳したものです。訳の正確さは保証できませんし、無条件に信用すべきでもありません。
※ 要求レベルを表現するためのキーワードについては、RFC-2119j（内田訳）を参考にしています。
(2009/08/19)
This document describes a dynamic, ReST-style means of enrolment and
participation in an HTTP network. The message/http and
application/http MIME types defined by RFC 2616 are used to
build a dynamically-configurable "Remote CGI" service.
このドキュメントは勧誘手段としての ReST-style と HTTP ネットワークへの参加について説明する。
RFC 2616 で定義される message/http と application/http という MIME type は
動的に設計可能な "Remote CGI" サービスを組み立てるために使われる。
Joining the World Wide Web as an HTTP server has been an ad-hoc, manual process. By using the protocol defined here, programs can provide services to the Web just as easily as they request services from the Web.
HTTP サーバとして WWW に参加する事はアドホックで手作業。ここで定義されるプロトコルを利用する事で、プログラムはウェブからサービスをリクエストする様な手軽さで、ウェブにサービスを提供する事が出来る。
To date, joining the World Wide Web as an HTTP server has been a complicated process, managed in an ad-hoc way. Almost every piece of server configuration is manual: DNS records, firewall and NAT configuration, load balancing, access control configuration, operating-system configuration, installation and management of server software and extensions, CGI scripts and their interpreters, and so on. Even simple HTTP services are static and difficult to change.
今まで、HTTP サーバとして WWW に参加する事は面倒で、アドホックな方法で管理されていた。 サーバ設定のほとんどは手作業: DNS レコード、ファイアウォール、NAT 設定、ロードバランス、アクセス制御の設定、OS 設定、サーバソフトウェアと拡張および CGI スクリプトとそのインタプリタのインストールと管理、など。 さらに単純な HTTP サービスは静的で変更は難しいもの。
By contrast, joining the World Wide Web as an HTTP client is extremely easy. No DNS configuration is required, as clients do not have names within the network; no complicated server software is required; no firewall or NAT configuration needs to be changed. HTTP clients come and go dynamically.
対照的に、HTTP クライアントとして WWW に参加する事は非常に簡単。 ネットワークに名前を持たないクライアントなら DNS 設定は要求されない; 複雑なサーバソフトウェアは要求されない; ファイアウォールや NAT 設定を変更する必要が無い。 HTTP クライアントは動的に動作する。
The World Wide Web is evolving from being a protocol for naming and copying statically-configured resources into being a communications platform for participants in a general-purpose distributed object system. As this has been happening, ad-hoc techniques such as long-polling/Comet have developed that serve to make HTTP less asymmetric and more dynamically configurable.
WWW は汎用的な分散オブジェクトシステムへの参加者のためのコミュニケーションプラットホームで静的に設定したリソースを名付けてコピーしたものによって発展している。 このため、ロングポーリングのようなアドホックなテクニック/Comet は非対称を減らし動的に設定可能な HTTP を提供するために開発された
This document describes a ReST-style protocol that permits programs with access to an HTTP client library to
このドキュメントはプログラムが HTTP クライアントライブラリにアクセス出来る様にするReSTスタイルのプロトコルについて説明する。
dynamically claim and relinquish pieces of URL-space in which to provide HTTP-accessible services, and
HTTP アクセス可能なサービスの URL 空間の一部を動的に要求し放棄する
respond to HTTP requests within their claimed portion of URL-space.
要求された URL 空間の一部への HTTP リクエストへに応答する
The protocol can be seen as "Remote CGI": a means of extending an HTTP service that, in contrast to ordinary CGI, does not require special access to the file system and configuration of the server.
"Remote CGI" の様なプロトコル: 普通の CGI と比べて、ファイルシステムへのアクセス特権とサーバ設定を必要としない HTTP サービスを拡張する手段。
By splitting out the concerns of allocation of URL-space and of responding to incoming requests from the concerns of DNS, firewall and NAT management, HTTP-based services can come and go without needing the extensive manual configuration that is currently required. Programs can provide services to the Web just as easily as they request services from the Web. The protocol defined here gives control over enrolment to the very programs wishing to enrol.
DNS・ファイアウォール・NAT 管理から URL 空間の割当とリクエストへの応答の関係を切り離す事で、 HTTP ベースのサービスは現在必要としている広範囲の手動設定を行う必要がなくなる。 プログラムはウェブからサービスにリクエストする様な手軽さでウェブにサービスを提供する事が出来る。 ここで定義するプロトコルは、加入の制御を加入を望む適正なプログラムにゆだねる。
Long-polling techniques are used by many Web services to provide timely event notification while avoiding the need for event recipients to expose addressable HTTP endpoints. This specification lowers the barriers to universal use of HTTP push and web hooks, and makes it possible to push the use of long-polling out to the very edges of the network.
ロングポーリングテクニックは、アドレス可能な HTTP エンドポイントにさらしたイベント受領者に必要になるまで保留するタイムリーなイベント通知を提供するために、多くのウェブサービスに使われている。 この仕様書は HTTP プッシュと web hooks の一般利用の障壁を下げ、 ネットワークの最端にロングポールの利用なしにプッシュできる様にする。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
There are several widely-deployed methods for extending web servers, all of which require some changes to the server's static configuration to be made in order to add or remove a service. Some are complex protocols in their own right.
いくつかの広く使われているウェブサーバの拡張手段があり、それらすべてはサービスを追加したり削除したりするためにサーバの静的な設定を変更する必要がある。 それらは複雑なプロトコルである。
Apache's mod_proxy in reverse-proxy mode lets many HTTP servers be composed to appear as a single server.
リバースプロキシモードの Apache の mod_proxy は沢山の HTTP サーバを束ねて一つのサーバであるかの様に振る舞う。
CGI (and variants such as FastCGI and SCGI) lets many small programs be individually named and made accessible via HTTP.
CGI (と、FastCGI と SCGI) は多くの小さなプログラムを個々に名付けて HTTP でアクセス可能にする。
More generally, web server extension modules are often used to extend web servers with new functionality.
更に一般に、ウェブサーバの拡張モジュールは新しい機能でウェブサービスを拡張するために使われる。
The participants in the protocol defined in this document are Applications and the Gateway Service. Interactions between the Gateway Server and HTTP clients requesting services provided by Applications are normal HTTP requests and so are not specified in this document.
このドキュメントで定義するプロトコルの関係者は、Application と Gateway Service 。 Gateway Server と Application によって提供されるサービスにリクエストする HTTP クライアントとの間の相互作用は、通常の HTTP リクエストであるためこのドキュメントでは述べない。
The following message sequence diagram illustrates the processing of a single request:
以下のメッセージシーケンス図は一つのリクエストを示したもの:
Original Requestor Gateway Service Application "foo"
| | |
| |<---- GET ------------|
| | |
|----- GET /foo/a ---->| |
| |----- 200 ----------->|
| | "GET /a" |
| | |
| |<---- POST -----------|
| | "404" |
| | |
|<---- 404 ------------|----- 202 ----------->|
| | |
An Application is a program that wishes to provide HTTP service to third parties, and that registers with a Gateway Service in order to do so.
Application は第三者に HTTP サービスの提供を望むプログラムで、そうするために Gateway Service に登録してある。
A Gateway Server is an ordinary HTTP server that provides Gateway Service to Applications. A Gateway Service
Gateway Server は Application に Gateway Service を提供する普通の HTTP サーバー。 Gateway Service は
responds to Application requests for claiming or relinquishing pieces of the URL-space under the control of the Gateway Server, and
Gateway Server の管理下にある URL 空間の一部を要求するか手放すためにリクエストした Application に応答し
relays incoming requests for claimed pieces of URL-space on to the corresponding Applications, and relays Application responses to such requests on to the original requestors.
要求された URL 空間に対応する Application へのリクエストを中継し、 そのリクエストに対する Application の応答を Original Requestor に中継する。
The Gateway Service URL is used by Applications to claim and configure pieces of URL-space under the control of the Gateway Server.
Gateway Server URL はGateway Server の管理下にある URL 空間の一部を要求したり設定したりするために Application によって使われる。
The Application Name is the identifier that Applications use when claiming URL-space from a Gateway Service. Application Names are embedded into the Public Application URL given to the Application on registration. Application Names must be valid DNS labels, as specified by RFC 1034.
Application Name は Gateway Service から URL 空間を要求する時に Application が使う識別子。 Application 名は、登録時に Application に与えられる、こうかい Application URL に埋め込まれる。 Application Name は RFC 1034 で示される適切な DNS ラベルでなければならない。
When an Application claims a portion of URL-space from a Gateway Service, the service sends back three URLs:
Application が Gateway Service に URL 空間の部分を要求する時、サービスは 3 つの URL を送り返す:
One, the Public Application URL, is a URL that lies within the portion of URL-space under control of the Gateway Server that the Application can give out to third parties.
1 つは、Public Application URL で、 Application が第三者に配る事が出来る Gateway Server の管理下にある URL 空間の部分。
One, the Private Application URL, is the URL that the Application uses to control its registration with the Gateway Service.
1 つは、Private Application URL で、 Application が Gateway Service への登録を管理するために使う。
The final URL is the Request URL that the Application should use to receive incoming requests. When HTTP requests arrive for the Public Application URL, they are placed in a queue, and sent on to the Application for processing when the Application accesses a Request URL.
最後は、Request URLで、Application がやってくるリクエストを受け取るために使うべきもの。 HTTP リクエストが Public Application URL に到着した時、 それらはキューに置かれ、Request URL にアクセスしたときに、処理するために Application に送られる。
Private Application URLs are for controlling active registrations with the Gateway Service, and SHOULD be unguessable (for instance, by incorporating a UUID or other nonce value) and SHOULD NOT be visible in any kind of public index. Private Application URLs are effectively capabilities granting full access to an application's registration with the Gateway Service.
Private Application URL は Gateway Service への有効な登録を管理するためにあり、 推測不可能(例えば、UUID か他の当座(nonce)の値を混ぜる)であるべき(SHOULD)で、 いかなる類の公開インデックスで見えるべきでない(SHOULD NOT)。 Private Application URL は、 Gateway Service への Application の登録のための完全なアクセス権限を事実上可能にする。
Public Application URLs are for wide distribution and use, and so MAY be guessable or placed in a public index.
Public Appliaction URL は広く知れ渡って使われ、推測可能であるか公開インデックスに置かれるかもしれない(MAY)。
HTTP requests relayed to Applications are named by unique Request
URLs. When an Application has finished processing a request, it
POSTs an appropriate HTTP response to the request's Request URL. The
response is then relayed back to the original requestor.
Application に中継される HTTP リクエストはユニークな Request URL に名付けられる。
Application がリクエストを処理し終えたとき、そのリクエストの Request URL に適した HTTP レスポンスを POST する。
そのレスポンスは Original Requestor に中継して戻される。
Since Request URLs give access to the incoming request stream for an Application, they SHOULD be unguessable (for instance, by incorporating a UUID or other nonce value) and SHOULD NOT be visible in any kind of public index.
Request URL は、 Application のためにやってくるリクエストストリームにアクセス出来る様になるまで、 推測不可能(例えば、UUID か他の当座(nonce)の値を混ぜる)であるべき(SHOULD)で、 いかなる類の公開インデックスで見えるべきでない(SHOULD NOT)。
RFC 2616
defines
the application/http MIME
type for representing
pipelines of HTTP requests or responses, and the message/http MIME
type for single HTTP requests or responses. In order to carry HTTP
over HTTP, we define a simple enveloping protocol for these pipelines
and messages.
RFC 2616 は
HTTP リクエストかレスポンスのパイプラインを示す application/http MIME type と
単一の HTTP リクエストかレスポンスを示す message/http MIME type を
定義している。
HTTP を HTTP で運ぶため、これらのパイプラインとメッセージを包み込むプロトコルを定義する。
An Embedded Pipeline is a pipeline being tunnelled. It is of
type application/http, and is either a pipeline of HTTP requests,
or a pipeline of HTTP responses.
Embedded Pipeline はトンネルしたパイプライン。
タイプは application/http で、HTTP リクエストのパイプラインか HTTP レスポンスのパイプラインのどちらかである。
An Embedded Message is a single HTTP request or HTTP response
being tunnelled. It is of type message/http.
Embedded Message はトンネルした HTTP リクエストか HTTP レスポンス。
タイプは message/http。
An Envelope HTTP Request is an HTTP request that carries an Embedded Pipeline or Message in its body.
Envelope HTTP Request は Embedded Pipeline か Embedded Message をボディとして運ぶ HTTP リクエストである。
An Envelope HTTP Response is an HTTP response that carries an Embedded Pipeline or Message in its body.
Envelope HTTP Response は Embedded Pipeline か Embedded Message をボディとして運ぶ HTTP レスポンスである。
In cases where there is no resulting ambiguity, the term Pipeline is used to mean either a Pipeline or a Message in the text below.
結果の曖昧さが無い場合、以下の文の通りに、パイプラインはパイプラインかメッセージの手段として使われる。
In the context of this specification,
この仕様書の文脈において、
Envelope HTTP Responses carry the Embedded HTTP request pipelines or messages from the Gateway Service to Applications, and
Envelop HTTP Responses は、 Gateway Service から Application へ、 HTTP Request の Embedded Pipeline か Embedded Message を運び、
Envelope HTTP Requests carry the corresponding Embedded HTTP response pipelines or messages from Applications to the Gateway Service.
Envelop HTTP Requests は、 Application から Gateway Service へ、 HTTP Response の Embedded Pipeline か Embedded Message を運ぶ。
To claim a piece of URL-space, POST to the Gateway Service URL with
a normal application/x-www-form-urlencoded entity body. The
parameters sent should be
URL 空間の一部を要求するために、
通常の application/x-www-form-urlencoded なエンティティボディを
Gateway Service URL に POST する。
送るべきパラメータは、
name: a valid DNS label, as specified by RFC 1034. This is
the Application Name to register.
name: RFC 1034 で示される適切な DNS ラベル。これは登録のための Application Name 。
token: any string of characters. Optional. If present, used as a
shared-secret to control access to the registration process: if, on
two subsequent registrations, the tokens do not match, then the
later registration will fail with response code 403.
token: なにかしらの文字列。任意。もし指定したなら、
登録プロセスへのアクセス制御のために共有秘密として使われる:
もし続いている登録で token らが一致しないなら、後の登録は 403 レスポンスコードとともに失敗する。
lease: any string of digits. Optional. If present, and a
registered service is left dormant (i.e. without clients collecting
incoming requests) for the specified number of seconds, the
registration will be deleted.
lease: 何かしらの数字。任意。もし指定し、
その数だけの秒間、登録済みサービスが休止状態のまま(例: やってくるリクエストを収集するクライアントがない)なら、
その登録は削除される。
If the token parameter is omitted, the service SHOULD act as if a
fresh, random token was supplied, thereby ensuring a
first-in-first-served policy on application name registrations.
token パラメータが省略されたなら、そのサービスはまだ使われていないランダムな token が与えられたように振る舞うべき(SHOULD)で、
それによって、Application Name の登録において、先に来たものに先に利用できるポリシーを確実にする。
If the lease parameter is omitted, the service should choose a value
for the lease-expiry-time long enough to give the newly-registered
service time to start polling for incoming requests. If the lease
parameter is present, the service should try to honour it as far as
possible, however overly-short or overly-long leases MAY be altered by
the service without notice to the application.
lease パラメータが省略されたなら、そのサービスは、
新たに登録されたサービスに対して、
やってくるリクエスト用のポーリングを始めるための時間を与えるために、
十分な長さのリース満了時間となる値を選ぶべき。
lease パラメータが指定されたなら、サービスは可能な限り従う様努めるべきだが、
短かすぎるか長過ぎる lease らは
Application に通知する事無くサービスによって変えられるかも(MAY)しれない。
Possible responses to a registration request include:
登録リクエストへのレスポンス候補:
201, if a new registration was made.
新しく登録が行われたなら 201 。
204, if an existing registration was refreshed.
既存の登録を新しくしたなら 204 。
400 は以下の場合。
lease parameter is present but not a parseable integer number of seconds, or
lease パラメータが示されたが秒数の整数としてパース不可能であるか、
name is missing or is not a legal DNS label
name がないか適正な DNS ラベルでない。
403, if the token does not match a token held in an existing registration record for this application name.
この Application Name に関する既存の登録レコードが所持する token と一致しないなら 403 。
If a 2xx-series response is sent, the response MUST have the following headers set:
2xx 系のレスポンスが送られたなら、そのレスポンスは以下のヘッダセットを持たなくてはならない(MUST):
Link, with rel="first" and the URL being a Request URL.
rel="first" とその URL が Request URL である Link。
Link, with rel="related" and the URL being the Public
Application URL.
rel="related" とその URL が Public Application URL である Link。
Location being the Private Application URL.
Private Application URL を値とに持つ Location。
Applications should issue a GET against the Request URL (given in
the rel="first" Link header) to begin polling for incoming
requests.
Application は、やってくるリクエストに関するポーリングを始めるために、
Request URL (rel="first" な Link ヘッダに与えられたものに対して GET を発行すべき。
Applications may hand out the Public Application URL (in the
rel="related" Link header) to third parties.
Application は第三者に Public Application URL (rel="related" な Link ヘッダにあるもの)を与えるかもしれない。
The URL given in the Location header can be used to query and update
the configuration of the registration.
Location ヘッダに与えられた URL は登録の設定を問い合わせたり更新するのに使う事が出来る。
The Public Application URL is chosen by the server on an application-by-application basis, and can be of any form, though it should include the application name. Two major possibilities exist:
Public Application URL は application-by-application ベースでそのサーバに選ばれ、 Application Name を含むべきだがどのような形をとる事が出来る。 2 つの主要な実現性がある:
virtual-host-based: http://applicationname.example.com/ (perhaps
using wildcard CNAMEs in DNS to support arbitrary application
labels)
バーチャルホスト: http://applicationname.example.com/
(おそらく任意の Application ラベルをサポートするために DNS のワイルドカード CNAME を使う)
path-based: http://example.com/x/y/applicationname
パス: http://example.com/x/y/applicationname
Applications MUST NOT assume a particular scheme for construction of
the Public Application URL, and MUST instead use the rel="related"
Link header in the registration response as their public address.
Application は Public Application URL を組み立てるための固有の方法があると仮定してはならず(MUST NOT)、
代わりに登録レスポンスにある rel="related" な Linkヘッダの URL を公開アドレスとして使わなければならない(MUST)。
If virtual-host-based URL construction is used, care must be taken to treat the Application Name case-insensitively, as DNS labels are case-insensitive.
バーチャルホスベースの URL 構成を使うなら、DNS ラベルがケースインセンシティブである様に Application Name をケースインセンシティブとして取り扱わなければならない事に気をつける。
To poll for incoming requests, issue an HTTP GET to a Request URL
sent from the Gateway Service in a Link header (either rel="first"
or rel="next"). The Gateway Service should hold the request open
until a request arrives for the registered application or an internal
timeout occurs.
やってくるリクエストにポールするために、
ゲースウェイサービスから Link ヘッダ (rel="first" か rel="next"のどちらか) で送られた
Request URL に HTTP GET を発行する。
Gateway Service は登録済み Application に関するリクエストが到着するか内部タイムアウトが生じるまで、
リクエストを開いたまま保持するべき。
The Accept header on the GET request, if present, lets the Gateway
Service know whether use of application/http is permissible (see the
section on Streaming below). Unless the Gateway Service
is sure that the requesting Application can handle application/http,
it MUST use message/http (i.e. it must send requests one-at-a-time
without streaming or pipelining).
GET リクエストに Accept ヘッダがあるならば、
application/http を使う事が出来るかを
Gateway Service が知れる様にする(ストリーミングセクション参照)。
Gateway Service がリクエストしている Application が application/http を扱える事に確信が無いなら、
message/httpを使わなくてはならない(例: ストリーミングかパイプラインを使わずに一度にひとつのリクエストを送らなければならない)。
Possible responses include:
レスポンス候補:
200, if a request arrives before the poll times out. The entity body is the incoming request(s).
ポールがタイムアウトする前にリクエストが到着したなら 200 。エンティティボディはやってきたリクエスト。
204, if the poll times out.
ポールがタイムアウトしたなら 204 。
404, if no such Request URL exists.
Request URL が存在しなければ 404 。
410, if the registration is deleted during the poll.
ポールの間に登録が削除されたなら 410 。
If a 2xx-series response carrying an entity body is sent, the response
will be an Envelope HTTP Response, carrying an Embedded HTTP Pipeline
or Embedded HTTP Message in its entity body. The Content-type header
of the Envelope Response will be set to application/http or
message/http. Embedded Pipelines (application/http) MUST NOT be
used unless the Gateway Service supports them, the Application has
explicitly requested them via use of the Accept header, and the
Gateway Service has decided to use them.
エンティティボディを運ぶ 2xx 系のレスポンスが送られたなら、
そのレスポンスは自身のエンティティボディで Embedded HTTP Pipeline か Embedded HTTP Message を運ぶ Envelope HTTP Response。
Envelope Response のContent-typeは
application/http か message/http。
Embedded Pipeline (application/http)は
Gateway Service がサポートするか、
Application が Accept ヘッダを使う事で明示的に要求して
Gateway Service が利用を決断するかしない限りは使ってはならない(MUST NOT)。
Embedded Pipelines will carry the HTTP Method, Request-URI and
HTTP-version values that were sent by the original requestor. The
Gateway Service MUST NOT alter the embedded HTTP headers or the
Request-URI when it relays requests on to applications.
Embedded Pipeline は Original Requestor によって送られた
HTTP Method、Request-URI、HTTP-versionらの値を運ぶ。
Gateway Service は Application へのリクエストを中継するときに、
組み込まれていた HTTP ヘッダか Request-URI を変更してはならない(MUST NOT)。
All 2xx-series responses MUST have a Link header with rel="next"
pointing to the next Request URL the application should use. If an
application sends a GET more than once for the same Request URL,
undefined behaviour results; Applications MUST NOT assume that a
Request URL can be used more than once, and MUST instead follow the
linked-list formed by successive Link rel="next" headers in
responses from the Gateway Service. The only known-safe reuse of a
Request URL is when the Gateway Service decides to send a
previously-used Request URL in a Link header.
すべての 2xx 系レスポンスは、
Application が使うべき次の Request URL を指し示す
rel="next" な Link を持たなければならない(MUST)。
Application が同一の Request URL に対して一度以上 GET を送った場合、
未定義の振る舞いが生じる;
Application は
Request URL が何度も使えると仮定してはならず(MUST NOT)、代わりに
Gateway Service からのレスポンスにある
連続する rel="next" な Link による連結リストに従わなければならない(MUST)。
Request URL の安全な再利用は Gateway Service が前に使われた Request URL を Link ヘッダで送る事を決定したときだけ。
Responses with code 200 MUST also have a Requesting-Client header
containing the IP address and port number of the original requestor
for the Embedded Pipeline or Message being delivered. The header
should be formatted as A.B.C.D:PORT; for example, if the requestor
had IP address 10.1.2.3 and remote TCP port number 45678, the
Requesting-Client header would contain the string 10.1.2.3:45678.
200 コードによるレスポンスは届けられる Embedded Pipeline か Embedded Message のために
Original Requestor の IP アドレスとポート番号を含む Requesting-Client ヘッダも持たなければならない(MUST)。
そのヘッダは A.B.C.D:PORT という書式であるべき;
例えば、Original Requestor の IP アドレスが 10.1.2.3 で、リモート TCP ポート番号が 45678 なら、
Requesting-Client ヘッダは 10.1.2.3:45678 という文字列を含む。
If an application is waiting on more than a single Request URL for incoming requests, the Gateway Service SHOULD send requests out to each polling client in as close to a round-robin fashion as possible, except where doing so could result in requests being delivered to the Application out of order. (See the section on "Streaming" below for details on ordering constraints.)
やって来るリクエストのために、Applicaiton が一つ以上の Request URL に対して待っているなら、 Gateway Service は、 順番外の Application に届けられるリクエストが生じる時を除いて、 可能な限りラウンドロビン風に似せて各ポーリングクライアントにリクエストを送るべき(SHOULD)。 (順番の制約に関する詳細は、"Streaming" セクションを参照。)
Once an Application has processed a received HTTP request, and
constructed an appropriate HTTP response, it uses POST to the
Request URL from which it received the request to cause the reply to
be relayed on to the original requestor.
受け取った HTTP リクエストを処理し妥当な HTTP レスポンスを組み立てた Application は、 Request URL に POST する事で Original Requestor への返信を中継させる。
The Content-type of the POST SHOULD be the same as the
Content-type received on the Envelope HTTP Response from the GET,
and SHOULD NOT be absent; that is, if the Gateway Service sent an
Embedded HTTP Request Pipeline, the POSTed response should be an
Embedded HTTP Response Pipeline labelled as application/http, and if
the Gateway Service sent an Embedded HTTP Request Message, the
POSTed response should be an Embedded HTTP Response Message labelled
as message/http. The Gateway Service MAY permit other
Content-types, such as application/x-www-form-urlencoded, since
some HTTP client libraries do not offer control over the
Content-type header.
POST の Content-type は GET して Envelope HTTP Response で受け取った
Content-type と同じであるべき(SHOULD)で、省略すべきでない(SHOULD NOT);
Gateway Service が Embedded HTTP Request Pipeline を送ったなら、
POST したレスポンスは application/http とラベル付けされた Embedded HTTP Response Pipeline であるべきで、
Gateway Service が Embedded HTTP Request Messsage を送ったなら、
POST したレスポンスは message/http とラベル付けされた Embedded HTTP Response Message であるべき。
Gateway Service は、
いくつかの Content-type ヘッダを制御できない HTTP クライアントライブラリのため、
application/x-www-form-urlencoded の様な他の Content-type を許可するかも(MAY)しれない。
The submitted entity body MUST be a valid HTTP response Pipeline or Message, as appropriate.
送信されたエンティティボディは妥当な HTTP Response Pipeline か HTTP Response Message に適したものでなければならない(MUST)。
Possible responses include:
レスポンス候補:
202, if the reply is accepted and relayed on to the original requestor. (NB: the requestor may have given up in the meantime. Status code 202 is no guarantee that the original requestor will receive the application's reply.)
返信が中継されて Original Requester に受け付けられたなら 202 。 (NB: その Original Requestor はその間に諦めているかもしれない。 ステータスコード 202 は Application の返信を Original Requestor が受け取った事を保証するものではない。)
404, if no such request URL exists.
リクエスト URL が存在しないなら 404 。
400, if the HTTP response in the request body is invalid.
リクエストボディ内の HTTP レスポンスが不正であるなら 400 。
Ordinary HTTP requests intended for Applications registered with the Gateway Service (that is, sent to portions of URL-space rooted at Public Application URLs) are simply enqueued and delivered to the application when it next polls for requests, in a first-in, first-out ordering. (NB: The Gateway Service MUST NOT reorder requests arriving on a single connection, but MAY arbitrarily interleave requests arriving on different connections.)
Gateway Service に登録された Application に向けるだろう 通常の HTTP リクエスト (Public Application URL をルートとする URL 空間の一部へ送られる)は 単純にキューに入り、先に入ったものが先に出る順番で次にリクエストをポールするときに Application に届けられる。 (NB: Gateway Service は一つのコネクションでやってくるリクエストらを最注文してはならない(MUST NOT)が、 異なるコネクションでやってくるリクエストを自由裁量で差し込めるかもしれない(MAY)。)
Normally, the application will generate its own HTTP responses to send back, but in some cases the Gateway Service has to supply a response. Cases where the Gateway Service may supply an HTTP response include:
通常、Application は送り返すために自身の HTTP レスポンスを生成するが、 いくつかの場面で Gateway Service はレスポンスを与える必要がある。 Gateway Service が HTTP レスポンスを与える場面:
400, if the IP address and port of the requestor could not be determined.
Original Requestor の IP アドレスとポート番号を知る事が出来なかったら 400 。
404, if no registration covering the requested URL exists.
リクエストされた URL をカバーする登録が存在しなければ 404 。
503, if there was an error relaying the request.
リクエストの中継中にエラーが起きたなら 503 。
504, if no pollers were available within a certain timeout (see below).
タイムアウトまでに有効なポーラーがなければ 504 (以下も参照)。
504, if there was a timeout waiting for a reply from the application.
Application からの返信を待つ間にタイムアウトしたなら 504 。
502, if the reply from the poller was invalid.
ポーラーからの返信が不正なら 502 。
If a request for an Application is sent to the Gateway Service during a period when no polling clients are waiting for incoming requests, the Gateway Service SHOULD time out the request with an appropriate response code, and SHOULD indicate to the requestor that no application servers were available. Some care should be taken to distinguish between unavailability of the registered Application and a busy Application that is working through a backlog of requests. Only in the former situation should the request be timed out for this reason.
やってくるリクエストを待つポーリングクライアントがない間、Application へのリクエストが Gateway Service に送られたなら、 Gateway Service はふさわしいレスポンスコードでリクエストをタイムアウトすべきで(SHOULD)、 利用可能な Application サーバーが無い事をその Original Requestor に示すべき(SHOULD)。 利用できない登録済み Application と未処理のリクエストで忙しい Application を区別すべき。 この理由で、前者のシチュエーションだけはそのリクエストがタイムアウトとされるべき。
A second kind of timeout MAY also be implemented by the Gateway Service: if a request is delivered to the Application, but the Application does not respond, the Gateway Service MAY time out the request. If it does, it SHOULD indicate to the requestor that the request was delivered to the Application, but that a reply was not received quickly enough. Notice that this kind of timeout should also apply to requests in a busy Application's request queue: if the Application is working, but not working fast enough, this kind of timeout MAY be signalled.
タイムアウトの 2 つめの種類は Gateway Service によって実行されるかもしれない(MAY): リクエストが Application に届けられたが、その Application が応答しない場合、 その Gateway Service はそのリクエストをタイムアウトするかもしれない(MAY)。 そうしたなら、リクエストが Application に届けられたが十分な速さで返信を受け取らなかった事を Original Requestor に示すべき(SHOULD)。 この種類のタイムアウトがあっても忙しい Application のリクエストキューにリクエストを向けるべきである事に注意: Application が動いているが十分速く動いていないなら、この種類のタイムアウトはシグナルになるかもしれない(MAY)。
Note that the timeout for unavailability of the Application can be short -- even as short as 1 second -- but that the timeout for a missing reply from the Application should be much longer, certainly no shorter than 60 seconds, if a timeout for a missing reply is implemented at all.
Application が利用できない事によるタイムアウトは 1 秒程度の短時間だが、 返信を受け取れない事に依るタイムアウトが実行されるかによらず、 Application からの返信を受け取れない事によるタイムアウトは 60 秒以上の長さであるべき。
Issuing a GET to the Gateway Service URL should, after appropriate
authentication and authorisation checks, retrieve a representation of
the state of the entire Gateway Service, either in HTML or in a
machine-readable format. The Accept header may be used to control
the format of the returned information.
Gateway Service URL に GET を発行する事で、妥当な認証と承認の後で、
Gateway Service 全体の状態を HTML か機械に読める形式のどちらかの表現で回収できるべき。
Accept ヘッダは返ってくる情報の形式を制御するために使われるかもしれない。
Issuing a GET to the Private Application URL SHOULD retrieve a
representation of the state of the registration. The Accept header
MAY be used to control the format of the returned information.
Private Application URL に GET の発行する事で、
登録状態の表現を回収できるべき(SHOULD)。
Accept ヘッダは返ってくる情報の形式を制御するために使われるかもしれない。
Gateway Services SHOULD support returning information about registrations in
Gateway Services は登録について以下の情報を返すことをサポートすべき(SHOULD)
application/x-www-form-urlencoded format. The parameters included
should include at least name and lease, as described for the
registration process above.
application/x-www-form-urlencoded 形式。
登録プロセスで述べた通りの name と lease を含む。
HTML format, for human use.
人が使うための HTML 形式。
Issuing a PUT to the Private Application URL with a body of
Content-type application/x-www-form-urlencoded SHOULD update the
configuration of a registration just as if the registration were
deleted and recreated. In particular, lease and token should be
updated, if supplied.
Content-type が application/x-www-form-urlencoded であるボディとともに
Private Application URL に PUT を発行する事で、
登録を削除し作り直す様にして、登録の設定を更新できるべき(SHOULD)。
lease と token が与えられていたなら更新されるべき。
If the name parameter is supplied, it MUST be ignored.
name パラメータが与えられたとしても、それは無視されなければならない(MUST)。
To cancel a registration, applications should issue an HTTP DELETE
to the Private Application URL.
登録をキャンセルするためには、 Application は Private Application URL に DELETE を発行すべき。
Possible responses to such a DELETE include:
DELETE のレスポンス候補:
204, if the registration was successfully deleted
登録の削除に成功したなら 204 。
404, if no such registration existed
登録が存在しないなら 404 。
If, at the time of the DELETE, one or more GETs to Request URLs
were active for the registration to be deleted, the GETs SHOULD be
terminated as soon as possible with HTTP status code 410 sent back to
the GETting application.
DELETE の際に削除されるべき登録で有効な Request URL に一度以上 GET されたなら、
GET は可能な限りすぐに中断され、 410 ステータスコードとともに Application に送り返されるべき(SHOULD)。
Any requests that were being processed by an application at the time
of the DELETE SHOULD NOT be affected by the deletion, and the
Gateway Service SHOULD relay replies received from the application to
the original requestors as usual.
DELETE されるとき、Application によって処理されたリクエストは
削除に影響すべきでなく(SHOULD NOT)、
Gateway Service はいつも通りに Application から Original Requestor に返信を中継すべき(SHOULD)。
HERE
Can begin talking to a poller immediately and use chunked transfer coding. May timeout the poller and end the request -- this results in a 200 response with an empty body in a corner case!
すぐにポーラーと会話を始められ、チャンク形式転送コーディングを利用する。 特別なケースにおいて、ポーラーがタイムアウトしてリクエストが終わったなら 空ボディの 200 レスポンスを返すことがある。
Queue ordering constraints for streams: either one connection, one stream, or wait for a reply before issuing the next request. Must not round-robin where doing so could reorder requests.
ストリームについて順序を強制されたキュー: 一つのコネクションに一つのストリームか次のリクエストを発行する前に返信を待つかのどちらか。 リクエストを再注文できるならラウンドロビンしてはならない。
Not all services are available all the time. At times, a registered Application will not be in a position to receive inbound requests from the Gateway Service. This corresponds to the equivalent of XMPP's "unavailable" presence indication. Further work will address the issue of presence state-change notification over HTTP.
すべてのサービスが常に利用可能とは限らない。 登録済み Application が Gateway Service からのリクエストを受け取るための場所にいないかもしれない。 XMPP の "unavailable" 在席表示と同じ。 さらに仕事を終えて HTTP 越しの通知で在席状態を変更するかもしれない。
In general, service unavailability is a problem shared by all HTTP services, not just those exposed via a Gateway Service. The difference here is that a 5xx-series response code is returned by the Gateway Service to the requestor in cases of unavailability, rather than the more usual case of simply no listening socket being available to take requests.
一般に、サービスの利用不可能状態は Gateway Service によって晒されるものだけではなく、 すべての HTTP サービスによって共有される問題。 この違いは、 利用不可能な場合に Gateway Service によって Original Requesotor に返された 5xx 系レスポンスコードは、 単にリクエストを受け取るための有効なリッスン中のソケットが無いというだけではないことにある。
Securing the registration of pieces of URL-space is important. Gateway Servers can use any means of HTTP or HTTPS authentication and authorisation to control access to the Gateway Service URL and to Private Application URLs and Request URLs. In particular, on any of the interactions described above between the Gateway Server and the Application, all the usual HTTP response codes apply, including 401 and 403 for authentication and authorisation control.
URL 空間の一部の登録の安全性は重要。 Gateway Service は Gateway Service URL と Private Application URL と Request URL へのアクセス制御のために HTTP か HTTPS の認証と承認のいかなる手段も利用する事が出来る。 特に、先述した Gateway Service と Application との間の連携において、 401 と 403 を含む認証と承認を制御するための通常の HTTP レスポンスコードは適用できる。
Besides traditional HTTP/HTTPS access control, unguessable URLs (including UUIDs or similar) can be used to provide a capability-style model of access control.
従来の HTTP/HTTPS アクセス制御と比べると、 推測不可能な URL (UUID などを含む) は アクセス制御の適応性スタイルモデルを提供するために使う事が出来る。
Interactions between third parties and Applications are to be relayed through the Gateway Service: it is not the Service's role to control access to Application resources. Instead, Applications themselves should check the credentials offered in each third-party HTTP request, and should return 401 and 403 responses as appropriate to the third parties.
第三者と Appliation との間の連携は Gateway Service を通して中継される: Application リソースへのアクセス制御は Gateway Service の役割ではない。 代わりに、Application 自身が 第三者の各リクエストに提示されたクレデンシャルを確認すべきで、 第三者にふさわしい 401 と 403 のレスポンスを返すべき。
RFC 1034, Domain Names - Concepts And Facilities, P. Mockapetris
RFC 1945, Hypertext Transfer Protocol -- HTTP/1.0, T. Berners-Lee et al.
RFC 2119 (BCP 14), Key words for use in RFCs to Indicate Requirement Levels, S. Bradner
RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding et al.
RFC 3857, The Common Gateway Interface (CGI) Version 1.1, D. Robinson and K. Coar
draft-nottingham-http-link-header-04, Link Relations and HTTP Header Linking, M. Nottingham; Internet-Draft, expires August 29, 2009
draft-lentczner-rhttp-00, Reverse HTTP, M. Lentczner and D. Preston; Internet-Draft, expires September 5, 2009
Tony Garnock-Jones
tonyg@lshift.net
http://homepages.kcbbs.gen.nz/~tonyg/
Copyright © 2009, Tony Garnock-Jones tonyg@lshift.net
Copyright © 2009, LShift Ltd. query@lshift.net
Permission is hereby granted, free of charge, to any person obtaining a copy of this documentation (the "Documentation"), to deal in the Documentation without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Documentation, and to permit persons to whom the Documentation is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Documentation.
THE DOCUMENTATION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE DOCUMENTATION OR THE USE OR OTHER DEALINGS IN THE DOCUMENTATION.