On Thu, Jan 25, 2018 at 3:37 PM, Dave Thaler <[email protected]> wrote:
> Ok I read this thread through again and checked the code and now I > understand your point. > > You’re saying that > > OICStrcat(eps->addr, OC_MAX_ADDR_STR_SIZE, "%25"); > > should be > > OICStrcat(eps->addr, OC_MAX_ADDR_STR_SIZE, "%"); > > in OCMapZoneIdToLinkLocalEndpoint() because eps->addr should be an IP > literal string, not a URL authority component string. > > either that or it’s ambiguous which it should be, because the > OCEndpointPayload definition in octypes.h doesn’t say what it is, > > which means it’s an API issue since it’s not documented how to use the > public API. > Yep. Something like that anyway. Background: I'm working on a kind of OCF explorer. You send Discovery, and then you can pick out discovered resources for GET. I use the EP stuff in the response payload to construct the GET. The problem is that the stack (and btw I'm going exclusively with the C API) augments the incoming EP address, adding the zone. That would be fine except for the percent encoding. So I pull the addr, use it to send, and get host not found (or such like) since in effect I end up with zone 25wlan0 instead of wlan0 (figured this out using ping6). I think this is a design flaw, since the ep->addr is just an addr, not a URL. Not a huge deal, but the result is basically a waste of time and energy: the stack converts to pct-encoded, which the application must then undo. I guess it's an efficiency thing, but either way it needs to be documented. thanks, -G
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
