[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] Change draft for #113 (hostname guidance)
Comments: If you emit the host name you should still include the // in the examples, so prefer
file:///c:/file.cpp over your example file:/c:/file.cpp.
In practice, your example works. I am beginning to wonder if we’re not off-track in our thinking. If you are rendering a Windows file path (which according to the blog below is not a URI but can be delivered as a URI), then the host name should not be included. The host
name is included if the file is actually being referenced as a UNC path. https://blogs.msdn.microsoft.com/ie/2006/12/06/file-uris-in-windows/
Consider this example, a file that exists in c:\public\file.cpp on MYMACHINE. Assume that c:\public is shared across the network. These renderings are acceptable: // No host name. Why? We are referencing the content as a local windows file path, crammed into a URI // An actual file URI. No drive letter, this file comes across that network from a shared location file://MYMACHINE/public/file.cpp
// By convention, Windows shares drives automatically as C$, D$, etc. This is a valid URI. If you have access to this implicitly shared thing (available to admins), you can access this file file://MYMACHINE/c$/public/file.cpp ALSO:
From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Comcast) The change draft for
Issue #113: “Provide guidance on including a hostname in a uriBaseIdValue” is available: Documents/ChangeDrafts/Active/sarif-v2.0-issue-113-hostname-guidance.docx I’ll move its adoption at the next TC meeting. Thanks, Larry |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]