Powershell: Invoke-RestMethod PUT fails

[Agazoth]

Steps to reproduce

 $Header = @{
Authorization = "Basic <MyToken>"
"Content-Type" =  "application/json"
}
Invoke-RestMethod -Uri https://MyOrg.freshservice.com/api/v2/assets/1511/delete_forever -headers $header -method PUT

Expected behavior

The API returns nothing when deleting an entry

Actual behavior

Invoke-RestMethod : {"message":"Content-Type header should have application/json","code":"invalid_content_type"}
At line:1 char:1
+ Invoke-RestMethod @Params
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (Method: PUT, Reques\u2026PowerShell/6.2.0
}:HttpRequestMessage) [Invoke-RestMethod], HttpResponseException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

Environment data

PS C:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.2.0
PSEdition                      Core
GitCommitId                    6.2.0
OS                             Microsoft Windows 10.0.18362
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[vexx32]

From what I remember, I think you need to specify the -ContentType application/json _parameter_ rather than supply it as a header. 🙂

[Agazoth]

Nope. Same result:

PS C:\> $header

Name                           Value
----                           -----
Authorization                  Basic <My Token>

PS C:\> Invoke-RestMethod -Uri 'https://MyOrg.freshservice.com/api/v2/assets/1510/delete_forever' -Headers $Header -Method PUT -ContentType 'application/json'
Invoke-RestMethod : {"message":"Content-Type header should have application/json","code":"invalid_content_type"}
At line:1 char:1
+ Invoke-RestMethod -Uri 'https://cloudeon.freshservice.com/api/v2/asse ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (Method: PUT, Reques\u2026PowerShell/6.2.0
}:HttpRequestMessage) [Invoke-RestMethod], HttpResponseException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

[kvprasoon]

Isn't Delete method to be used here to delete ?
Doesn't Put method required -Body ?

[Agazoth]

@kvprasoon not on this particular API

[Agazoth]

@kvprasoon I actually did test with a body, but got the same error. As you can ser, the exact same code works in Windows Powershell.

[iSazonov]

@Agazoth Could you look our Pester tests for the method and create repo test in the same way?

[Agazoth]

@iSazonov would love to. Where do I find those?

[Agazoth]

I would have to commit my API key to code repository for that to happen.

[iSazonov]

Look WebCmdlets.Tests.ps1 file and our test module in test\tools\WebListener\ - we use the module to emulate server side (and you have not to commit private API key).

/cc @markekraus

[Agazoth]

Don't get the error there:

PS C:\dev\PowerShell> Invoke-RestMethod -Uri http://127.0.0.1:8083/Put -Method Put -Headers @{Authorization = "Basic <MyToken>";"Content-Type" =  "application/json"}

args    :
headers : @{User-Agent=Mozilla/5.0 (Windows NT 10.0; Microsoft Windows 10.0.17763; en-US) PowerShell/6.2.0;
          Authorization=Basic <MyToken>; Content-Length=0; Host=127.0.0.1:8083}
origin  : 127.0.0.1
url     : http://127.0.0.1:8083/Put
method  : PUT

That works in both Windows Powershell and Powershell

[TravisEz13]

But the Content-Type Header was not set, which is the error you are getting, unless the server puts that value somewhere else.

[Agazoth]

@TravisEz13 good point. But it is included in the call.

[markekraus]

~This a docs issue... Content-Type is not supported in -Headers and must be supplied to the -ContentType parameter instead. Perhaps adding a warning when Content-Type is included in the headers dictionary could also be done.~

[markekraus]

On closer inspection... maybe not...

I'm not seeing the content type being sent for any calls..... with or without the -ContentType param and on any method....

Let me dig into this further

[markekraus]

@Agazoth as a temporary work around, do the following:

 $Header = @{
  Authorization = "Basic <MyToken>"
  "Content-Type" =  "application/json"
}
Invoke-RestMethod -Uri https://MyOrg.freshservice.com/api/v2/assets/1511/delete_forever -headers $header -method PUT -body ''

Currently, we do not set a content-type if there is no body present... but setting an empty string body tricks the cmdlet into creating content and applying the content-type header.

[Agazoth]

Thanks Mark, the workaround works :-)

[yar05]

Is there any ETA for this to be fixed?
I cannot use a "workaround" with setting -body '' as my api requires Content-Length: 0 !

I really dont want to be rude but command for interacting with API is missing the basic functionality! How this got passed the testing is beyond me. I just convinced my whole department to use powershell core and now I will have to ask them to uninstall it because powershell API interaction commands are unable to interact with APIs . This is really sad taking to consideration that Azure reps from Microsoft will say PowereShell core is cool to use while it feels like alpha software and what's more sad is that this piece of software ships by default in cloud shell.

[markekraus]

@yar05

I cannot use a "workaround" with setting -body '' as my api requires Content-Length: 0 !

I'm not sure I follow. using -body '' does not send any body at all.

[yar05]

Ok so In fact setting -body '' sets the Content-Type header I must have not looked properly at headers I am sending... The actual reason my code was failing was that I had Content-Length header set in my headers. Powershell 6.2.1 was converting it to "Content-Length: 0, 0" when I removed my own header it seems to work. However PowerShell 5 worked perfectly by just setting "Content-Length: 0" so this looks like yet another bug :/

[markekraus]

@yar05 Re: Content-Length: 0, That's not a bug, that's an implementation difference between 5 and 6.

[markekraus]

I've submitted #10034 to address this.

[yar05]

Is there any actual reasoning behind this behaviour ? If I set X number of headers to a request I expect them to be there while it seems pwsh is trying to be smart about it. Is there a way to run pwsh in some sort of compatibility mode with previous powershell versions? With this implementation I am unable to write a script that will work both on version 5 and core. Calling the specific powershell version from within another powershell script is a bit ugly ... IMHO setting headers manually should ALWAYS overwrite whatever pwsh thinks should be set as a header.

[markekraus]

@yar05

Is there any actual reasoning behind this behaviour

Yes, The content length is determined by the body and is calculated for you by the .NET HttpContent API. You have no control over this header in .NET and therefore not control over this header in PowerShell.

Is there a way to run pwsh in some sort of compatibility mode with previous powershell versions?

No. 6.0.0 was a major version release that introduced many breaking changes. For backwards compatible code you will need version gates. This can be made cleaner and easier with splatting.

IMHO setting headers manually should ALWAYS overwrite whatever pwsh thinks should be set as a header.

And in all but Content-Length, it does (or should anyway if there are others not working, that would be a bug to address). You cannot control this header as it is automatically calculated.

[msftbot[bot]]

:tada:This issue was addressed in #10034, which has now been successfully released as v7.0.0-preview.2.:tada:

Handy links:

• Release Notes