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
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. :(
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
I also just noticed this post (https://community.smartbear.com/t5/SoapUI-Pro/URLs-are-converted-to-lower-case/m-p/43120#M22327) which says soapui treats the URI's in requests as case insensitive. The response by SmartBear on the post is that there is an open defect on this.
The fix might also include resolving your issue also, I'd definitely contact SmartBear if I were you,
richie
