Inconsistencies with dot-segment normalization

[JordanMilne]

It seems like "%2E%2E" should be treated the same as ".." during dot segment normalization, but it isn't:

> URI('/foo/../bar').normalize().toString()
'/bar'
> URI('/foo/%2E%2E/bar').normalize().toString()
'/foo/../bar'

Looks like it's because the normalization of %2E -> . happens after the paths are resolved.

Another one:

// v correct
> URI('/foo/.bar').normalize().toString()
'/foo/.bar'
// v incorrect
> URI('/foo/..bar').normalize().toString()
'bar'

[rodneyrehm]

It seems like "%2E%2E" should be treated the same as ".." during dot segment normalization, but it isn't:

While Remove Dot Segments does not mention percent encoded values at all, it looks like you're right in the .normalize() context.

 URI('/foo/..bar').normalize().toString()
'bar'

this is definitely a bug.

---

Are you up to the task and want to send a PR?

There are a bunch of tests for .normalizePath() already.

From today's perspective I'd likely rewrite URI.normalizePath() to base on URI.segmentCoded() and work on the array of segments, rather than string mutation.

[JordanMilne]

While Remove Dot Segments does not mention percent encoded values at all, it looks like you're right in the .normalize() context.

It's not clear to me from the RFC what order syntax normalizations should be applied in, but it looks like most browsers apply Percent Encoding Normalization before removing dot segments:

> new URL("http://example.com/foo/%2E%2E/bar").pathname
"/bar"

Are you up to the task and want to send a PR?

Sure thing, might take me 'til the weekend though

[rodneyrehm]

Sure thing, might take me 'til the weekend though

no worries, take your time :)