"+" in query params do not get URL encoded

[lennertvandevelde]

When using a "+" in one of the query params, e.g.

GET {{host}}records
    ?nrOfResults=100
    &startIndex=0
    &q=+(OrganisationId:226) +(type:image)

the + is not url encoded:

`GET HOST/records?nrOfResults=100&startIndex=0&q=+(OrganisationId:226)%20+(type:image)`  
*accept*: application/json  
*accept-encoding*: gzip, deflate, br  
*user-agent*: httpyac  

meaning the query wilt get different results in this case. I could url encode manually, but I wonder if this is intentional, since the space character is encoded to '%20'?

[AnWeber]

More or less on purpose. Since I don't know whether the string is already encoded, I can't do any active encoding, otherwise I would produce incorrect output.

[lennertvandevelde]

I see, so could identifying encoded parts and changing them back afterwards be something that could be implemented? (That's how I see it's being done in Insomnia for example). If you could point me to the location of the query parser in the code, I could try to make a PR 🙂 (I assume here this should be done?)

[AnWeber]

I don't find your position ideal, as it takes place during parsing and I don't want to make any changes to the content here. This should remain as specified by the user.
It should be implemented similarly to the encodeRequestBody hook. All variables must already be replaced before the encoding is called, i.e. the code may only be executed after requestVariableReplacer. And I have not implemented a query parser anywhere. Not needed. But using URL should get you there.
The path would then even work without PR in a httpyac.config.js, but it would be cool if you get it working. But I wonder if there's any way to avoid accidentally encoding twice.

[mmadson]

So apparently the + symbol is valid in the query string and depending on the client / server in play -- it may actually be an archaic encoding for the space character.

• https://stackoverflow.com/questions/1634271/url-encoding-the-space-character-or-20

Let's say we needed to write a server that supported this older style encoding and you wanted to test that your server was interpreting the + symbol correctly as a space character using httpyac. If httpyac makes the decision to urlencode all + symbols as %2B for you, then you really couldn't test your server's backward compatibility. So, I personally like that httpyac is sticking to the spec here and not making a decision for you.