i have a API GET object as attached, i use variable parameter like this at endpoint /${dispenseOrderId}
and test case define the id (static value).
test case failed error
I found the issue is due to the space , when def OrderId = “do-test 1” then HTTP/1.1 400 Bad Request
if def OrderId = “do-test” then test case passed.
is this Katalon issue or something i need to tweak at object?
Okay I don’t agree that this is tester doesn’t follow the api spec or test data problem. This is obviously katalon limitation that don’t handle and parse the data correctly when space appear. Because the same data works exactly at other tool like postman or SOAPUI like what other tester mentioned.
maybe get Katalon Developer to access it, why the cause, then you will see the priority.
to me it is critical, as i cannot tell people hey, make sure your test data does not contains space.
Hi @Gan_Jyi_Yng,
At the present Katalon hasn’t supported escaping special characters in the URL’s path, just query parameters. We will supported escaping special characters in path in upcoming releases.
Regards.
@huynguyen but pleaaase add an option to turn it on/off too … just to avoid further headache.
(there may be already users with similar issues which already escaped the url’s)
and kindly document the feature.
and … perhaps it is clever to ship it off by default.
(for backward compatibility reasons)
thank you!
@Gan_Jyi_Yng
as for you … buy a baseball bat and have a ‘private discussion’ with your development team.
endpoints with empty spaces (or any custom characters not ascii) are a terrible idea, lot of stuff can go out of control.
just saying …
LE. you don’t have to actualy use the device i suggested.
just call them on a meeting and display it on the table. 99% will increase the attention.
@Gan_Jyi_Yng aha, so i missunderstood.
for empty spaces in parametters … that should be already implemented. if is not working as expected, is a bug.
however, not that, the comon practice to distinguih query parammeters from the url+endpoint is the ‘?’
so … talk again with your dev team, maybe they are confused
which is not usual, therefore the empty space it is considered in the URL himself as being part of the endpoint (therefore ignored by the parameters escaping feature) and not in the query parameters list
therefore the answer from katalon team:
At the present Katalon hasn’t supported escaping special characters in the URL’s path, just query parameters. We will supported escaping special characters in path in upcoming releases.
Nope. Haha we are design exactly follow api standard like your Your first example. If parameter supported then we use & or _ or =
If it is not parameter then use immediately after /.
My previous post gave full endpoint link. You may check that. Earlier example was just my quick typing to explain what went wrong. It’s definately katalon design issue that can’t handle variable at endpoint. Im very sure about it.
Not about our application design issue.
If now I don’t use katalon variable method, I give full link at katalon object then it works.
Its just simple test, u can try.
Why there is variable function supported but missing to support standard kind of value with space or special characters.
You may ask katalon developer for details.
no is not. query parametters are following the ? in standard implementations (and are reasons why is like this) but looks like your team is re-inventing the wheel.
i won’t argue anymore, it is up to anybody to do it as he like.
you got the answer also from the dev team … so please wait until this will be implemented.
a key=value or an option (flag, value whatever) it should be a query parameter
if it is a parametrized endpoint, well … this is another story. this is again a bad practice (code tend to break more often particularly with negative scenarios, therefore more try-catch needed)
don’t take it wrong, i had also such type of implementations under test.
after a bunch of boundary testing rounds (mostly failed) the dev team decided is too difficult to keep-up with my fantasy and they did it properly
The parameter I taking here is katalon parameter not the endpoint parameter. Katalon provided parameterised variable.
U can do simple test with direct link then replace with katalon parameter.
Or perhaps I can explore more on how postman did it. How Web browser did it.
Further test, to try utf8 or any unicode and see how it needs to be handled.
I guess the Service don’t handle but the one who parse need to. If there is UI data comes in, the ui layer need to handle it. Not the service.
Hi @Gan_Jyi_Yng,
As a workaround, you can define your variable as: ${URLEncoder.encode(dispenseOrderId, “UTF-8”)} so that your path variable will be escaped properly.
Regards.