[ 
https://issues.apache.org/jira/browse/COUCHDB-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15821898#comment-15821898
 ] 

Richard Ellis commented on COUCHDB-1580:
----------------------------------------

As stated above the RFC 3986 https://tools.ietf.org/html/rfc3986#section-3.3 
allows + as a valid unencoded parameter in the path segments of a URI.

CouchDB's conversion of `+` to space in URI path segments impacts the retrieval 
of documents too.

For example: 
curl http://localhost:5984/mydb/dog+cat
retrieves the document with _id: "dog cat" not the document with _id: "dog+cat" 
which currently requires using
curl http://localhost:5984/mydb/dog%2bcat

It would be nice if this followed the spec so that standard HTTP libraries 
didn't need special casing to work as expected with CouchDB, but backwards 
compatibility could make that challenging.

> 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 was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to