10. Protokollübergreifendes Proxying zwischen CoAP und HTTP
CoAP unterstützt eine begrenzte Teilmenge der HTTP-Funktionalität, und daher ist das protokollübergreifende Proxying zu HTTP unkompliziert. Es kann mehrere Gründe für das Proxying zwischen CoAP und HTTP geben, beispielsweise beim Entwurf einer Webschnittstelle zur Nutzung über eines der beiden Protokolle oder bei der Realisierung eines CoAP-HTTP-Proxys. Ebenso könnte CoAP gleichermaßen zu anderen Protokollen wie XMPP [RFC6120] oder SIP [RFC3264] weitergeleitet werden; die Definition dieser Mechanismen liegt außerhalb des Geltungsbereichs dieser Spezifikation.
Es gibt zwei mögliche Richtungen, um über einen Forward-Proxy auf eine Ressource zuzugreifen:
CoAP-HTTP Proxying: Ermöglicht CoAP-Clients, über einen Vermittler auf Ressourcen auf HTTP-Servern zuzugreifen. Dies wird eingeleitet, indem die Option Proxy-Uri oder Proxy-Scheme mit einem "http"- oder "https"-URI in eine CoAP-Anfrage an einen CoAP-HTTP-Proxy aufgenommen wird.
HTTP-CoAP Proxying: Ermöglicht HTTP-Clients, über einen Vermittler auf Ressourcen auf CoAP-Servern zuzugreifen. Dies wird eingeleitet, indem ein "coap"- oder "coaps"-URI in der Request-Line einer HTTP-Anfrage an einen HTTP-CoAP-Proxy angegeben wird.
In beiden Fällen wird nur das Request/Response-Modell von CoAP auf HTTP abgebildet. Das zugrunde liegende Modell von Confirmable- oder Non-confirmable-Nachrichten usw. ist unsichtbar und darf keine Auswirkung auf eine Proxy-Funktion haben (MUST NOT). Die folgenden Abschnitte beschreiben die Behandlung von Anfragen an einen Forward-Proxy. Reverse-Proxys werden nicht spezifiziert, da die Proxy-Funktion für den Client transparent ist und der Proxy so handelt, als wäre er der Origin-Server. Es gelten jedoch ähnliche Überlegungen für Reverse-Proxys wie für Forward-Proxys, und es wird allgemein erwartet, dass Reverse-Proxys auf ähnliche Weise arbeiten wie Forward-Proxys. Als Implementierungshinweis: HTTP-Client-Bibliotheken können den Betrieb eines HTTP-CoAP-Forward-Proxys erschweren, indem sie keine Möglichkeit bieten, einen CoAP-URI in die HTTP-Request-Line zu setzen; Reverse-Proxying kann daher zu einer breiteren Anwendbarkeit eines Proxys führen. Eine separate Spezifikation kann eine Konvention für URIs definieren, die einen solchen HTTP-CoAP-Reverse-Proxy betreiben [MAPPING].
10.1. CoAP-HTTP-Proxying
Wenn eine Anfrage eine Option Proxy-Uri oder Proxy-Scheme mit einem 'http'- oder 'https'-URI [RFC2616] enthält, wird der empfangende CoAP-Endpunkt (im Folgenden "der Proxy" genannt) aufgefordert, die durch die Anfragemethode angegebene Operation auf der bezeichneten HTTP-Ressource auszuführen und das Ergebnis an den Client zurückzugeben. (Siehe auch Abschnitt 5.7 dazu, wie die Anfrage an den Proxy formuliert wird, einschließlich der Sicherheitsanforderungen.)
Dieser Abschnitt legt für jede CoAP-Anfrage die CoAP-Antwort fest, die der Proxy an den Client zurückgeben sollte. Wie der Proxy die Anfrage tatsächlich erfüllt, ist ein Implementierungsdetail, wobei im typischen Fall erwartet wird, dass der Proxy die Anfrage übersetzt und an einen HTTP-Origin-Server weiterleitet.
Da HTTP und CoAP die grundlegende Menge von Anfragemethoden gemeinsam nutzen, unterscheidet sich das Ausführen einer CoAP-Anfrage auf einer HTTP-Ressource nicht wesentlich vom Ausführen auf einer CoAP-Ressource. Die Bedeutungen der einzelnen CoAP-Methoden bei Ausführung auf HTTP-Ressourcen werden in den Unterabschnitten dieses Abschnitts erläutert.
Wenn der Proxy nicht in der Lage oder nicht willens ist, eine Anfrage mit einem HTTP-URI zu bedienen, wird dem Client eine 5.05 (Proxying Not Supported)-Antwort zurückgegeben. Wenn der Proxy die Anfrage durch Interaktion mit einem Dritten (etwa dem HTTP-Origin-Server) bedient und nicht in der Lage ist, innerhalb eines angemessenen Zeitrahmens ein Ergebnis zu erhalten, wird eine 5.04 (Gateway Timeout)-Antwort zurückgegeben; wenn ein Ergebnis erhalten werden kann, aber nicht verstanden wird, wird eine 5.02 (Bad Gateway)-Antwort zurückgegeben.
10.1.1. GET
Die GET-Methode fordert den Proxy auf, eine Darstellung der durch den Request-URI identifizierten HTTP-Ressource zurückzugeben.
Bei Erfolg sollte (SHOULD) ein 2.05 (Content) Response Code zurückgegeben werden. Der Payload der Antwort muss (MUST) eine Darstellung der Ziel-HTTP-Ressource sein, und die Option Content-Format muss (MUST) entsprechend gesetzt werden. Die Antwort muss (MUST) einen Max-Age-Wert angeben, der nicht größer ist als die verbleibende Zeit, in der die Darstellung als frisch betrachtet werden kann. Wenn die HTTP-Entity ein entity-tag hat, sollte (SHOULD) der Proxy eine Option ETag in die Antwort aufnehmen und ETag-Optionen in Anfragen wie unten beschrieben verarbeiten.
Ein Client kann die Verarbeitung einer GET-Anfrage beeinflussen, indem er die folgende Option einbezieht:
Accept: Die Anfrage kann (MAY) eine Option Accept enthalten, die den bevorzugten Antwort-content-format angibt.
ETag: Die Anfrage kann (MAY) eine oder mehrere ETag-Optionen enthalten, die vom Client gespeicherte Antworten identifizieren. Dies fordert den Proxy auf, eine 2.03 (Valid)-Antwort zu senden, wann immer er andernfalls eine 2.05 (Content)-Antwort mit einem entity-tag aus der angefragten Menge senden würde. Beachten Sie, dass CoAP-ETags im HTTP-Sinne immer starke ETags sind; CoAP hat kein Äquivalent zu HTTP-schwachen ETags, und es gibt keine gute Möglichkeit, diese in einem Cross-Proxy zu nutzen.
10.1.2. PUT
Die PUT-Methode fordert den Proxy auf, die durch den Request-URI identifizierte HTTP-Ressource mit der beigefügten Darstellung zu aktualisieren oder zu erstellen.
Wenn am Request-URI eine neue Ressource erstellt wird, muss (MUST) dem Client eine 2.01 (Created)-Antwort zurückgegeben werden. Wenn eine vorhandene Ressource geändert wird, muss (MUST) eine 2.04 (Changed)-Antwort zurückgegeben werden, um den erfolgreichen Abschluss der Anfrage anzuzeigen.
10.1.3. DELETE
Die DELETE-Methode fordert den Proxy auf, die durch den Request-URI identifizierte HTTP-Ressource auf dem HTTP-Origin-Server zu löschen.
Bei Erfolg oder wenn die Ressource zum Zeitpunkt der Anfrage nicht existiert, muss (MUST) dem Client eine 2.02 (Deleted)-Antwort zurückgegeben werden.
10.1.4. POST
Die POST-Methode fordert den Proxy auf, die in der Anfrage beigefügte Darstellung durch den HTTP-Origin-Server verarbeiten zu lassen. Die tatsächlich von der POST-Methode ausgeführte Funktion wird vom Origin-Server bestimmt und hängt von der durch den Request-URI identifizierten Ressource ab.
Wenn die von der POST-Methode ausgeführte Aktion nicht zu einer durch einen URI identifizierbaren Ressource führt, muss (MUST) dem Client eine 2.04 (Changed)-Antwort zurückgegeben werden. Wenn auf dem Origin-Server eine Ressource erstellt wurde, muss (MUST) eine 2.01 (Created)-Antwort zurückgegeben werden.
10.2. HTTP-CoAP-Proxying
Wenn eine HTTP-Anfrage einen Request-URI mit einem "coap"- oder "coaps"-URI enthält, wird der empfangende HTTP-Endpunkt (im Folgenden "der Proxy" genannt) aufgefordert, die durch die Anfragemethode angegebene Operation auf der bezeichneten CoAP-Ressource auszuführen und das Ergebnis an den Client zurückzugeben.
Dieser Abschnitt legt für jede HTTP-Anfrage die HTTP-Antwort fest, die der Proxy an den Client zurückgeben sollte. Sofern nicht anders angegeben, sind alle getroffenen Aussagen empfohlenes Verhalten (RECOMMENDED); einige stark eingeschränkte Implementierungen müssen möglicherweise auf Abkürzungen zurückgreifen. Wie der Proxy die Anfrage tatsächlich erfüllt, ist ein Implementierungsdetail, wobei im typischen Fall erwartet wird, dass der Proxy die Anfrage übersetzt und an einen CoAP-Origin-Server weiterleitet. Die Bedeutungen der einzelnen HTTP-Methoden bei Ausführung auf CoAP-Ressourcen werden in den Unterabschnitten dieses Abschnitts erläutert.
Wenn der Proxy nicht in der Lage oder nicht willens ist, eine Anfrage mit einem CoAP-URI zu bedienen, wird dem Client eine 501 (Not Implemented)-Antwort zurückgegeben. Wenn der Proxy die Anfrage durch Interaktion mit einem Dritten (etwa dem CoAP-Origin-Server) bedient und nicht in der Lage ist, innerhalb eines angemessenen Zeitrahmens ein Ergebnis zu erhalten, wird eine 504 (Gateway Timeout)-Antwort zurückgegeben; wenn ein Ergebnis erhalten werden kann, aber nicht verstanden wird, wird eine 502 (Bad Gateway)-Antwort zurückgegeben.
10.2.1. OPTIONS und TRACE
Da die Methoden OPTIONS und TRACE in CoAP nicht unterstützt werden, muss (MUST) dem Client ein 501 (Not Implemented)-Fehler zurückgegeben werden.
10.2.2. GET
Die GET-Methode fordert den Proxy auf, eine Darstellung der durch den Request-URI identifizierten CoAP-Ressource zurückzugeben.
Bei Erfolg wird eine 200 (OK)-Antwort zurückgegeben. Der Payload der Antwort muss (MUST) eine Darstellung der Ziel-CoAP-Ressource sein, und die Header-Felder Content-Type und Content-Encoding müssen (MUST) entsprechend gesetzt werden. Die Antwort muss (MUST) eine max-age-Direktive angeben, die einen Wert angibt, der nicht größer ist als die verbleibende Zeit, in der die Darstellung als frisch betrachtet werden kann. Wenn die CoAP-Antwort eine Option ETag hat, sollte der Proxy ein Header-Feld ETag in die Antwort aufnehmen.
Ein Client kann die Verarbeitung einer GET-Anfrage beeinflussen, indem er die folgenden Optionen einbezieht:
Accept: Der am meisten bevorzugte Medientyp des HTTP-Header-Felds Accept in einer Anfrage wird auf eine CoAP-Option Accept abgebildet. HTTP-Accept-Medientypbereiche, -Parameter und -Erweiterungen werden von der CoAP-Option Accept nicht unterstützt. Wenn der Proxy keine Antwort senden kann, die gemäß dem kombinierten Accept-Feldwert akzeptabel ist, sendet der Proxy eine 406 (Not Acceptable)-Antwort. Der Proxy kann (MAY) die Anfrage dann mit weiteren Medientypen aus dem HTTP-Header-Feld Accept erneut versuchen.
Conditional GETs: Bedingte HTTP-GET-Anfragen, die ein Request-Header-Feld "If-Match" oder "If-None-Match" enthalten, können auf eine entsprechende CoAP-Anfrage abgebildet werden. Die Request-Header-Felder "If-Modified-Since" und "If-Unmodified-Since" werden von CoAP nicht direkt unterstützt, sondern von einem caching proxy lokal implementiert.
10.2.3. HEAD
Die HEAD-Methode ist identisch mit GET, außer dass der Server keinen message-body in der Antwort zurückgeben darf (MUST NOT).
Obwohl es in CoAP kein direktes Äquivalent zur HEAD-Methode von HTTP gibt, antwortet ein HTTP-CoAP-Proxy auf HEAD-Anfragen für CoAP-Ressourcen, und die HTTP-Header werden ohne message-body zurückgegeben.
Implementierungshinweis: Ein HTTP-CoAP-Proxy möchte möglicherweise versuchen, eine block-wise transfer option [BLOCK] zu verwenden, um die tatsächlich übertragene Datenmenge zu minimieren, muss aber auf den Fall vorbereitet sein, dass der Origin-Server block-wise transfers nicht unterstützt.
10.2.4. POST
Die POST-Methode fordert den Proxy auf, die in der Anfrage beigefügte Darstellung durch den CoAP-Origin-Server verarbeiten zu lassen. Die tatsächlich von der POST-Methode ausgeführte Funktion wird vom Origin-Server bestimmt und hängt von der durch den Request-URI identifizierten Ressource ab.
Wenn die von der POST-Methode ausgeführte Aktion nicht zu einer durch einen URI identifizierbaren Ressource führt, muss (MUST) dem Client eine 200 (OK)- oder 204 (No Content)-Antwort zurückgegeben werden. Wenn auf dem Origin-Server eine Ressource erstellt wurde, muss (MUST) eine 201 (Created)-Antwort zurückgegeben werden.
Wenn eine der Location-*-Optionen in der CoAP-Antwort vorhanden ist, wird ein aus den Werten dieser Optionen konstruiertes Header-Feld Location zurückgegeben.
10.2.5. PUT
Die PUT-Methode fordert den Proxy auf, die durch den Request-URI identifizierte CoAP-Ressource mit der beigefügten Darstellung zu aktualisieren oder zu erstellen.
Wenn am Request-URI eine neue Ressource erstellt wird, wird dem Client eine 201 (Created)-Antwort zurückgegeben. Wenn eine vorhandene Ressource geändert wird, wird entweder der Response Code 200 (OK) oder 204 (No Content) gesendet, um den erfolgreichen Abschluss der Anfrage anzuzeigen.
10.2.6. DELETE
Die DELETE-Methode fordert den Proxy auf, die durch den Request-URI identifizierte CoAP-Ressource auf dem CoAP-Origin-Server zu löschen.
Eine erfolgreiche Antwort ist 200 (OK), wenn die Antwort eine den Status beschreibende Entity enthält, oder 204 (No Content), wenn die Aktion ausgeführt wurde, die Antwort aber keine Entity enthält.
10.2.7. CONNECT
Diese Methode kann derzeit von einer HTTP-CoAP-Proxy-Funktion nicht erfüllt werden, da das Tunneln von TLS zu DTLS noch nicht spezifiziert wurde. Vorerst wird dem Client ein 501 (Not Implemented)-Fehler zurückgegeben.