API query params should use `+` not `%20` for spaces
See original GitHub issueDescription
Currently, hitting the API with a properly encoded query parameter will return a 400 when spaces are encoded as +
. This is not only valid encoding, but the preferred encoding as per the current HTTP spec. The official Java URLEncoder, for which I am using to build out a program that interacts with the API, follows this spec for application/x-www-form-urlencoded
and only encodes spaces as +
.
Version
Commit: 4f654b98c31c33cafc50785d0c0a7fb4a7dbe859
Steps to Reproduce
Hit the api with something like http://localhost:5055/api/v1/search?query=Matrix+Reloaded
Expected Behavior
I expect to get search results and not an error
Issue Analytics
- State:
- Created 2 years ago
- Comments:9 (4 by maintainers)
Top Results From Across the Web
In a URL, should spaces be encoded using %20 or +?
Within the query string, the plus sign is reserved as shorthand notation for a space. Therefore, real plus signs must be encoded. This...
Read more >URLEncoding of spaces in query parameters + vs %20
My problem is that any space is automatically encoded as a + and not as %20. While it is not necessarily wrong for...
Read more >Use %20 instead of + to encode spaces when submitting a ...
When I create the get request with query parameter that contains the space then it automatically encoded as a + and not as...
Read more >Solved: Handling white spaces in query params
RFC 3986 specifically omits spaces as valid elements of a URI. Typically user-agents will encode your URI for you when they encounter a...
Read more >Spaces and Uppercase characters in URLs - SISTRIX
Spaces are not allowed in URLs. They should be replaced by the string %20. In the query string part of the URL, %20...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Wouldn’t URLs be more correct here than URIs though? i.e. shouldn’t RFC1738 take precedence for a web API over RFC3986?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.