Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of adam.kocoloski@gmail.com
 designates 209.85.221.111 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=mb3qThcZ5D7VzHEOVvk3JuvJLC+noRGLMHy+vYnKwC34HQHyUKIVTrZq1iZm4CUrXf
         6hOlIa1O8neupohvLd52l5AunvqWppnfd1nXCM7ymsgCA9cg5ZGutd+YubCqRT3tMtoY
         8D7s0RL1If9jtr+KAZgCUSbOFenI02EMaSEqI=
Sender: Adam Kocoloski <adam.kocoloski@gmail.com>
Message-Id: <1A0D7347-FC8A-4FCA-9277-B99DBAA29E32@apache.org>
From: Adam Kocoloski <kocolosk@apache.org>
To: user@couchdb.apache.org
In-Reply-To: <4A0FC837.9040009@griffinbyteworks.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: URL encoding issue
Date: Sun, 17 May 2009 09:52:32 -0400
References: <4A0FC837.9040009@griffinbyteworks.com>

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