Usability: PathString.StartsWithSegments() with a trailing slash is not intuitive behavior

[NickCraver]

I was trying to do effectively this yesterday:

new PathString("/profiler/test").StartsWithSegments(new Path("/profiler/");

This was, to me, unexpectedly false. And I spent over an hour being an idiot. Once I was in source, I finally realized that a starts-with check of "/profiler" works, while including a trailing slash of "/profiler/" does not. Is this intended behavior? The PathString tests don't actually include a case testing it either way.

Current behavior examples:

	new PathString("/a/b").StartsWithSegments(new PathString("/a/"));  // false
	new PathString("/a/b").StartsWithSegments(new PathString("/a"));   // true
	new PathString("/a//b").StartsWithSegments(new PathString("/a/")); // true

Currently the check of value1[value2.Length] == '/' means whatever's checked against must match or have a trailing slash after it, unless it matches exactly. It seems to be that a /path/ should work here. Is there any objection to this working?

The check could change from:

value1.Length == value2.Length || value1[value2.Length] == '/'

to:

value1.Length == value2.Length || value1[value2.Length] == '/' || value2[value2.Length-1] == '/'

and in the remainder methods, it'd be slightly different with an additional if instead:

if (value2[value2.Length - 1] == '/')
{
    remaining = new PathString(value1.Substring(value2.Length - 1));
    return true;
}

Thoughts? Is there a reason it doesn't behave like this already, or just an ambiguous case? I'd be happy to submit a PR if it's a welcomed change.

[Tratcher]

Fuzzy matching like this creates ambiguity that leads to subtle bugs. We may be able to do this, but I'd want a lot of test cases. Give it a try.

[aspnet-hello]

This issue was moved to dotnet/aspnetcore#2713