INTO-CPS-Association / maestro

Maestro a Co-Simulation Orchestration Engine
https://build.overture.au.dk/jenkins/job/maestro/
19 stars 3 forks source link

uri-parser single slash or double slash #34

Open CThuleHansen opened 4 years ago

CThuleHansen commented 4 years ago

URIs on windows are allowed with single slags, i.e. file:/c:/... but it is more typical to use file:///c:/... as also mentioned in https://tools.ietf.org/html/rfc8089 in Appendix B (and D.2)

o A traditional file URI for a local file with an empty authority. This is the most common format in use today. For example:

  *  "file:///path/to/file"

o The minimal representation of a local file with no authority field and an absolute path that begins with a slash "/". For example:

  *  "file:/path/to/file"

Therefore, it could make sense to chance Maestro to use /// instead of /

clegaard commented 3 years ago

I am revisiting this issue after hitting an unrelated issue.

Wikipedia summarizes rules regarding the number of slashes as follows: image 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'

CThuleHansen commented 3 years ago

So to understand what you are saying - You are backing the proposal of using /// right?

clegaard commented 3 years ago

Yes, I think we should follow the recommendations of /// for absolute paths on both Unix and Windows