couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Stainsby (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (COUCHDB-1580) literal '+' in database create URL should succeed
Date Mon, 29 Oct 2012 22:06:12 GMT

     [ 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 ('+') 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)

    
> 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

Mime
View raw message