Specification is not restricting address from containing query- or fragment parts not ending with "/"
marcushultman opened this issue · 3 comments
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".
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.
@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?
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/.)