10. Cross-Protocol Proxying between CoAP and HTTP (CoAPとHTTP間のクロスプロトコルプロキシング)

CoAPはHTTP機能の限定されたサブセットをサポートしているため、HTTPへのクロスプロトコルプロキシングは簡単です。たとえば、いずれかのプロトコルで使用するWebインターフェイスを設計する場合や、CoAP-HTTPプロキシを実現する場合など、CoAPとHTTPの間でプロキシを行う理由はいくつか考えられます。同様に、CoAPはXMPP [RFC6120] やSIP [RFC3264] などの他のプロトコルにプロキシすることもできます。これらのメカニズムの定義は、本仕様の範囲外です。

フォワードプロキシを介してリソースにアクセスするには、2つの方向が考えられます:

CoAP-HTTP Proxying (CoAP-HTTPプロキシング): CoAPクライアントが仲介者を介してHTTPサーバー上のリソースにアクセスできるようにします。これは、CoAP-HTTPプロキシへのCoAPリクエストに、"http" または "https" URIを含むProxy-UriまたはProxy-Schemeオプションを含めることによって開始されます。

HTTP-CoAP Proxying (HTTP-CoAPプロキシング): HTTPクライアントが仲介者を介してCoAPサーバー上のリソースにアクセスできるようにします。これは、HTTP-CoAPプロキシへのHTTPリクエストのRequest-Lineで "coap" または "coaps" URIを指定することによって開始されます。

いずれにせよ、CoAPのリクエスト/レスポンスモデルのみがHTTPにマッピングされます。ConfirmableまたはNon-confirmableメッセージなどの基礎となるモデルは不可視であり、プロキシ機能に影響を与えてはなりません (MUST)。以下のセクションでは、フォワードプロキシへのリクエストの処理について説明します。リバースプロキシは、プロキシがオリジンサーバーであるかのように機能し、プロキシ機能がクライアントに対して透過的であるため、指定されていません。ただし、リバースプロキシにはフォワードプロキシと同様の考慮事項が適用され、一般にリバースプロキシはフォワードプロキシと同様の方法で動作することが期待されます。実装上の注意として、HTTPクライアントライブラリは、HTTP Request-LineにCoAP URIを配置する方法を提供していないため、HTTP-CoAPフォワードプロキシの操作が困難になる場合があります。したがって、リバースプロキシの方がプロキシの適用範囲が広くなる可能性があります。別の仕様で、このようなHTTP-CoAPリバースプロキシを操作するURIの規則を定義する場合があります [MAPPING]。

10.1. CoAP-HTTP Proxying (CoAP-HTTPプロキシング)

リクエストに 'http' または 'https' URI [RFC2616] を含むProxy-UriまたはProxy-Schemeオプションが含まれている場合、受信CoAPエンドポイント (以下「プロキシ」) は、示されたHTTPリソースに対してリクエストメソッドで指定された操作を実行し、結果をクライアントに返すよう要求されます。(セキュリティ要件を含め、プロキシへのリクエストがどのように定式化されるかについては、セクション5.7も参照してください。)

このセクションでは、任意のCoAPリクエストについて、プロキシがクライアントに返すべきCoAPレスポンスを指定します。プロキシが実際にリクエストをどのように満たすかは実装の詳細ですが、典型的なケースは、プロキシがリクエストを変換してHTTPオリジンサーバーに転送することであると予想されます。

HTTPとCoAPは基本的なリクエストメソッドのセットを共有しているため、HTTPリソースに対してCoAPリクエストを実行することは、CoAPリソースに対してそれを実行することとそれほど違いはありません。HTTPリソースに対して実行されたときの個々のCoAPメソッドの意味は、このセクションのサブセクションで説明されています。

プロキシがHTTP URIでリクエストを処理できないか、処理する意思がない場合、5.05 (Proxying Not Supported) レスポンスがクライアントに返されます。プロキシがサードパーティ (HTTPオリジンサーバーなど) と対話してリクエストを処理し、妥当な時間枠内に結果を取得できない場合、5.04 (Gateway Timeout) レスポンスが返されます。結果を取得できるが理解できない場合、5.02 (Bad Gateway) レスポンスが返されます。

10.1.1. GET

GETメソッドは、リクエストURIによって識別されるHTTPリソースの表現を返すようにプロキシに要求します。

