When the CoapRequest::get_path method encounters a slash in a path option, it plainly reports it in the output. Thus, both requests containing the correct sequence of two options Uri-Path: ".well-known", Uri-Path: "core" and requests containing the incorrect[^1] sequence of one option Uri-Path: ".well-known/core" are reported as ".well-known/core" in get_path.
[^1]: It's not incorrect as CoAP request, but it accesses a different resource, which while the server is free to define it, it is very surprising coap://host/.well-known%2fcore.
This leads to server applications silently tolerating erroneous clients, which has already led to such clients not being detected (which then later fail when encountering servers that do URI processing according to RFC7252 Section 6.5)
This behavior is not necessarily wrong, depending on the intention of get_path: It is correct if get_path claims to do a concatenation of the Uri-Path options with slashes, but incorrect if get_path claims to produce the path component of the requested URI. If the latter were to be produced, any slash found in a Uri-Path option would need to be expressed as %2f, any '%' would become '%25', and a few other characters would need conversion too. (Including non-ASCII characters, unless the intention is to produce an IRI path, which would also be valid). Another option would be to make the method fallible and return an error on paths that would need percent encoding; this would also allow a more visible error behavior for components that are not UTF-8, which are currently dropped silently.
When the CoapRequest::get_path method encounters a slash in a path option, it plainly reports it in the output. Thus, both requests containing the correct sequence of two options Uri-Path: ".well-known", Uri-Path: "core" and requests containing the incorrect[^1] sequence of one option Uri-Path: ".well-known/core" are reported as ".well-known/core" in get_path.
[^1]: It's not incorrect as CoAP request, but it accesses a different resource, which while the server is free to define it, it is very surprising
coap://host/.well-known%2fcore.This leads to server applications silently tolerating erroneous clients, which has already led to such clients not being detected (which then later fail when encountering servers that do URI processing according to RFC7252 Section 6.5)
This behavior is not necessarily wrong, depending on the intention of get_path: It is correct if get_path claims to do a concatenation of the Uri-Path options with slashes, but incorrect if get_path claims to produce the path component of the requested URI. If the latter were to be produced, any slash found in a Uri-Path option would need to be expressed as
%2f, any '%' would become '%25', and a few other characters would need conversion too. (Including non-ASCII characters, unless the intention is to produce an IRI path, which would also be valid). Another option would be to make the method fallible and return an error on paths that would need percent encoding; this would also allow a more visible error behavior for components that are not UTF-8, which are currently dropped silently.