Request.scheme is not set properly or at all

[calif-devel]

I'm working on a HTTP-CoAP ProxyServer based on Californium and I'm using cf-rd from californium.tools project. My intention is to support both coap and coaps endpoints on the proxy server and with help of cf-rd tools, the CoAP peers can POST /rd using either coap or coaps.

However I noticed that although my CoAP device registered using coaps, the logs showed

INFO [RDResource]: Adding new endpoint: coap://127.0.0.1:50961

On further investigation, in RDNodeResource class, when LinkFormat.CONTEXT is either missing or empty, the code assumes the scheme to be coap. I can't set LinkFormat.CONTEXT in URIQuery when positng on resource /rd, because of NAT. Based on RFC, if LinkFormat.CONTEXT is not set, then source address and port should be used. RDNodeResource class uses Request object to correctly set the source address and port, but not the scheme.

So I decided to change the logic in class RDNodeResource to rely on Request.getScheme() method to create appropriate LinkFormat.CONTEXT. But this change produced the following in logs

INFO [RDResource]: Adding new endpoint: //127.0.0.1:50961

Is Request.scheme ever set? Which component is responsible of setting this variable to right value? Is there a better way to setting the LinkFormat.CONTEXT in RDNodeResource other than using Request object?

[sophokles73]

My understanding is that we are talking about an incoming CoAP request, right?
The problem here seems to be that (currently) Californium does not know whether the incoming request has been sent via coap or coaps. The problem is that Californium's CoAP layer is independent from the underlying transport layer so we will need to figure out a way for the CoAP layer to determine whether the Endpoint we have received the request on is secure (DTLS) or not.

[calif-devel]

Yes, you are right. Currently it is not possible to know if a request is coming from a coaps endpoint. So if a CoAP peer wants to send a follow up request to a peer, using the RDNodeResource.getContext(), sends in this new request as plain (non-DTLS) CoAP request to a port listening for DTLS CoAP requests.

In Class CoapEndpoint.InboxImpl where request object created, is this a valid fix?

if (raw.getCorrelationContext().get(DtlsCorrelationContext.KEY_SESSION_ID) != null) {
    request.setScheme(CoAP.COAP_SECURE_URI_SCHEME);
} else {
    request.setScheme(CoAP.COAP_URI_SCHEME);
}
request.setSource(raw.getAddress());
request.setSourcePort(raw.getPort());
request.setSenderIdentity(raw.getSenderIdentity());

[calif-devel]

I guess additionally, RDNodeResource class need to be changed to take the request.getScheme() into consideration to properly set the RDNodeResource.context variable.

[sophokles73]

@calif-devel,

In Class CoapEndpoint.InboxImpl where request object created, is this a valid fix?

I had exactly the same idea :-)
However, I think we should encapsulate this test in RawData, e.g.

if (raw.isSecure()) {
    request.setScheme(CoAP.COAP_SECURE_URI_SCHEME);
} else {
    request.setScheme(CoAP.COAP_URI_SCHEME);
}

This way we do not expose too much of the underlying mechanism around CorrelationContext to upper layers ...

Would you like to create a PR? :-)

[mkovatsc]

I like the fix.

Another comment: Do not rely too much on the RD implementation. It was a contribution that has never been fully overhauled, and hence is of lower code quality... (yet I did some improvements a while ago).

This means, whenever you find something strange in the RD code, do not hesitate to ask about it! ;)

[calif-devel]

Fixed and submitted as Pull Request #42

[sophokles73]

I will take a look (and merge) tomorrow.
Thanks again, @calif-devel

[sophokles73]

Hi @calif-devel,

I guess you can now close this issue ... thanks again for contributing :-)

[calif-devel]

Thank you @sophokles73 and @mkovatsc for resolving this.