成功すると、2.05 (Content) Response Codeが返されるべきです (SHOULD)。レスポンスのペイロードはターゲットHTTPリソースの表現でなければならず (MUST)、Content-Formatオプションはそれに応じて設定されなければなりません (MUST)。レスポンスは、表現が新鮮であると見なすことができる残り時間以下のMax-Age値を示さなければなりません (MUST)。HTTPエンティティにエンティティタグがある場合、プロキシはレスポンスにETagオプションを含めるべきであり (SHOULD)、以下に説明するようにリクエスト内のETagオプションを処理すべきです (SHOULD)。

クライアントは、次のオプションを含めることでGETリクエストの処理に影響を与えることができます:

Accept: リクエストには、優先レスポンスコンテンツ形式を識別するAcceptオプションを含めることができます (MAY)。

ETag: リクエストには、クライアントが保存したレスポンスを識別する1つ以上のETagオプションを含めることができます (MAY)。これは、要求されたセットのエンティティタグを持つ2.05 (Content) レスポンスを送信する場合に、代わりに2.03 (Valid) レスポンスを送信するようにプロキシに要求します。CoAP ETagは常にHTTPの意味での強力なETagであることに注意してください。CoAPにはHTTPの弱いETagに相当するものはなく、クロスプロキシでこれらを利用する良い方法はありません。

10.1.2. PUT

PUTメソッドは、リクエストURIによって識別されるHTTPリソースを、同封された表現で更新または作成するようにプロキシに要求します。

新しいリソースがリクエストURIで作成された場合、2.01 (Created) レスポンスがクライアントに返されなければなりません (MUST)。既存のリソースが変更された場合、リクエストの正常な完了を示すために2.04 (Changed) レスポンスが返されなければなりません (MUST)。

10.1.3. DELETE

DELETEメソッドは、HTTPオリジンサーバーでリクエストURIによって識別されるHTTPリソースを削除するようにプロキシに要求します。

成功した場合、またはリクエスト時にリソースが存在しない場合、2.02 (Deleted) レスポンスがクライアントに返されなければなりません (MUST)。

10.1.4. POST

POSTメソッドは、リクエストに含まれる表現をHTTPオリジンサーバーによって処理させるようにプロキシに要求します。POSTメソッドによって実行される実際の機能は、オリジンサーバーによって決定され、リクエストURIによって識別されるリソースに依存します。

POSTメソッドによって実行されたアクションがURIによって識別できるリソースにならない場合、2.04 (Changed) レスポンスがクライアントに返されなければなりません (MUST)。オリジンサーバー上でリソースが作成された場合、2.01 (Created) レスポンスが返されなければなりません (MUST)。

10.2. HTTP-CoAP Proxying (HTTP-CoAPプロキシング)

HTTPリクエストに "coap" または "coaps" URIを含むRequest-URIが含まれている場合、受信HTTPエンドポイント (以下「プロキシ」) は、示されたCoAPリソースに対してリクエストメソッドで指定された操作を実行し、結果をクライアントに返すよう要求されます。

このセクションでは、任意のHTTPリクエストについて、プロキシがクライアントに返すべきHTTPレスポンスを指定します。特に明記されていない限り、行われたすべてのステートメントは推奨される動作 (RECOMMENDED) です。一部の高度に制約された実装は、ショートカットに頼る必要がある場合があります。プロキシが実際にリクエストをどのように満たすかは実装の詳細ですが、典型的なケースは、プロキシがリクエストを変換してCoAPオリジンサーバーに転送することであると予想されます。CoAPリソースに対して実行されたときの個々のHTTPメソッドの意味は、このセクションのサブセクションで説明されています。

プロキシがCoAP URIでリクエストを処理できないか、処理する意思がない場合、501 (Not Implemented) レスポンスがクライアントに返されます。プロキシがサードパーティ (CoAPオリジンサーバーなど) と対話してリクエストを処理し、妥当な時間枠内に結果を取得できない場合、504 (Gateway Timeout) レスポンスが返されます。結果を取得できるが理解できない場合、502 (Bad Gateway) レスポンスが返されます。

10.2.1. OPTIONS and TRACE

OPTIONSおよびTRACEメソッドはCoAPでサポートされていないため、501 (Not Implemented) エラーがクライアントに返されなければなりません (MUST)。

