xdg-open: file: URIs getting handled in unexpected ways
When opening a file:// with the hostname being either empty, localhost
or the actual hostname of the machine get treated as expected.
However when called with any other hostname, the filepath turns into a relative filepath:
scripts/xdg-open "file://not-my-hostname/home/"
xdg-open: file 'not-my-hostname/usr/bin/xdg-open' does not exist
Expected behaviour would be that xdg-open
hand over to a x-scheme-handler/file
.
When the file:
is not followed by a //
exactly that happens as the usual URI handling kicks in there, but in such a case the hostname is missing and the path starts immediately after the colon.
Relevant specifications
The freedesktop specification has the following to say:
File URIs are of the form "file:///", where hostname can be empty, with all non-allowed bytes escaped, containing no escaped '/' or zero bytes.
Which handles the most common cases and is mostly implemented correctly except for the "not my hostname" part.
Some current apps generate URIs of the form "file:/". These are not correct according to RFC1738, so they should not be generated. However for backwards compatibility, it is recommended that such URIs are interpreted as file URIs with an empty hostname.
According to RFC 8089 "file" Scheme both notations are valid.
Such that:
URI | Host | Path | Handled correctly in xdg-open ? |
---|---|---|---|
file:///foo/bar | /foo/bar | yes | |
file://foo/bar | foo | /bar | when hostname matches local machine¹ |
file:/foo/bar | /foo/bar | no² | |
file:foo/bar | foo/bar | no² |
¹ when not it gets incorrectly treated as if the path was foo/bar
² passed directly to scheme handler or BROWSER
instead of extracting the filepath and opening
Relevant quote from RFC 3986 section 3.2. Authority:
The authority component is preceded by a double slash ("//") and is terminated by the next slash ("/"), question mark ("?"), or number sign ("#") character, or by the end of the URI.