Alteryx download tool UTF-8 Encoding when using POST rest API

[GloriousData]

Hi All.

We have upgraded server & designer from 2022.1 to 2024.1 and are experiencing a new issue.

When using the download tool to POST data to a REST API the encoding of the payload/body should be UTF-8 according to Alteryx documentation; but what we see is that the receiving end cannot parse "æ" or "--" (longdash) correctly. E.g. æ becomes "æ"

When running the same workflow from the 2022.1 version the receiving end can parse the data correctly as UTF-8. 

This is causing quite a ruckus for us. 

Using any other 3rd party software, e.g. postman also sends the data correctly.

Workaround is to use the python tool instead; but we would like to identify why the download tool doesnt work. 

Any insights?

Kind regards

GloriousWater

[alexnajm]

is this a matter of just unchecking the encode URL text option in the download tool?

[alexnajm]

You can also select different encoding under the string option - that might work

[GloriousData]

I have tried with/without encode url.

It is however the payload/body of the post request that contains the special characters.

From here under the payload tab: attached screenshot.

https://help.alteryx.com/current/en/designer/tools/developer/download-tool.html#idp378553

it says all data is utf-8 encoded.

I have also played around with content-type header and ';charset=utf-8', aswell is encoding the data before the download tool using 'ConvertToCodepage()' and trying different formats. But it seems the download tool is applying a another encoding when posting the data.

Again, the exact same workflow and configuration works from 2022.1. we are only experiencing this issue on 2024.1

The encoding under string option is to encode the response from the endpoint and not what goes out to another server.

[KGT]

I don't have the later version of alteryx to test or see what has changed. However I do have some info that will help.

The change that you mentioned occurs when UTF-8 contains Iso8859 encoded characters. I think you would be looking for "Iso 8859-1 Latin" if you were to encode these yourself.

Test it by putting the ae character in and run this formula: ConvertToCodePage([Field1], 65001) to convert it to UTF-8 and you will see that change. Not sure how that can be used to fix your problem, but might give some things to test.

[apathetichell]

I'd recommend comparing the localization settings for the specific user and seeing if any of the defaults differ -> if this isn't the case and you don't see any presets - raise a ticket. This could relate to the underlying version of C or Curl or whatever is going on under the hood and not something you can fix.

[GloriousData]

No difference in localization settings for version that works / doesnt work.

Tried changing code page, in localization settings, to UTF-8 and still doesnt work. 

Suppose next step is a ticket then.

Thank you.

[apathetichell]

I'd recommend:

1) generate har files for both versions (see https://confluence.atlassian.com/kb/generating-har-files-and-analyzing-web-requests-720420612.html)

2) downgrade to the earlier version.

You may need a patch to get this to work.

[GloriousData]

Turns out, replacing the download tool fixed the issue.