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

From: Gavin Lambert (boost_at_[hidden])
Date: 2021-10-18 03:55:37

On 18/10/2021 15:06, Vinnie Falco wrote:
> On Sun, Oct 17, 2021 at 7:04 PM Gavin Lambert wrote:
>> Getting back to this point, as I mentioned in another branch it looks
>> like {std,boost}::filesystem breaks down "/foo/bar/baz.htm" to { "/",
>> "foo/", "bar/", "baz.htm" }.
> 
> I'm not sure that's viable or correct for URL paths though.

Actually, sorry, I was getting my wires crossed.  The above is how 
.NET's System.Uri class behaves.  (So Microsoft evidently thinks it's 
viable for URLs.)

{std,boost}::filesystem will break down "/foo/bar/baz.htm" to { "/", 
"foo", "bar", "baz.htm" } (and "/foo/bar/" to { "/", "foo", "bar", "" } 
-- except boost:: returns "." for the final element).

Filesystems perhaps have a slight advantage here as AFAIK no filesystem 
accepts an escaped path separator within a filename (modulo Linux 
allowing backslashes; including WSL, but the latter actually stores a 
different character), while there's no rule against %2F appearing inside 
an URL path (although it's more common in a query string).  But this 
isn't insurmountable.

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; 
Filesystem includes it for lexicographic sorting & comparison purposes, 
but those don't entirely apply since we're only considering part of the 
URL here anyway.  So that is more justifiable.

With that in mind, it's probably reasonable for this iteration:

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

But as I said before, this makes it impossible to convert between 
relative and absolute paths via the path-segment API alone (as the 
initial "/" isn't exposed, and instead a different method must be used). 
  Whether this is a feature or a bug is in the eye of the beholder.

>> On a related note, you should strongly consider cross-compatibility with
>> {std,boost}::filesystem::path anyway, since inevitably an URL-parsing
>> library will hit one of the following scenarios sooner or later:
> 
> Yeah, I agree that there needs to be something to facilitate working
> with paths that are formed from URLs. I haven't given it any thought
> yet because I am still trying to finish the baseline functionality.

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