10.2.2. GET

GETメソッドは、Request-URIによって識別されるCoAPリソースの表現を返すようにプロキシに要求します。

成功すると、200 (OK) レスポンスが返されます。レスポンスのペイロードはターゲットCoAPリソースの表現でなければならず (MUST)、Content-TypeおよびContent-Encodingヘッダーフィールドはそれに応じて設定されなければなりません (MUST)。レスポンスは、表現が新鮮であると見なすことができる残り時間以下の値を示すmax-ageディレクティブを示さなければなりません (MUST)。CoAPレスポンスにETagオプションがある場合、プロキシはレスポンスにETagヘッダーフィールドを含めるべきです (SHOULD)。

クライアントは、次のオプションを含めることでGETリクエストの処理に影響を与えることができます:

Accept: リクエスト内のHTTP Acceptヘッダーフィールドの最も好ましいメディアタイプは、CoAP Acceptオプションにマッピングされます。HTTP Acceptメディアタイプ範囲、パラメータ、および拡張機能は、CoAP Acceptオプションではサポートされていません。プロキシが、結合されたAcceptフィールド値に従って受け入れ可能なレスポンスを送信できない場合、プロキシは406 (Not Acceptable) レスポンスを送信します。プロキシは、HTTP Acceptヘッダーフィールドからのさらなるメディアタイプを使用してリクエストを再試行できます (MAY)。

Conditional GETs: "If-Match" または "If-None-Match" リクエストヘッダーフィールドを含む条件付きHTTP GETリクエストは、対応するCoAPリクエストにマッピングできます。"If-Modified-Since" および "If-Unmodified-Since" リクエストヘッダーフィールドは、CoAPによって直接サポートされていませんが、キャッシュプロキシによってローカルに実装されます。

10.2.3. HEAD

HEADメソッドは、サーバーがレスポンスでメッセージボディを返してはならない (MUST NOT) ことを除いて、GETと同じです。

CoAPにはHTTPのHEADメソッドに直接相当するものはありませんが、HTTP-CoAPプロキシはCoAPリソースのHEADリクエストに応答し、メッセージボディなしでHTTPヘッダーが返されます。

実装上の注意: HTTP-CoAPプロキシは、実際に転送されるデータの量を最小限に抑えるためにブロック単位の転送オプション [BLOCK] の使用を試みたい場合がありますが、オリジンサーバーがブロック単位の転送をサポートしていないケースに備える必要があります。

10.2.4. POST

POSTメソッドは、リクエストに含まれる表現をCoAPオリジンサーバーによって処理させるようにプロキシに要求します。POSTメソッドによって実行される実際の機能は、オリジンサーバーによって決定され、リクエストURIによって識別されるリソースに依存します。

POSTメソッドによって実行されたアクションがURIによって識別できるリソースにならない場合、200 (OK) または204 (No Content) レスポンスがクライアントに返されなければなりません (MUST)。オリジンサーバー上でリソースが作成された場合、201 (Created) レスポンスが返されなければなりません (MUST)。

CoAPレスポンスにLocation-*オプションのいずれかが存在する場合、これらのオプションの値から構築されたLocationヘッダーフィールドが返されます。

10.2.5. PUT

PUTメソッドは、Request-URIによって識別されるCoAPリソースを、同封された表現で更新または作成するようにプロキシに要求します。

Request-URIで新しいリソースが作成された場合、201 (Created) レスポンスがクライアントに返されます。既存のリソースが変更された場合、リクエストの正常な完了を示すために、200 (OK) または204 (No Content) Response Codeのいずれかが送信されます。

10.2.6. DELETE

DELETEメソッドは、CoAPオリジンサーバーでRequest-URIによって識別されるCoAPリソースを削除するようにプロキシに要求します。

レスポンスにステータスを説明するエンティティが含まれている場合、成功したレスポンスは200 (OK) です。アクションは実行されたがレスポンスにエンティティが含まれていない場合は204 (No Content) です。

10.2.7. CONNECT

このメソッドは現在、HTTP-CoAPプロキシ機能では満たすことができません。TLSからDTLSへのトンネリングがまだ指定されていないためです。今のところ、501 (Not Implemented) エラーがクライアントに返されます。