Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4A101E3B.2090407@griffinbyteworks.com>
Date: Sun, 17 May 2009 16:24:59 +0200
From: Kai Griffin <kai@griffinbyteworks.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: URL encoding issue
References: <4A0FC837.9040009@griffinbyteworks.com>
 <1A0D7347-FC8A-4FCA-9277-B99DBAA29E32@apache.org>
In-Reply-To: <1A0D7347-FC8A-4FCA-9277-B99DBAA29E32@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thank-you, Adam.  I'll keep playing with it.  I wonder if running 
couchdb (v0.9) in Windows has anything to do with it.  I'm using Windows 
because I also want to make use of the couchdb External handler to run 
chunks of legacy code on certain result sets.

I actually typed out those examples by hand, so that leading 
double-quote is not missing in reality (but well-spotted).  In any case, 
I'm not getting an error - just a result with zero rows.

Cheers,
Kai

On 17/05/2009 15:52, Adam Kocoloski wrote:
> Hi Kai, I don't think the URL-encoded double quotes are your problem.  
> I just tried encoding all the double-quotes with curl and it worked 
> fine -- even when using a compound key and a string as the first 
> element of that key.
>
> If you can write up a reproducible test case that shows unexpected 
> behavior I'm sure someone here can take a crack at it.  Best,
>
> Adam
>
> P.S. you missed a leading double-quote in your first query string.  
> Could it be that simple?
>
> On May 17, 2009, at 4:17 AM, Kai Griffin - Relaxing wrote:
>
>> Hi,
>> These past few weeks, I've been re-building our flagship product as a 
>> Flex application, with couchdb as the back end, and this has been 
>> progressing really well.  However, I've hit a strange snag, to do 
>> with URL encoding.  Flex's HTTPService component automatically 
>> url-encodes requests, so that...
>>
>> ....?startkey=["SYD","LAX","2008-01-01T00:00:00Z"]&endkey=["SYD","LAX",2008-01-01T23:59:59Z"] 
>>
>>
>> becomes...
>>
>> ....?startkey=[%22SYD%22,%22LAX%22,%222008-01-01T00:00:00Z%22]&endkey=[%22SYD%22,%22LAX%22,....etc....] 
>>
>>
>> that is, when I look at the Erlang console after the request has been 
>> sent from Flex, I see the request with quotes encoded as %22's as 
>> shown above when issued from Flex.
>>
>> The trouble is, couchdb fails to return any rows when those quotes 
>> are encoded as %22's like that.  When I issue the exact same request 
>> in curl, the quotes are not automatically encoded (they still show as 
>> quotes in Erlang's console), and I get the correct result set for the 
>> view.  I always use group=true, so that's not the difference.
>>
>> What is particularly strange to me, is that a different design/view I 
>> have works perfectly with the following key:
>>
>> ....?startkey=[911,%222008-01-01T00:00:00Z%22]&...etc
>>
>> In this case, the first item in the key is an unquoted integer, but 
>> couchdb is still fine with the quoted date, and correctly returns a 
>> result from either Flex or curl.
>>
>> Any suggestions from a kind soul out there?
>>
>> Cheers,
>> Kai
>
>