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