Forum Discussion

fdahdouh's avatar
fdahdouh
New Contributor
3 years ago
Solved

ASCI encoding for mac address failing after 3.20.1 update

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.

 

 

Function Tests
REST
Test Results
Test Setup
  • richie's avatar
    richie
    3 years ago

    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

3 Replies

Sort By
  • richie's avatar
    richie
    Community Hero
    3 years ago

    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's avatar
      fdahdouh
      New Contributor
      3 years ago

      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's avatar
        richie
        Community Hero
        3 years ago

        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