On 14/10/2021 12:52, Vinnie Falco wrote:
Given the following path:
/path/to/file.txt
What should iterating the segments return?
{ "path", "to", "file.txt" } or { "/path", "/to", "/file.txt" }
or something else?
It would have to be the former, because supplying the latter as input to the unencoded variants would presumably try to %-encode the slash (or if it didn't, you'd have problems dealing with slashes elsewhere in the string). Also part of the point of splitting paths into subcomponents is so that you don't have to think about the path separators. Some URI libraries will also explicitly iterate "" or "/" as the first component (by itself) to indicate the difference between absolute and relative URIs, although that could be indicated another way instead. In which case it might be best to render the absolute path as: { "/", "path", "to", "file.txt" }
Given this path:
my/download/folder/
What should iterating the segments return?
{ "my", "download", "folder", "" } or { "my/", "download/", "folder/" } or { "my", "/download", "/folder", "/" }
or something else?
Again, the first.
Given an empty relative-ref (empty string) in a url u, what is the encoded path after executing this statement?
u.segments().push_back( "index.htm" );
Anyone feel free to answer!
I would imagine if u.segments() == { "my", "download", "folder", "" } before the push_back then after == { "my", "download", "folder", "index.htm" }. But that would be a special case only when the trailing component is empty. The app would have to subsequently push_back("") if it was intending to leave a trailing final slash (or just push_back the next component if it wasn't finished yet). But either way it's the app's responsibilty to explicitly indicate whether the URL has a trailing slash or not; they are semantically different and a library cannot decide that for it. Basically it ought to behave somewhat consistently with the URI resolution rules in section 5 of the RFC (except for not replacing a trailing non-empty component). (On that note, url::resolve is undocumented and doesn't seem to have the correct signature -- having both a base and relative parameter only makes sense if it's static or free, but it appears to be declared as instance. Unless the instance is only used as a completely-replaced output, but that seems weird and a free function with return value makes more sense to me.)