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

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

On 17/10/2021 07:53, Vinnie Falco wrote:
> On Sat, Oct 16, 2021 at 11:10 AM Phil Endecott wrote:
>> I would be very interested to see a comparison of how your
>> decomposition of paths into segments, and the reverse, compares
>> to what std::filesystem::path does, and rationale for the
>> differences.
> 
> To be honest I have no idea, I have never used std::filesystem to any
> meaningful extent.

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" }.

Like it or hate it, this is the standard now, and it's likely that 
people would expect that Boost.Url would use similar segmentation.

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:

   - conversion of an absolute file:/// uri to a filesystem path and back
   - conversion of a relative uri path (only) to a relative filesystem 
path and back (or perhaps better: conversion of [absolute uri, base uri, 
base path] to absolute path)

While you could get away with doing the second kind of interop only with 
complete strings, having an explicit method for it is better as it 
allows you to encourage security checks such as considering it illegal 
to use a relative path that would escape the base path.