Attach Invoice With Spaces in Filename Causes 404 Error - Xero.NetStandard.OAuth2 9.2.0

[phil000]

SDK you're using (please complete the following information):

• Version Xero.NetStandard.OAuth2 9.2.0

Describe the bug
We have upgraded from Xero.NetStandard.OAuth2 6.0.0 to Xero.NetStandard.OAuth2 9.2.0
When uploading files to attach to an invoice we now get an error code 404, with error content "The resource you're looking for cannot be found"
If we remove the spaces from the filename the upload works correctly.
We have noticed that this error was introduced in Xero.NetStandard.OAuth2 9.0.0
The issue does not occur in 8.1.0.

To Reproduce
Upload a file with spaces.

Expected behavior
File attachment with spaces can be uploaded via .NET API.

[github-actions]

PETOSS-645

[github-actions]

Thanks for raising an issue, a ticket has been created to track your request

[phil000]

We have noted that while the documentation states:
"When the file name includes special characters, the characters should not be encoded unless they're brackets. Brackets must be encoded in order for the call to go through, and all other characters must be unencoded"

If we actually URL path encode the filename the filename with spaces can be uploaded again. (This means replacing spaces with %20, not +)

[DanPatten]

This just happened to me, I had to use System.Uri.EscapeDataString instead of WebUtility.UrlEncode

[phil000]

Yes, FYI the answer is to use System.Uri.EscapeDataString that escapes spaces as "%20"

System.Net.WebUtility.UrlEncode encodes spaces as '+' which does not work.

[DanPatten]

Can the change be listed in releases as a breaking change? This broke production when our users started getting errors after upgrading and there is no mention of this in the changelog.

[joshsj]

Yes, FYI the answer is to use System.Uri.EscapeDataString that escapes spaces as "%20"

System.Net.WebUtility.UrlEncode encodes spaces as '+' which does not work.

+1, this is what RestSharp is using (and therefore what this SDK was using up to 9.x.x).

For reference:

• Where the SDK created the RestClientOptions. No encoder is specified so it uses the default.

• The default encoder uses an extension method internal to RestSharp.

• This extension method that uses Uri.EscapeDataString. It also handles unencoded URLs longer than 32766 characters.

This raises the question of whether compatibility with massive URLs should also be preserved as part of the fix? Seems like the sensible option given we can simply adopt RestSharp's method - there's a simplified version in the codebase already.