Relative URL Resolver (RFC 3986)

RFC 3986 resolves it to http://g, with an empty path. The WHATWG URL Standard, which is what browsers and Node implement, normalises an empty path on a special scheme to /, so you get http://g/. Both are deliberate. It matters when you compare URLs as strings or use one as a cache key, because the two forms are not equal even though they address the same resource.

Section 5.2.2 offers a non-strict variant for backward compatibility with older partial-URI rules: if the reference has a scheme identical to the base’s, ignore it and treat the reference as relative. That turns http:g into http://a/b/c/g instead of leaving it as http:g. The RFC allows it and advises against relying on it; browsers do it. The toggle lets you see which behaviour your case depends on.

Because .. removes the whole preceding segment, and g;x=1 is one segment — the semicolon has no special meaning in the generic syntax. So the path becomes /b/c/y. Matrix parameters written that way are fragile for exactly this reason; a dot-segment anywhere after them takes them with it.

Because the reference is split into path, query and fragment before dot-segments are removed, and /../ there is inside the query. Section 5.4.2 calls this out specifically, noting that some parsers get it wrong by merging the whole reference first — a bug that rarely shows up because queries seldom contain slashes.

No, beyond what resolution itself requires. Case of the scheme and host, percent-encoding, the default port and an empty path are all left as section 5.2 leaves them, because normalisation is section 6 and a separate decision. If you need URLs that compare equal, normalise them deliberately rather than relying on a resolver to do it.