Forum Discussion

ajay1902's avatar
ajay1902
Occasional Contributor
7 years ago

SOAPUI converts Headers and Query parameters to lower case

Hi,

I have a rest request ex. http://192.168.91.101/nic/games/players/ with 2 Parameters

  1. SportsID - Header parameter
  2. sportsID - Query parameter

On trying to import the APIs via Swagger I am not able to see the 2nd parameter and the request displays only one parameter.

While adding the parameter manually I get an error message - Property Name exists. Can someone help to resolve this issue or any workarounds are available.

 

SOAPUI Version 1.9.0

 

RestRequest
SOAPUIPro
  • richie's avatar
    richie
    Community Hero
    7 years ago

    Hi,

     

    erm... I just tried creating an 'authorization' query parm on my REST request when it already had an 'Authorization' header parm and I got the same response you did (parm already exists!)

     

    It looks like the parameter handling in soapui is case insensitive - so its nothing to do with your import etc.  I don't see a way around this other than change the name of your parms so they're unique taking into account the case insensitivity feature.

     

    But I'm not an expert - someone else might have a whizzy idea that I haven't thought of!

     

    cheers,

     

    richie

    • ajay1902's avatar
      ajay1902
      Occasional Contributor
      7 years ago

      Hi Richie,

      We are working with lot of external systems and cannot change the param names in the request especially when it comes to external vendor calls.

      Without passing both values of header and query parameter my request does not work.

       

      This issue happens when I have path parameters in URL matching headers and query parameters as well. :(

      • richie's avatar
        richie
        Community Hero
        7 years ago

        Hi,

         

        Yeah - if you're hitting 3rd party endpoints you're kind of stuck with the URIs  you've been supplied.

         

        I have 1 rubbish idea that's a lot of hard work and inefficient 'I think' it will allow you to do your testing but its essentially hardcoding the requests.

         

        Rubbish idea. 

        The example you've given is header and query parms.  I was kicking around the idea of perhaps if you were using template parameters then not parameterizing the URI values  - i.e. hardcoding the parameters values and create multiple requests in the 'Projects' (for each possible template parm value) section to get around this - obviously this could be a lot of work if there were a large number of possible values for each template parameter - but as I say - this would only work if they were template parms - not query or header parms.

         

        Extending this rubbish idea, then I started thinking about if it was possible to do the same with your query parms.  If you use the 'application/x-www-form-urlencoded' mediatype option for your requests and hardcode the query parms within the body of the requests - this will 'I think', allow you to have a query parm with 'the same' name value as a header parm.  This wont work if the listening web service won't accept the Content-Type header of 'application/x-www-form-urlencoded' - but I asked a solution architect if a web service would inhibit the possibility of allowing the query parms in the body of a request and he didn't think the endpoint would care whether the query parms were in the body of the request rather than within the URI.

         

         

        Only other thing I can suggest (still hoping someone else will have a good idea - I'm intrigued what the workaround for this could be) is you raise a SmartBear technical support ticket to see if SmartBear can answer this.

         

        Sorry I couldn't be more help!

         

        richie