You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Sam Stainsby (JIRA)" <ji...@apache.org> on 2012/10/29 23:06:11 UTC
[jira] [Updated] (COUCHDB-1580) literal '+' in database create URL
should succeed
[ 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