gcoap: allow proxied client requests#13637
Conversation
a1119fa to
d047a15
Compare
|
The not-so-little change to the Wouldn't it be much more consistent (also with our tools) to use the absolute path here? E.g., instead of |
|
I agree it is useful to support a client sending to a forward proxy. Let's start with my comment below on |
|
|
||
| int gcoap_req_init(coap_pkt_t *pdu, uint8_t *buf, size_t len, | ||
| unsigned code, const char *path) | ||
| unsigned code, const char *path, bool proxied) |
There was a problem hiding this comment.
Are you sure we want to specify use of a proxy here? The major issue I see is that the option number for Proxy-Uri is 35. If we add this option here, the user will be unable to specify use of an option with a lesser number. These lesser numbers include a large number of options, including Content-Format.
Why not just require the user to specify use of a forward proxy with coap_opt_add_string() themselves? This allows them to use either Proxy-Uri or Proxy-Scheme.
There was a problem hiding this comment.
hmm, this would mean:
- no changes in gcoap (maybe a little bit on the documentation on how to achieve proxied requests)
- put more logic into the gcoap example
or did I misunderstand your comment?
There was a problem hiding this comment.
Yes, right on both points -- and point to the example from the documentation.
There was a problem hiding this comment.
You also could add an inline convenience function, coap_opt_add_proxy_uri(), similar to coap_opt_put_location_path().
There was a problem hiding this comment.
You also could add an inline convenience function,
coap_opt_add_proxy_uri(), similar tocoap_opt_put_location_path().
I think that approach makes sense in this case. +1
|
Please add "proxy" to the printf usage statement on the next to the last line of |
kb2ma
left a comment
There was a problem hiding this comment.
Aside from inline comments, I agree with how you organized the CLI for proxy. Thanks for the contribution!
I am neutral on this change to the CLI. It would make parsing the full command line easier because it is a single string, and we could use the scheme to infer use of a default port. On the other hand, parsing scheme + destination + port + path from a single string is more complicated than use of IMO, URI parsing belongs at the system level though, in a separate PR. There should be One True Way to do it. For example, the Wakaama example needs it for the server URI. @leandrolanzieri, @miri64 -- any opinion on use of a URI, especially as a default approach for CLI tools? |
I would prefer URIs as well. I wanted to propose it a long time ago actually, but ended up very low on my list of priorities. |
alright. Then let's go for now with the currently proposed solution and in a separate Pr we could think about using absolute URIs. |
kb2ma
left a comment
There was a problem hiding this comment.
Overall this looks good except for the inline comments. I plan to test over the next day or so.
d6abb70 to
cc8ebc5
Compare
|
@kb2ma addressed your comments. Thanks for the doc enhancements (: |
Perhaps the reason for the specific At any rate, let's defer any modifications for a path. The gcoap example is just an example and does not need to cover all possible uses of a proxy. |
|
I think that covers all the issues from testing. Let me take one more look through. |
|
Looks good and tests pass. Able to do a PUT with a payload and receive a Block2 response. Please squash! |
I see your point now! It's not legal to add a Uri-Path option with a Proxy-Uri option. In that case the cf-proxy app could parse the Proxy-Uri scheme to decide what to do. At any rate, that app was really nice for testing. I was able to create two tap interfaces and use the proxy to communicate between them. |
|
thanks @kb2ma for this review :) I just squashed and triggered murdock. |
|
I amended a fix to the doc (unsinged => unsigned) and retriggered murdock. |
|
Good stuff @cgundogan, and great to finally work through a PR with you. |
Contribution description
This patch extends the
gcoap_req_init()function to understand client-side proxied RFC7252#section-5.10.2 requests. A request to a proxy does not include anURI_PATHoption, but aPROXY_URIoption. A Proxy-URI is an absolute uri that contains the scheme, host part, and the path of the origin server.(Proxy-Scheme is ignored for now)
The
gcoapexample is extended with a new shell command:Once a proxy is set, all coap packets are sent to the proxy.
Example:
will yield a CoAP GET packet directed to the proxy address that contains the option
Testing procedure
Proxy-URIoption, instead of aURI-PATHoptionIssues/PRs references
n/a