ASCI encoding for mac address failing after 3.20.1 update

[fdahdouh]

Since the new ReadyAPI 3.20.1 update, REST calls containing mac addresses in the URL are not working anymore.

For example, The following mac 5C:35:3B:D7:10:38 in the URL is interpreted as admin/homegateways/5C%253A35%253A3B%253AD7%253A10%253A38 while it should be /admin/homegateways/5C%3A35%3A3B%3AD7%3A10%3A38/ according to ASCII encoding. In fact, there is an extra "%25" before each column "%3A"

The test steps are old ones and used to work as they are part of regression tests we do. Every test step containing a mac address in the URL is now failing, so there is clearly an issue.

[richie]

Hey @fdahdouh 

This is the double encoding defect that SmartBear introduced when coding another percent encoding fix for v3.20.1

Percent encoding is done by default in ReadyAPI/SoapUI and various other tools.

You're maybe the 3rd of 4th person that's stumbled across this issue since v3.20.1 was released and posted to the forum.

Essentially percent encoded values are being encoded twice - hence changing '5C:35:3B:D7:10:38' to '5C%253A35%253A3B%253AD7%253A10%253A38'

There is a "Disable URL encoding" checkbox in the 'Advanced Options' of your REST API.  Sorry I going on memory here and cant give screenshots cos I just have SOAP projects in ReadyAPI at the moment, but navigate to the API - view the form where you can see the different parameters and move down - you'll see an Advanced Options down arrow - expand this to reveal the "Disable URL encoding"  checkbox.

Tick the box, save the changes and then try re-running your test.  This has provided the other forum users who saw this issue with a workaround.

Cheers,

Rich

[fdahdouh]

Hey @richie 

Thank you for the workaround, it did solve the issue !!

Are you aware of any way to apply this over all the REST calls in a project? I have hundreds of calls imported automatically via swagger protocol, and I would need to go to each Request containing a mac in the URL and change its advanced settings, which is of course not practical.

Otherwise, as you said it is indeed an issue introduced in the new update, I can consider downgrading my ReadyApi

Fadi

[richie · Accepted solution]

Hey @fdahdouh 

Im not aware of a way of updating every single API in the workspace with this im afraid - perhaps one of the other forum users can help.

If you do have the option of rolling back to a previous version - perhaps thats one of the easiest answers?  Although please check the release notes and make sure whatever version you roll back to has latest versions of log4j files.

If you rolll back to a version with old log4j files you can just overwrite them yourself - cos you definitely want the latest files due to that log4j security issue that was found in late November/early December last year

ta

Rich