Allow uppercase in URL in the HTTP Request test step
In soapUI 5.2.2 I have to use a property or modify the xml file directly to be able to test against a URL with mixed case it should just be allowed. Refer to Question on How for the the workaround i want to avoid
This creates additional problems when paired with the fact that default parameters in SoapUI are forced to camel case with Project and TestSuite. Any paramaterized url will fail.
Absolutely agree, the problematic part is in method:
It lowercases the endpoint to check if it starts with http/https but leaves it in lowercase, which is incorrect
This issue should be fixed in the next release - please see my accepted pull request:
If you would like to have this feature now, then please build SoapUI from the latest code in GitHub.
This feature request has been implemented in version 5.3 (shown in Bug Fix section 'A bug fix by bearsoftware (GitHub nickname): The Request URL property of the HTTP Request test step did not allow capital letters. (SOAPUIOS-213)')
Please can you move this feature request to status of 'implemented'? Sorry, if you're not the right person to do this.
Also, please can I check that https://sourceforge.net/p/soapui/bugs/ is the right place to log/discuss SoapUI O/S bugs? I sometimes wonder about picking these up but am not sure if this is the right place.
Thanks for your help,
I believe that sourceforge.net may be not the right place any more from my understand as SoapUI source has been moved / relocated to github which might allow to create issue there. Of course, looking forward to hear from @TanyaYatskovska.
For those do not aware workaround for this issue:
By the way, there is simple & clean workaround for this issue if property expansion for the url is used, where capital letter can be supplied which won't be replaced to small.
Thanks for the feedback. As far as I am aware, there is no issue tracking feature in the SoapUI GitHub project - the only correct course of action in GitHub is to code a fix/enhancement and create a 'pull request', which is not the same as having a means to track issues that may or may not be developed.
I also wanted to check with @TanyaYatskovska, who manages the 'Feature Requests' area, as I think it's a nice area and a good way to empower community members to contribute ideas, even if they aren't able to provide solutions. Updating a few statuses might help demonstrate progress and encourage more contribution.
Thanks for the workaround (which is also detailed in the initial feature request), but there is no need for any work-around - as my fix has been accepted, merged and deployed as part of release 5.3.
@rupert_anderson, I am very glad to learn that your fix is part of 5.3.
I thought issue can be tracked as shown below:
Ah yes, I see what you mean! That could be an option, but it appears nobody uses it. Not sure how to create issues here either, possibly I don't have the necessary permissions.
@rupert_anderson, My understanding was that one needs to be in agreement with SmartBear to become a contributor. May be the same is case with Issue, don't know.
Here is the documentation to take part in contribution:
You're quite correct in that one needs to become a contributor before contributing code (as I am already), but that doesn't give permissions to commit directly to the GotHub repository, or at least not in my case. Instead you need to create pull requests and a member of SmartBear then merges your code. As for that GitHub issue tracker it appears unused anyway.
- « Previous
- Next »
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.