+ symbol in safe name seems to be unhandled in pspas mod

[AaronG1234]

Describe the issue safe names created in PVWA with a + symbol seem to create what looks like a webrequest 404 error (perhaps not escaped somewhere)

To Reproduce Steps to reproduce the behavior:

1. Create a safe with a + name in it: humans+r+dumb via PVWA
2. using powershell and psPAS enumerate safes with get-passafe -findall (successful)
3. using powershell and psPAS attempt to get info on safe get-passafe "humans+r+dumb" or set-passafe, etc.

also, I was not able to get it to work with "humans%2Br%2Bdumb" but doesnt mean that URL encoding isnt the right direction, i just couldnt through the module.

Expected behavior as dumb as it is to create a safe with a + symbol (in this case it was actually ME), i would expect get-passafe "humans+r+dumb" to return a pspas "safe" object Note: PVWA can alter the settings of these safes [like reassign a CPM], i know the API and PVWA are distinct beasts, but i just wanted to demonstrate that the API should in theory be able to work with these... even if the symbols are not the best idea

Screenshots & Console Output If applicable, add screenshots to help explain your problem.

Console Output Code Block: PS C:\Users\xxxxxxx> Get-PASSafe -SafeName "team_secops%2Beas" Invoke-PASRestMethod : 404 File or directory not found Server Error 404 File or directory not found The resource you are looking for might have been removed had its name changed or is temporarily unavailable At line:106 char:13

• ... $result = Invoke-PASRestMethod -Uri $URI -Method GET -WebSession $S ...

• 
  + CategoryInfo          : NotSpecified: (
  404 - F...ble.

:ErrorRecord) [Invoke-PASRestMethod], Exception

• FullyQualifiedErrorId : 404,Invoke-PASRestMethod

**Your Environment**
Include relevant details about your environment

* PowerShell Version: 5.1
* psPAS Version: 4.3.65
* CyberArk Version: 11.1

**Additional context**
Add any other context about the problem here.

[pspete]

Hi @AaronG1234 psPAS escapes all values used in the URLs, this can be seen in the verbose output - believe the 404 result here is the result of IIS being configured to not "Allow double escaping".

[pspete]

This is not a configuration recommendation, but was able to be reproduce the reported behaviour:

• IIS Request Filtering "Allow double escaping" disabled
  • 404 as reported
• IIS Request Filtering "Allow double escaping" enabled
  • Success (get/set etc. work)

[pspete]

Closing, as the cause related to server config. Can reopen if there is any insight into any fix which can be applied in the modules code.