Control parameter encoding in editor based http client
I'm using the editor based http client to query an OData api but I'm having issues. In OData there is a syntax to provide a filter and it looks like this:
GET http://example.com/service/Data?$filter=key eq value
The spaces in the filter expression are important and the only allowed encoding is percent encoding but no matter how I write my query the spaces are always replaced with + upon execution making the query invalid. Is there any way to disable this behaviour?
# Even if I do this
GET http://example.com/service/Data?$filter=key%20eq%20value
# It will be executed as this
GET http://example.com/service/Data?$filter=key+eq+value
Please sign in to leave a comment.
Looks like this is known issue https://youtrack.jetbrains.com/issue/WI-40402. We've also created a separate report: https://youtrack.jetbrains.com/issue/IDEA-234779 - feel free to vote for or comment it in order to get notified about its updates.
Hi team, we also have the same problem. Is there any update on this? Many thanks :)
Hi,
The tickets are still in the "Open" state and there is no ETA that we may share, sorry.
You may subscribe for tickets on YouTrack to get updates on their status.
We are also facing the same issue. It is really annoying to debug, because IntelliJ nowhere actually shows the raw request that was send. Also even when using a perfectly fine encoded URL encoded with %20 instead of spaces, IntelliJ replaces it with a “+”.
This is a bug that should be fixed IMO.
The issue is set to be resolved in upcoming updates. Please check both https://youtrack.jetbrains.com/issue/IJPL-65386 and https://youtrack.jetbrains.com/issue/IJPL-66739.
In my opinion the implemented "solutions" are just workarounds. Having automatic url encoding is fine and a good feature, that I don't want to have disabled.
However replacing %20 with a “+” is not fine. And one could even argue that a space should be encoded with %20 instead of a +.
Also the Request output should show the raw request, so even if there are inconsistencies it is easy to see.
Hi, Github.
We believe that both
+and%20options are acceptable.It will be shown in the 2025.1.2 bugfix release version. It will look like this (both with and without annotation):
Hi,
is there a way to turn-off the automatic URL encoding or modify it?
Even if i write “%20” explicitly in my request it gets converted to “+” before the request is executed, which is not accepted by the OData API.
Basically I'm still facing the exact issue as OP mentioned (but now it is 6 years later ;))
I'm using PyCharm 2026.1.1 Build #PY-261.23567.174
Hi Leppa, since 2025.1.1 the HTTP client includes the
# @no-auto-encodingwhich disables URL encoding for a single request. Your PyCharm 2026.1.1 has it.Could you give it a try?
This worked! Thank you very much :)