Client.GetObject to SwiftStack fails when object path contains space characters

[rfeezel]

The URL being sent to SwiftStack appears to contain "+" characters in place of " " (space) characters. SwiftStack apparently wants spaces to be encoded as %20. I modified line 34 of SwiftUrlBuilder.cs to read:
var url = storageUrl + "/" + containerId.Encode().Replace("+","%20") + "/" + objectId.Encode().Replace("+", "%20");
And it seems to work. I don't know, however, if this is technically correct or might break something else.

[alejandro1585]

I second this issue. It is still present in the library. Your approach seems to be ok, the only problem I see is that it only accounts for space, but not other characters that when encoded may end up changing the original name of the file.

[alejandro1585]

After forking the project, I see the following in the code (StringExtensions.cs):

public static string Encode(this string stringToEncode)
        {
            var stringSplit = stringToEncode.Split('/');
            var stringEncoded = stringSplit.Select(x => Uri.EscapeDataString(x));
            return string.Join("/", stringEncoded);
            
        }

Which would solve this issue, however, when installing the Nuget Package I don't see the above. Could it be possible that the fix was added but the package was never updated to have it?

[alejandro1585]

I took the liberty of packaging the latest and greatest source code version and publishing it as a nuget package. It's not best practice as you won't get any updates if the original authors make a change, but at least is out there so you can easily install it as a package with the fix to this issue. https://www.nuget.org/packages/SwiftClientUpdated/2.1.5-beta#usedby-body-tab

[cristipufu]

@alejandro1585 why not make a pull request and contribute to this repo?

[alejandro1585]

@cristipufu I see the enhancement is already part of the master branch; however, it seems like the nuget package does not have this change. I see the commit was made by merqlove (see screenshot). As a result, there's no need for a PR on my end, perhaps a new version of the package can be released with the latest and greatest. What are your thoughts?