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
file:///c:/public/file.cpp
// 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:
Whatever we do next, we should be sure to look at all file paths in examples to make sure they follow current guidance
Also suggest scrubbing ‘larry-dev’ from examples. You can use contoso where required as a host/domain name, as a well-established fictional term.
From: <>
On Behalf Of Larry Golding (Comcast)
Sent: Thursday, April 5, 2018 9:42 AM
To:
Subject: [sarif] Change draft for #113 (hostname guidance)
Importance: High
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
