Closed JKRhb closed 1 year ago
Should we do the same for uriLocationPath
?
Should we do the same for
uriLocationPath
?
Good point!
I adjusted the code, I am not entirely sure if this is the correct way to handle this option, though. Let me know if you have any suggestions :)
We could sneak a peak at Californium :)
Seems similar to our approach, but if we want to make the code a tiny bit shorter:
var trimmedPath = fullPath;
if (fullPath.startsWith('/')) {
trimmedPath = fullPath.substring(1);
}
Good catch, could clean up the locationPath
setter a lot :)
Good catch, could clean up the locationPath setter a lot :)
I think we can do the same for uriPath
, but it's just nitpicks anyway. The PR LGTM!
I think we can do the same for
uriPath
, but it's just nitpicks anyway.
Cleaned up that method as well now :)
The PR LGTM!
🎉
Great work on RFC compliance in general, and sorry for the sloppy URI/query validation I added in my previous PR. Should have checked the RFC, I've been a bit stressed and busy with other things lately.
Interacting with other CoAP libraries, we noticed in my project that URI paths seem to not be converted into options correctly. In particular, it seems as if empty URI path segments are supposed to be converted into empty URI-path options. Currently, these empty segments are removed from the URI path completely.
This PR adjusts the corresponding creation method accordingly, which should also make the library's behavior more consistent with section 6.4 of RFC 7252.