Re: Boost.URL: Something Wicked This Way Comes!

From: Gavin Lambert (boost_at_[hidden])
Date: 2021-10-14 00:55:58

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.)