If I create a GET request with a URL that contains query parameters, they will be automatically added in the query parameter list in Katalon. If any of the values of my query parameters have spaces in them, they will be automatically URL encoded on execution of the query.
My problem is that any space is automatically encoded as a + and not as %20. While it is not necessarily wrong for query parameters it doesn’t work with OData, which is what our REST-APIs talk. In OData a plus character is used for expansion of child records and is treated as a special character. Therefore an OData REST query requires any space to be encoded with %20 instead.
Is there any way to have Katalon not automatically encode your query param values? If I try to put in %20 manually it will encode the ‘%’-sign instead. Tried seeing if I could escape it but it didn’t seem to make a difference. Maybe I’m missing something obvious
The query parameter basically looks like this:
Name: $filter
Value: TheKeyColumn eq ‘${TheKeyValue}’
Admittedly, one can easily go snow-blind reading the specs but I failed to find a reference to support your statement that “+” is “special” in OData. Can you therefore provide the authoritative source for your claim?
Aside: Searching the above pages is quite easy. Knowing that all authors use the same textual means to discuss specific character notations, I used the browser’s Find feature - Ctrl-F. In your case, I searched for the plus-literal in double quotes: "+"
Again, I found nothing special about OData’s use of “+” that differed from the TBL original.
I’m only human - I may have missed it. But, to file a Bug Report that Katalon/Groovy/Java is breaking the use of a published internet standard, we need to be precise, accurate and rigorous in that reporting.
So, saying that a + sign was a special character in a query string in OData was wrong. What isn’t wrong though is that as you point out with the ABNF, it says it expects percent encoding as specified in the rfc3986.
@Russ_Thomas up to now ithink we cand agree that automaticaly conversion of special characters have to be optional. and why not, to have choices.
there are at least two (maybe three) use cases
I think I agree. The specs are the specs. Without knowing where in the source the URL is being built and how it is being built, it’s all conjecture (hence my callout to the devs).
Said another way, I think the OP has a reasonable question (so far as I understand it) which deserves a considered response - but I don’t have the relevant authoritative information to form an answer (again, hence the callout).
Also, this is not a part of Katalon I use - there could be a dead simple solution I’m unaware of
I probably read the spec a bit too quickly. The mentioning of + is actually in the 4.01 draft spec related to expanded entities and is not actually a part of a query URL but of a context URL: