10. Mise en proxy inter-protocoles entre CoAP et HTTP
CoAP ne prend en charge qu'un sous-ensemble limité des fonctionnalités de HTTP, et la mise en proxy inter-protocoles vers HTTP est donc simple. Les raisons de proxyer entre CoAP et HTTP peuvent être multiples, par exemple lors de la conception d'une interface web utilisable indifféremment via l'un ou l'autre protocole, ou lors de la réalisation d'un proxy CoAP-HTTP. De même, CoAP pourrait tout aussi bien être proxyé vers d'autres protocoles tels que XMPP [RFC6120] ou SIP [RFC3264] ; la définition de ces mécanismes sort du cadre de la présente spécification.
Il existe deux directions possibles pour accéder à une ressource via un forward-proxy :
Mise en proxy CoAP-HTTP : permet aux clients CoAP d'accéder à des ressources situées sur des serveurs HTTP par l'intermédiaire d'un intermédiaire. Elle est déclenchée en incluant l'option Proxy-Uri ou Proxy-Scheme avec un URI "http" ou "https" dans une requête CoAP adressée à un proxy CoAP-HTTP.
Mise en proxy HTTP-CoAP : permet aux clients HTTP d'accéder à des ressources situées sur des serveurs CoAP par l'intermédiaire d'un intermédiaire. Elle est déclenchée en spécifiant un URI "coap" ou "coaps" dans la Request-Line d'une requête HTTP adressée à un proxy HTTP-CoAP.
Dans les deux cas, seul le modèle requête/réponse de CoAP est mis en correspondance avec HTTP. Le modèle sous-jacent des messages Confirmable ou Non-confirmable, etc., est invisible et ne doit avoir aucun effet sur la fonction de proxy (MUST NOT). Les sections suivantes décrivent le traitement des requêtes adressées à un forward-proxy. Les reverse-proxies ne sont pas spécifiés, la fonction de proxy étant transparente pour le client, le proxy agissant comme s'il était le serveur d'origine. Toutefois, des considérations similaires s'appliquent aux reverse-proxies et aux forward-proxies, et l'on s'attendra généralement à ce qu'un reverse-proxy fonctionne de manière similaire à un forward-proxy. En note d'implémentation, les bibliothèques clientes HTTP peuvent rendre difficile l'exploitation d'un forward-proxy HTTP-CoAP en n'offrant pas le moyen de placer un URI CoAP sur la Request-Line HTTP ; le reverse-proxying peut donc conduire à une applicabilité plus large d'un proxy. Une spécification distincte peut définir une convention pour les URI exploitant un tel reverse-proxy HTTP-CoAP [MAPPING].
10.1. Mise en proxy CoAP-HTTP
Si une requête contient une option Proxy-Uri ou Proxy-Scheme avec un URI 'http' ou 'https' [RFC2616], alors le point de terminaison CoAP récepteur (appelé ci-après "le proxy") est invité à effectuer l'opération spécifiée par la méthode de requête sur la ressource HTTP indiquée et à renvoyer le résultat au client. (Voir aussi la section 5.7 pour la formulation de la requête adressée au proxy, y compris les exigences de sécurité.)
La présente section spécifie, pour toute requête CoAP, la réponse CoAP que le proxy devrait renvoyer au client. La manière dont le proxy satisfait réellement la requête relève des détails d'implémentation, bien que le cas typique attendu soit que le proxy traduise la requête et la transfère à un serveur d'origine HTTP.
Comme HTTP et CoAP partagent l'ensemble de base des méthodes de requête, exécuter une requête CoAP sur une ressource HTTP n'est pas très différent de l'exécuter sur une ressource CoAP. La signification de chaque méthode CoAP lorsqu'elle est appliquée à des ressources HTTP est expliquée dans les sous-sections de la présente section.
Si le proxy est incapable ou refuse de traiter une requête comportant un URI HTTP, une réponse 5.05 (Proxying Not Supported) est renvoyée au client. Si le proxy traite la requête en interagissant avec un tiers (tel que le serveur d'origine HTTP) et ne parvient pas à obtenir un résultat dans un délai raisonnable, une réponse 5.04 (Gateway Timeout) est renvoyée ; si un résultat peut être obtenu mais n'est pas compris, une réponse 5.02 (Bad Gateway) est renvoyée.
10.1.1. GET
La méthode GET demande au proxy de renvoyer une représentation de la ressource HTTP identifiée par l'URI de requête.
En cas de succès, un Response Code 2.05 (Content) devrait être renvoyé (SHOULD). Le payload de la réponse doit être une représentation de la ressource HTTP cible, et l'option Content-Format doit être définie en conséquence (MUST). La réponse doit indiquer une valeur Max-Age qui n'est pas supérieure au temps restant pendant lequel la représentation peut être considérée comme fraîche (MUST). Si l'entité HTTP possède un entity-tag, le proxy devrait inclure une option ETag dans la réponse et traiter les options ETag des requêtes comme décrit ci-dessous (SHOULD).
Un client peut influencer le traitement d'une requête GET en incluant l'option suivante :
Accept : la requête peut inclure une option Accept, identifiant le content-format de réponse préféré (MAY).
ETag : la requête peut inclure une ou plusieurs options ETag, identifiant des réponses que le client a stockées (MAY). Cela demande au proxy d'envoyer une réponse 2.03 (Valid) chaque fois qu'il enverrait autrement une réponse 2.05 (Content) avec un entity-tag figurant dans l'ensemble demandé. Notez que les ETag de CoAP sont toujours des strong ETags au sens de HTTP ; CoAP n'a pas d'équivalent des weak ETags de HTTP, et il n'existe pas de bonne façon de les utiliser dans un cross-proxy.
10.1.2. PUT
La méthode PUT demande au proxy de mettre à jour ou de créer la ressource HTTP identifiée par l'URI de requête à l'aide de la représentation jointe.
Si une nouvelle ressource est créée à l'URI de requête, une réponse 2.01 (Created) doit être renvoyée au client (MUST). Si une ressource existante est modifiée, une réponse 2.04 (Changed) doit être renvoyée pour indiquer la réussite de la requête (MUST).
10.1.3. DELETE
La méthode DELETE demande au proxy de supprimer, sur le serveur d'origine HTTP, la ressource HTTP identifiée par l'URI de requête.
Une réponse 2.02 (Deleted) doit être renvoyée au client en cas de succès ou si la ressource n'existe pas au moment de la requête (MUST).
10.1.4. POST
La méthode POST demande au proxy de faire traiter par le serveur d'origine HTTP la représentation jointe à la requête. La fonction réellement exécutée par la méthode POST est déterminée par le serveur d'origine et dépend de la ressource identifiée par l'URI de requête.
Si l'action exécutée par la méthode POST n'aboutit pas à une ressource pouvant être identifiée par un URI, une réponse 2.04 (Changed) doit être renvoyée au client (MUST). Si une ressource a été créée sur le serveur d'origine, une réponse 2.01 (Created) doit être renvoyée (MUST).
10.2. Mise en proxy HTTP-CoAP
Si une requête HTTP contient une Request-URI avec un URI "coap" ou "coaps", alors le point de terminaison HTTP récepteur (appelé ci-après "le proxy") est invité à effectuer l'opération spécifiée par la méthode de requête sur la ressource CoAP indiquée et à renvoyer le résultat au client.
La présente section spécifie, pour toute requête HTTP, la réponse HTTP que le proxy devrait renvoyer au client. Sauf indication contraire, toutes les affirmations formulées relèvent d'un comportement recommandé (RECOMMENDED) ; certaines implémentations fortement contraintes peuvent devoir recourir à des raccourcis. La manière dont le proxy satisfait réellement la requête relève des détails d'implémentation, bien que le cas typique attendu soit que le proxy traduise la requête et la transfère à un serveur d'origine CoAP. La signification de chaque méthode HTTP lorsqu'elle est appliquée à des ressources CoAP est expliquée dans les sous-sections de la présente section.
Si le proxy est incapable ou refuse de traiter une requête comportant un URI CoAP, une réponse 501 (Not Implemented) est renvoyée au client. Si le proxy traite la requête en interagissant avec un tiers (tel que le serveur d'origine CoAP) et ne parvient pas à obtenir un résultat dans un délai raisonnable, une réponse 504 (Gateway Timeout) est renvoyée ; si un résultat peut être obtenu mais n'est pas compris, une réponse 502 (Bad Gateway) est renvoyée.
10.2.1. OPTIONS et TRACE
Comme les méthodes OPTIONS et TRACE ne sont pas prises en charge dans CoAP, une erreur 501 (Not Implemented) doit être renvoyée au client (MUST).
10.2.2. GET
La méthode GET demande au proxy de renvoyer une représentation de la ressource CoAP identifiée par la Request-URI.
En cas de succès, une réponse 200 (OK) est renvoyée. Le payload de la réponse doit être une représentation de la ressource CoAP cible, et les champs d'en-tête Content-Type et Content-Encoding doivent être définis en conséquence (MUST). La réponse doit indiquer une directive max-age dont la valeur n'est pas supérieure au temps restant pendant lequel la représentation peut être considérée comme fraîche (MUST). Si la réponse CoAP comporte une option ETag, le proxy devrait inclure un champ d'en-tête ETag dans la réponse.
Un client peut influencer le traitement d'une requête GET en incluant les options suivantes :
Accept : le media type le plus préféré du champ d'en-tête Accept de la requête HTTP est mis en correspondance avec une option Accept de CoAP. Les plages de media type, les paramètres et les extensions de HTTP Accept ne sont pas pris en charge par l'option Accept de CoAP. Si le proxy ne peut pas envoyer une réponse acceptable selon la valeur combinée du champ Accept, il envoie alors une réponse 406 (Not Acceptable). Le proxy peut ensuite réessayer la requête avec d'autres media types issus du champ d'en-tête Accept de HTTP (MAY).
Conditional GETs : les requêtes HTTP GET conditionnelles qui incluent un champ d'en-tête de requête "If-Match" ou "If-None-Match" peuvent être mises en correspondance avec une requête CoAP correspondante. Les champs d'en-tête de requête "If-Modified-Since" et "If-Unmodified-Since" ne sont pas directement pris en charge par CoAP, mais sont mis en œuvre localement par un proxy avec cache.
10.2.3. HEAD
La méthode HEAD est identique à GET, à ceci près que le serveur ne doit pas renvoyer de message-body dans la réponse (MUST NOT).
Bien qu'il n'existe pas d'équivalent direct de la méthode HEAD de HTTP dans CoAP, un proxy HTTP-CoAP répond aux requêtes HEAD portant sur des ressources CoAP, et les en-têtes HTTP sont renvoyés sans message-body.
Note d'implémentation : un proxy HTTP-CoAP peut vouloir essayer d'utiliser une option de transfert par blocs (block-wise transfer) [BLOCK] afin de minimiser la quantité de données réellement transférées, mais il doit être préparé au cas où le serveur d'origine ne prend pas en charge les transferts par blocs.
10.2.4. POST
La méthode POST demande au proxy de faire traiter par le serveur d'origine CoAP la représentation jointe à la requête. La fonction réellement exécutée par la méthode POST est déterminée par le serveur d'origine et dépend de la ressource identifiée par l'URI de requête.
Si l'action exécutée par la méthode POST n'aboutit pas à une ressource pouvant être identifiée par un URI, une réponse 200 (OK) ou 204 (No Content) doit être renvoyée au client (MUST). Si une ressource a été créée sur le serveur d'origine, une réponse 201 (Created) doit être renvoyée (MUST).
Si l'une des options Location-* est présente dans la réponse CoAP, un champ d'en-tête Location construit à partir des valeurs de ces options est renvoyé.
10.2.5. PUT
La méthode PUT demande au proxy de mettre à jour ou de créer la ressource CoAP identifiée par la Request-URI à l'aide de la représentation jointe.
Si une nouvelle ressource est créée à la Request-URI, une réponse 201 (Created) est renvoyée au client. Si une ressource existante est modifiée, l'un des Response Codes 200 (OK) ou 204 (No Content) est envoyé pour indiquer la réussite de la requête.
10.2.6. DELETE
La méthode DELETE demande au proxy de supprimer, sur le serveur d'origine CoAP, la ressource CoAP identifiée par la Request-URI.
Une réponse réussie est 200 (OK) si la réponse comprend une entité décrivant l'état, ou 204 (No Content) si l'action a été exécutée mais que la réponse ne comprend pas d'entité.
10.2.7. CONNECT
Cette méthode ne peut actuellement pas être satisfaite par une fonction de proxy HTTP-CoAP, la tunnelisation de TLS vers DTLS n'ayant pas encore été spécifiée. Pour l'instant, une erreur 501 (Not Implemented) est renvoyée au client.