On Sun, Oct 17, 2021 at 8:56 PM Gavin Lambert via Boost
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