Specification is not restricting address from containing query- or fragment parts not ending with "/"

[marcushultman]

The specification says:

Note that the right-hand side of the mapping (known as the "address") must start with /, ../, or ./, or be parseable as an absolute URL, to identify a URL.

It does not mention any restriction from what I must assume to be a valid URL (RFC 3986 and referenced RFCs). Yet the reference implementation asserts that the full (href) version of the URL ends with "/". This limitation seem pretty arbitrary (and not mentioned in the specification). Is there a reason why query- and fragment parts are not allowed (unless they end with "/", which I see no functional reason for)?

I would expect these parts of the URL to be legal, and usable even when resolving a relative path for trailing slashes "packages".

@domenic

[jkrems]

This is specifically when the key ended with a slash, which follows from this part of the spec:

      1. [=Report a warning to the console=] that an invalid address was given for the specifier key |specifierKey|; since |specifierKey| ended in a slash, the address needs to as well.

[marcushultman]

@jkrems I see. So the specification (spec.bs) does mention it but the README does not. This formally addresses this issue statement. But before I close this issue, I must ask, was allowing query- & fragment parts of the address ever evaluated, and if so, why didn't it make it into the spec? If it wasn't evaluated, would it be reasonable to do that?

[domenic]

You can combine them, e.g. if you are mapping "foo/": "bar/" then foo/x?y#z will map to bar/x?y#z.

You cannot map "foo/": "bar?y#z" because then foo/x would map to bar?y#z/x which is probably not what you intended.

(Also, reminder that RFC 3986 is obsolete and on the web we use https://url.spec.whatwg.org/.)