Invoke-RestMethod started to fail in v6-beta.9 on a Windows 7 machine

[nightroman]

• This issue happens on a Windows 7 machine. All works fine on Windows 8.1 and 10.
• This issue is new in v6-beta.9. All was fine in previous betas and is fine in v5.

Problem case:

Invoke-RestMethod https://api.github.com/users/nightroman/repos

Expected result:

The command returns the requested data.

Actual result:

The command fails:

Invoke-RestMethod : Version string portion was too short or too long.
At line:1 char:1
+ Invoke-RestMethod https://api.github.com/users/nightroman/repos
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Invoke-RestMethod], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

Some info about the inner exception:

PS> $error.Exception.ToString()
System.ArgumentException: Version string portion was too short or too long.
   at System.Version.VersionResult.SetFailure(ParseFailureKind failure, String argument)
   at System.Version.TryParseVersion(String version, VersionResult& result)
   at System.Version.Parse(String input)
   at System.Version..ctor(String version)
   at Microsoft.PowerShell.Commands.PSUserAgent.get_PlatformName()
   at Microsoft.PowerShell.Commands.PSUserAgent.get_UserAgent()
   at Microsoft.PowerShell.Commands.WebRequestSession..ctor()
   at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.PrepareSession()
   at Microsoft.PowerShell.Commands.WebRequestPSCmdlet.ProcessRecord()
   at System.Management.Automation.Cmdlet.DoProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()

Environment:

PS> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.0.0-beta.9
PSEdition                      Core
GitCommitId                    v6.0.0-beta.9
OS                             Microsoft Windows 6.1.7601 S
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[markekraus]

It looks like this is related to the change in #4937

[thezim]

Note that most web server can and should limit length of individual headers lengths it accepts, I’ve had to do this to adhere to best practices and organizational security requirements on my servers. Usually the request is returned as a 400 series http status code. This might be the case in this instance. For Windows 7 it might be crossing that threshold. If that is the case then the workaround would be to explicitly set the user agent or default the parameter.

[markekraus]

@thezim this is occurring during the generation of the User-Agent header before it is even sent to the remote server. This is related to a change where we made the User-Agent platform aware instead of always reporting Win NT. The underlying .NET would complain on a non-compliant User-Agent (at least for the default generated User-Agent).

[markekraus]

The change in #4937 is using System.Runtime.InteropServices.RuntimeInformation.OSDescription which on Windows 7 produces something like Microsoft Windows 6.1.7601 S and on Windows 10 Microsoft Windows 10.0.15063. The offending code is here:

PowerShell/src/Microsoft.PowerShell.Commands.Utility/commands/utility/WebCmdlet/PSUserAgent.cs

Lines 134 to 135 in 4df7036

	string versionText = OS.Substring(OS.LastIndexOf(" ") +1);
	Version windowsPlatformversion = new Version(versionText);

Since windows 7 is using an extra space after the version number its capturing S as the substring and then failing to parse that as a Version