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

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2021-10-18 16:10:04

On Sun, Oct 17, 2021 at 8:56 PM Gavin Lambert via Boost
<boost_at_[hidden]> wrote:
> You can perhaps argue that the leading "/" element is not needed if
> there is another method to indicate whether the URI is absolute or not;

Yep, you're right that is needed and we have these functions

    bool url_view::is_path_absolute() const noexcept;

    // returns true on success
    bool url::set_path_absolute( bool should_be_absolute );

set_path_absolute(false) can fail in the one case where there is an
authority and at least one segment.

>    - "/.//foo/bar"      => { ".", "", "foo", "bar" }

The list looks fine except for the above, which I think has to be {
"", "foo", "bar" } for the reason that assigning the path should give
you back the same results when iterated:

    url u = parse_uri( "http:" ).value();

    u.segments() = { "", "foo", "bar" };

    assert( u.encoded_url() == "http:/.//foo/bar" );
    assert( u.segments() == { "", "foo", "bar" } ); // same list

If we then remove the scheme, I think the library needs to remove the
prefix that it added. Not a full "normalization" (that's a separate
member function that the user calls explicitly). The rationale is that
if the library can add something extra to make things consistent, it
should strive to remove that something extra when it can do so. Yes
this means that if the user adds the prefix themselves and then
performs a mutation, the library could end up removing the thing that
the user added. I think that's ok though, because the (up to 2
character) path prefixes that the library can add are all semantic
no-ops even in the filesystem cases.

> It's worthwhile considering these things from the start, as they can
> inform design of your baseline (such as compatibility of path segment
> iteration).

Library-added prefixes are semantic no-ops anyway, even for the
filesystem case, so they should not change anything in terms of
filesystem compatibility. And they don't appear in segment iteration
so it is like they were never there, thus zero impact.

Thanks