Open CThuleHansen opened 4 years ago
I am revisiting this issue after hitting an unrelated issue.
Wikipedia summarizes rules regarding the number of slashes as follows: As I understand it the difference between a single and double slash for file URI is:
Following only these rules it would seem:
file:/path/ : correct, host=localhost implicitly
file://localhost/ : correct
file://path/ : illegal, no hostname appears between
file:///path/ : correct, first // implies that hostname will appear, in this case empty, ultimately defaulting to localhost
empty hostname rfc 3986:
If the URI scheme defines a default for host, then that default applies when the host subcomponent is undefined or when the registered name is empty (zero length). For example, the "file" URI scheme is defined so that no authority, an empty host, and "localhost" all mean the end-user's machine, whereas the "http" scheme considers a missing authority or empty host invalid.
Let's denote the number of slashes by ux for example 'file:/path/' is u1, 'file://path/ is u2
There seems to be a lot of misunderstandings of how to encode Windows paths to file URIs. At its core, this stems from the fact that the RFC8089 specifies the syntax of a file URI, but not how the various operating systems convert their respective paths. Appendix E.2 does list some non-standard syntax variations, specific to windows:
This is intended to support the minimal representation of a local file in a DOS- or Windows-like environment, with no authority field and an absolute path that begins with a drive letter. For example: o "file:c:/path/to/file" URIs of the form "file:///c:/path/to/file" are already supported by the "path-absolute" rule. Note that comparison of drive letters in DOS or Windows file paths is case insensitive. In some usages of file URIs, drive letters are canonicalized by converting them to uppercase; other usages treat URIs that differ only in the case of the drive letter as identical.
To maximize compatibility it makes sense to emit the most common representation, which judging by the links is u3. However, FMUs should also aim to consume other legal representations.
The first references provide a number of recommendations for Unix and Windows
Here's the summary. If you are converting from a file path to a URI reference: Absolute paths on Unix-like filesystem (/etc/hosts): Use u3 notation file:///etc/hosts Relative paths on Unix-like filesystem (../src/main/): Use relative reference ../src/main Absolute paths on Windows filesystem (C:\Documents and Settings): Use u3 notation file:///C:/Documents%20and%20Settings/ Relative paths on Windows filesystem (..\My Documents\test): Use relative reference ../My%20Documents/test UNC paths on Windows (\laptop\My Documents\Some.doc): Use u2 notation file://laptop/My%20Documents/Some.doc
If you are converting from a URI reference to a file path, in addition to the above, Handle u0 notation file:C:/Documents%20and%20Settings/ Handle u1 notation file:/etc/hosts Handle u2 notation file://localhost/etc/hosts and file://localhost/C:/Documents%20and%20Settings/ for local path Handle u4 notation file:////laptop/My%20Documents/Some.doc
Links: blogpost discussing resolving URIs on Unix and Windows Microsoft IE blogpost Microsofts .NET api, see 'Implicit File Path Support'
So to understand what you are saying - You are backing the proposal of using /// right?
Yes, I think we should follow the recommendations of /// for absolute paths on both Unix and Windows
URIs on windows are allowed with single slags, i.e.
file:/c:/...
but it is more typical to usefile:///c:/...
as also mentioned in https://tools.ietf.org/html/rfc8089 in Appendix B (and D.2)Therefore, it could make sense to chance Maestro to use
///
instead of/