Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of
 gcdcu-couchdb-user@m.gmane.org designates 80.91.229.3 as permitted sender)
To: user@couchdb.apache.org
From: Sam Stainsby <sam@sustainablesoftware.com.au>
Subject: Re: literal '+' in URL when creaitng a database
Date: Mon, 29 Oct 2012 08:26:16 +0000 (UTC)
Lines: 32
Message-ID: <k6lej7$h20$2@ger.gmane.org>
References: <k6l9sn$h20$1@ger.gmane.org>
	<CAJNb-9owMQJbcL17_3qX_X2eugyCYQrhCqUppUG0G8+Gzjk4CQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: Pan/0.136 (I'm far too busy being delicious; GIT 926a150
	git://git.gnome.org/pan2)

On Mon, 29 Oct 2012 08:23:09 +0100, Benoit Chesneau wrote:

> On Mon, Oct 29, 2012 at 8:05 AM, Sam Stainsby

>> I understand that '+' has special significance in the query part of a
>> URL, but not the path part, so I think the above should work.

> '+' would mean space on the file system if I recall correctly. Which
> could be problematic on some platforms.

Hi Benoit,

How couch encodes that as a file name in an OS would be internal to 
couch, so if couch is using query string encoding for the file name, that 
may be a good choice for OS portability. However, my understanding is 
that '+' representing a space in a URL is only valid for the *query* part 
of a URL.

"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

Cheers,
Sam.