Should we treat `+` as `%20` in query part?
Closed this issue · 3 comments
I know that it is not compliant with RFC 3986 as it allows only percent encoding of special characters (and explicitly shows how to encode spaces), but unfortunately + is used as space encoding character in query part by many libraries and even browsers (based on RFC-1866 - first sentence in first section!) - situation is quite clearly described in this answer:
https://stackoverflow.com/questions/2678551/when-to-encode-space-to-plus-or-20#answer-47188851
After query decoding phase users of this library are not able to differentiate if + means really decoded %2B or literal + (which was incorrectly used), so maybe we should decode these incorrectly used pluses as %20 before passing query string to decodeURIComponent.
If you agree I can provide appropriate pull request with this change ;-)
I know that this is not a real argument for discussion, but other libs/tools/frameworks do seem to decode + as space in query strings:
-
Haskell http-types (Servant uses http-api-data which uses http-types):
parseQuerycallsparseQueryReplacePlus True: https://github.com/aristidb/http-types/blob/e5d8ea1cdc36bcbe98db7bc789c60b958ce3eca6/Network/HTTP/Types/URI.hs#L144 -
Haskell Snap framework decodes
+in query keys and values to space: https://github.com/snapframework/snap-core/blob/c711851f08d5dc1602ca793bab474347a9921afa/src/Snap/Internal/Parsing.hs#L327 -
Python3 urllib.parse decodes
+in queries (even in strict mode ;-)): https://github.com/python/cpython/blob/fd1771dbdd28709716bd531580c40ae5ed814468/Lib/urllib/parse.py#L735
Also I've tested on two versions of Firefox and Chromium (latest Firefox nightly 59.0a1 (2017-11-20), Chromium 62.0.3202.89 and Firefox 56.0.2) that this form:
```
<!DOCTYPE html>
<html>
<body>
<form action=".">
<input name="name with spaces" value="value with spaces" />
<input type="submit" value="send" />
</form>
</body>
</html>
```
results in + in queries. The same behavior is observed when I add explicit enctype=application/x-www-form-urlencoded.
The new version of the library doesn't fix this specifically, but it's now possible to solve it in a way that is more natural than having to do custom parsing/printing on the whole URI. 🎉