Invalid json in view param error...

[Rob Law <ro...@flywheelnetworks.com>]

Hi,

I have a graph that tries to access a list like this:

http://localhost:5984/email_events/_list/events/pie/count_with_lead_by_home_price?startkey=["2005/06/25"]&endkey=["2008/06/29
Z"]

and it works as expected.  The problem is I get a JSON error if I replace
the & with it's equivalent %26 like so:

http://localhost:5984/email_events/_list/events/pie/count_with_lead_by_home_price?startkey=["2005/06/25"]%26endkey=["2008/06/29
Z"]


Because of limitations of the graph library (
http://sourceforge.net/forum/forum.php?thread_id=2536346&forum_id=716572) I
am unable to 'just use the & instead'.  Is there some workaround for getting
couch to NOT puke on the %26 vs. & distinction?

thanks for any help

Rob

p.s.  The new show and list functionality is awesome and has enabled me to
create views to aggregate statistics for my data and then reformat them into
more specific json so that my graphing library can access the data directly
from couchdb!

Re: Invalid json in view param error...

[Brian Candler <B....@pobox.com>]

On Tue, Mar 10, 2009 at 01:55:01PM -0700, Rob Law wrote:
> Hi,
> 
> I have a graph that tries to access a list like this:
> 
> http://localhost:5984/email_events/_list/events/pie/count_with_lead_by_home_price?startkey=["2005/06/25"]&endkey=["2008/06/29
> Z"]
> 
> and it works as expected.  The problem is I get a JSON error if I replace
> the & with it's equivalent %26 like so:
> 
> http://localhost:5984/email_events/_list/events/pie/count_with_lead_by_home_price?startkey=["2005/06/25"]%26endkey=["2008/06/29
> Z"]

No, they are not equivalent.

>From RFC 3986:

  "The purpose of reserved characters is to provide a set of delimiting
   characters that are distinguishable from other data within a URI.
   URIs that differ in the replacement of a reserved character with its
   corresponding percent-encoded octet are not equivalent.  Percent-
   encoding a reserved character, or decoding a percent-encoded octet
   that corresponds to a reserved character, will change how the URI is
   interpreted by most applications." 

& is one of those reserved characters.

If this were not the case, it would be impossible to use a query parameter
whose value contained the character '&'

For example:
   ....?foo=bar&baz=bap        -- has two params (foo and baz)
   ....?foo=bar%26baz%3dbap    -- has one param (foo)

Regards,

Brian.