HTTP 1.1 400 bad request when the parameter value has space

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?

“response” : {
“status” : 400,
“statusText” : “”,
“httpVersion” : “”,
“cookies” : ,
“headers” : [ {
“name” : null,
“value” : “HTTP/1.1 400 Bad Request”
},

Test Case:
import static com.kms.katalon.core.testobject.ObjectRepository.findTestObject
import static org.assertj.core.api.Assertions.*

import com.kms.katalon.core.webservice.keyword.WSBuiltInKeywords as WS
import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI

import groovy.json.JsonOutput as JsonOutput
import groovy.json.JsonSlurper as JsonSlurper
import internal.GlobalVariable

WebUI.delay(5)

def OrderId = “do-test 1”

getDispenseOrder(OrderId)

def getDispenseOrder(def OrderId){
def response = WS.sendRequestAndVerify(findTestObject(‘Object Repository/Web Service Request/ApiGet’, [(‘OrderId’) : OrderId, (‘SiteHostName’) : GlobalVariable.SiteHostName, , (‘SitePort’) : GlobalVariable.SitePort]))
WS.verifyResponseStatusCode(response, 200)

}

ApiGet.zip (851 Bytes)0.har (2.4 KB)

Respondents be aware this topic was answered in an old thread here: Rest API Request with parameter value containing spaces must be filled with %20

I’ll leave this open and close the old one.

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.

There are two ways to get something changed:

  1. Report a bug.
  2. Post a suggestion.

In over a year, two people have had cause to mention this. I’m saying this so you can gauge how it might be received. What priority would you give it?

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.

critical-no workaround provided from katalon

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
thank you for confirming this will be supported soon.
great!

@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

1 Like

that is an endpoint.
the right way to do it is:

/api/get?itemid=blah space&other_param=whatever

so you have to tell your devs ‘please don’t confuse a path with a parametter’

Hmm I don’t really get you.
You can see the har file, what has been posted from my test data thru katalon. Then katalon failed to parse it correctly.

This link works correctly in postman or any api tool, even chrome browser can handle it well. It’s standard way how system handle such case.
This data, treated as raw.
http://localhost:8020/api/dispenseorder/do-test a5
Any standard system should read it as
http://localhost:8020/api/dispenseorder/do-test%20a5

what i am trying to say is, that ‘normal practice’ to implement an rest api is:

{protocol}://domain.foo/path/to/endpoint?param1=value1&param2=value2

with your application the implementation seems to be:

{protocol}://domain.foo/path/to/endpoint/param=value

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

1 Like

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.

you pass it via katalon parameter.
but is part of the endpoint

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.

Thanks. I’ll try it.