[
https://issues.apache.org/jira/browse/COUCHDB-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Stainsby updated COUCHDB-1580:
----------------------------------
Description:
Plus ('+') characters only have special meaning in the query part of a URL, not
the path part. So, the following should succeed:
curl -X PUT 'http://localhost:5984/aaa+bbb'
but instead it results in an error: "Only lowercase characters (a-z), digits
(0-9), and
any of the characters _, $, (, ), +, -, and / are allowed ...". Couchdb is
requiring the '+' to be percent encoded, so this *does* succeed:
curl -X PUT 'http://localhost:5984/aaa%2bbbb'
This causes problems with the latest Dispatch library (version 0.9.3), which
(quite correctly) leaves '+' characters intact when adding a path segment. If
you pre-encode the '+', then you'll get double encoding instead, so there is no
neat solution.
Refer to RFC 3986 Appendix A's BNF to see that '+' is a valid path segment
character. See also:
"Within the query string, the plus sign is reserved as shorthand notation for a
space. Therefore, real plus signs must be encoded. This method was used to make
query URIs easier to pass in systems which did not allow spaces."
(http://www.w3.org/Addressing/URL/4_URI_Recommentations.html)
"For HTTP URLs, a space in a path fragment part has to be encoded to "%20"
(not, absolutely not "+"), while the "+" character in the path fragment part
can be left unencoded."
(http://www.lunatech-research.com/archives/2009/02/03/what-every-web-developer-must-know-about-url-encoding)
was:
Plus ('+') only have special meaning in the query part of a URL, not the path
part. So, the following should succeed:
curl -X PUT 'http://localhost:5984/aaa+bbb'
but instead it results in an error: "Only lowercase characters (a-z), digits
(0-9), and
any of the characters _, $, (, ), +, -, and / are allowed ...". Couchdb is
requiring the '+' to be percent encoded, so this *does* succeed:
curl -X PUT 'http://localhost:5984/aaa%2bbbb'
This causes problems with the latest Dispatch library (version 0.9.3), which
(quite correctly) leaves '+' characters intact when adding a path segment. If
you pre-encode the '+', then you'll get double encoding instead, so there is no
neat solution.
Refer to RFC 3986 Appendix A's BNF to see that '+' is a valid path segment
character. See also:
"Within the query string, the plus sign is reserved as shorthand notation for a
space. Therefore, real plus signs must be encoded. This method was used to make
query URIs easier to pass in systems which did not allow spaces."
(http://www.w3.org/Addressing/URL/4_URI_Recommentations.html)
"For HTTP URLs, a space in a path fragment part has to be encoded to "%20"
(not, absolutely not "+"), while the "+" character in the path fragment part
can be left unencoded."
(http://www.lunatech-research.com/archives/2009/02/03/what-every-web-developer-must-know-about-url-encoding)
> literal '+' in database create URL should succeed
> -------------------------------------------------
>
> Key: COUCHDB-1580
> URL: https://issues.apache.org/jira/browse/COUCHDB-1580
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
> Affects Versions: 1.2
> Environment: Linux Ubuntu 12.04
> Reporter: Sam Stainsby
> Priority: Minor
>
> Plus ('+') characters only have special meaning in the query part of a URL,
> not the path part. So, the following should succeed:
> curl -X PUT 'http://localhost:5984/aaa+bbb'
> but instead it results in an error: "Only lowercase characters (a-z), digits
> (0-9), and
> any of the characters _, $, (, ), +, -, and / are allowed ...". Couchdb is
> requiring the '+' to be percent encoded, so this *does* succeed:
> curl -X PUT 'http://localhost:5984/aaa%2bbbb'
> This causes problems with the latest Dispatch library (version 0.9.3), which
> (quite correctly) leaves '+' characters intact when adding a path segment. If
> you pre-encode the '+', then you'll get double encoding instead, so there is
> no neat solution.
> Refer to RFC 3986 Appendix A's BNF to see that '+' is a valid path segment
> character. See also:
> "Within the query string, the plus sign is reserved as shorthand notation for
> a space. Therefore, real plus signs must be encoded. This method was used to
> make query URIs easier to pass in systems which did not allow spaces."
> (http://www.w3.org/Addressing/URL/4_URI_Recommentations.html)
> "For HTTP URLs, a space in a path fragment part has to be encoded to "%20"
> (not, absolutely not "+"), while the "+" character in the path fragment part
> can be left unencoded."
> (http://www.lunatech-research.com/archives/2009/02/03/what-every-web-developer-must-know-about-url-encoding)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
