Send User-Agent header to service

[arthuraraujo-msft]

Related Issues

• Closes Send User-Agent in the request header #40

Why is this change being made?

Service will capture and use the User-Agent header for their own telemetry to know which calls are coming from the Client library. This is a "best-effort" model and there is no service enforcement.

What is being changed?

• Sending "User-Agent" header on every request.
• Format is "Microsoft-SFSClient/<version> (<OS Version>; <Machine Info>)"
  • Examples:
    • Microsoft-SFSClient/1.0.0 (Windows NT 10.0; x64)
    • Microsoft-SFSClient/1.0.0 (Ubuntu 22.04.3 LTS; x86_64)
  • In Windows there is no longer an API to retrieve the version. We must rely on whatever the application that is using the library has registered in a manifest file. At least the machine info should be trustworthy.
  • In Linux it also changes depending on the distribution. The most common place to find distro + version is the /etc/os-release file. After that, the uname() function returns some generic info.

How was the change tested?

• New tests are being added: added lines to functional CurlConnectionTests and SFSClientImplTests to expect the same header in the mock web server.

[JeffMill]

approved with comments

[JeffMill]

this is already incorrect as it's reporting Windows 10 (and there's no such thing as "Windows NT 10") on Windows 11.

WU must need this info as it has OS version specific applicability. I'm guessing it uses GetVersionEx() [ignore the MSDN warnings that have been there since windows 8] or perhaps does a registry read -- see

Get-ItemProperty 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion'

If you can't find a definitive source from WU folks, LMK.

[arthuraraujo-msft]

I see reports on the web that GetVersionEx() function returns unexpected values
Like https://stackoverflow.com/questions/58294262/getversionex-windows-10-detected-as-windows-8

The current suggestion from MSDN is to use these helper functions IsWindows10OrGreater()
That's probably going to be the best guess we can make at this point.
Windows 11 can no longer be detected programmatically and the recommendation is instead to check for capabilities available on the system.

[JeffMill]

as i mention in another comment, while it's undocumented, it's been there as long as I've been at Windows which is a LONG time....for build info it's probably fine for us to use some variant of:

$cv = Get-ItemProperty 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion'
'Version {0} (OS Build {1}.{2})' -f $cv.DisplayVersion, $cv.CurrentBuildNumber,$cv.UBR

which gives the same value as winver.exe, "Version 23H2 (OS Build 22631.3296)" on my dev box.

likely service team just needs a BuildNumber as that's unique across all windows builds ever, e.g.

• The first Windows 10 build number is 10240
• The last Windows 8.1 build number is 9600
• The last Windows XP build number is 3790

so maybe just send up BuildNumber and architecture ID ?

[arthuraraujo-msft]

Cool!
Created #185