Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#259 closed other technical (fixed)

Standardize a workaround for HTTP library limitations in talking to forward HTTP-COAP cross-proxies?

Reported by: cabo@… Owned by: cabo@…
Priority: minor Milestone: post-WGLC-1
Component: coap Version: coap-09
Severity: In WG Last Call Keywords:


Cullen Jennings notes (msg03072bu):

Section 8 - I tried passing a COAP URL in a HTTP request line of various libraries, firewalls, and other tools. In theory it might work, but my observation is that in practice, it does not. I'm not sure how to fix this. One possible solution is making a way to translate well know http URL into a coap URL. So for example, the translator proxy that received an HTTP request like

would translate that to


If we did something like this, your standard web libraries running on things like google app engine could make REST calls to the proxy that resulted in a request to the CoAP device. Perhaps you think this approach is the reverse proxy approach but one way or another, I can see how to get the current solution working very well in practice.

Solution: Defining such a workaround mapping (carrying a CoAP URI "in" a URI) is straightforward (with a little bike-shedding needed). Do we do this in core-coap or separately?

Change History (4)

comment:1 Changed 10 years ago by tho@…

Message received by email on Tue, 06 Nov 2012 12:37:39 +0000, inserted by email2trac:

On Tue, Nov 6, 2012 at 12:12 PM, core issue tracker
<> wrote:
> #259: Standardize a workaround for HTTP library limitations in talking to
> forward HTTP-COAP cross-proxies?

Re to this, I've added a feature request to HTML5:

to let browsers configure their HTTP-CoAP forward proxy via the
registerProtocolHandler API.

Maybe worth doing some lobbying in this direction ?

comment:2 Changed 10 years ago by cabo@…

  • Owner changed from draft-ietf-core-coap@… to cabo@…
  • Status changed from new to assigned

It now seems pretty clear that we should go for a separate specification for a reverse-proxy convention for HTTP-CoAP mapping.
So, to prepare for this, I propose to add the following text (from "However") to the end of the introduction to section 10.

HTTP-CoAP Proxying: Enables HTTP clients to access resources on CoAP

servers through an intermediary. This is initiated by specifying
a "coap" or "coaps" URI in the Request-Line of an HTTP request to
an HTTP-CoAP proxy.

Either way, only the Request/ Response model of CoAP is mapped to
HTTP. The underlying model of confirmable or non-confirmable
messages, etc., is invisible and MUST have no effect on a proxy
function. The following sections describe the handling of requests
to a forward-proxy. Reverse proxies are not specified as the proxy
function is transparent to the client with the proxy acting as if it
was the origin server. However, similar considerations apply to
reverse-proxies as to forward-proxies, and there generally will be an
expectation that reverse-proxies operate in a similar way forward-
proxies would. As an implementation note, HTTP client libraries may
make it hard to operate an HTTP-CoAP forward proxy by not providing a
way to put a CoAP URI on the HTTP Request-Line; reverse-proxying may
therefore lead to wider applicability of a proxy. A separate
specification may define a convention for URIs operating such a HTTP-
CoAP reverse proxy.

comment:3 Changed 10 years ago by cabo@…

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed in coap-13 in combination with draft-bormann-core-cross-reverse-convention-00.txt

comment:4 Changed 10 years ago by cabo@…

Fixed in [1095]:

Provide a reference to a placeholder I-D in order to close #259.

Note: See TracTickets for help on using tickets.