couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jared Scheel <jare...@gmail.com>
Subject Re: URL encoding issue
Date Tue, 19 May 2009 15:12:59 GMT
We've been discussing this issue here as well:
http://www.mail-archive.com/dev@couchdb.apache.org/msg02730.html

I think that couchdb could really benefit from supporting an override
instead of relying on a workaround with _bulk_docs though. The
x-http-method-override header has been used in several APIs, including
all of Google's, to get around this limitation in a clean fashion.

-Jared


On Tue, May 19, 2009 at 3:04 AM, Jan Lehnardt <jan@apache.org> wrote:
>
> On 19 May 2009, at 02:11, Kai Griffin wrote:
>
>> Hi Sam, the Flex HTTPService only supports two content-types -
>> x-www-form-urlencoded and xml - but the former of these works fine.  My
>> application won't need DELETE, fortunately.  As for PUT, I'd forgotten about
>> that limitation - I suppose I could POST to _bulk_docs as a work-around?
>
> That works.
>
> Cheers
> Jan
> --
>
>
>>  Fortunately, the client-side of the application (that is, at the Flex
>> end) consists mainly of read-only operations, and most of the writing to
>> database is handled by processes located on the server-side over night.  I'm
>> also using the external process feature of couch to launch legacy code on
>> the server which has been cannibalised from our old app, which performs
>> lengthy bulk record update operations.
>>
>> Many thanks for pointing these out.
>>
>> By the way, the mystery view issue that originally prompted this thread is
>> now resolved; thanks, all, for the help.
>>
>> Kai
>>
>> On 19/05/2009 01:32, Samuel Wan wrote:
>>>
>>> Do you need to set the json content-type headers in the HTTPService
>>> requests?
>>>
>>> BTW, the flash player doesn't support delete or put, will that be a
>>> problem for you?
>>>
>>> -Sam
>>>
>>> On Mon, May 18, 2009 at 1:35 PM, Kai Griffin <kai@griffinbyteworks.com>
>>> wrote:
>>>
>>>> On 18/05/2009 21:54, Rhett Sutphin wrote:
>>>>
>>>>> Hi Kai,
>>>>>
>>>>> On May 18, 2009, at 2:40 PM, Kai Griffin wrote:
>>>>>
>>>>>
>>>>>> Hi Brian,
>>>>>>
>>>>>> I've been escaping the square brackets and double quotes in curl,
like
>>>>>> this  \[\" ....\" \] - which seems to work.   I'll start using
-g in
>>>>>> curl so
>>>>>> I don't have to escape the square braces.
>>>>>>
>>>>>> Wrapping the url in single quotes results in the single quote being
>>>>>> interpreted as part of the url itself, and curl complains that
>>>>>> "protocol
>>>>>> 'http is not supported".
>>>>>>
>>>>>> As for %22's... I cannot make that work at all.  If I encode double
>>>>>> quotes as %22's in curl, couchdb complains about invalid JSON, and
it
>>>>>> looks
>>>>>> as if all the %'s have been stripped out and the 22's become part
of
>>>>>> the
>>>>>> request.  For example the following request:
>>>>>>
>>>>>> (snip)
>>>>>>
>>>>> You are on windows, right?  In the regular windows shell, environment
>>>>> variable substitution is done with %ENV_VAR_NAME% (roughly equivalent
>>>>> to
>>>>> $ENV_VAR_NAME in bash).  So %22SYD%22 would mean "take the value of
the
>>>>> 22SYD environment variable and concatenate 22".  If there is no such
>>>>> env
>>>>> var, the result would just be "22". This fits with the invalid JSON
>>>>> couchdb
>>>>> is seeing.
>>>>>
>>>>> Long story short, I think you need to escape the '%'s from the windows
>>>>> shell.  I don't know how to do this, but I'm sure it is possible.
>>>>>
>>>> Aha!  Thank-you, Rhett - this never crossed my mind, though it makes
>>>> perfect
>>>> sense.  It's a simple matter of doubling the %  (%%) to ensure the
>>>> command
>>>> processor doesn't try to do the replacement.  When I just tried this, my
>>>> curl command worked fine, and as Brian suggested, I get a successful
>>>> result
>>>> whether I escape the quotes with backslashes or encoded them as %22's.
>>>>  Now
>>>> I just need to figure out why the HTTPService from Flex is not
>>>> working...
>>>> clearly the url-encoding has nothing to do with it and I've no doubt got
>>>> an
>>>> unrelated bug in my own work.
>>>>
>>>> Best regards,
>>>> Kai
>>>>
>>>>
>>>>
>>>>> Rhett
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Mime
View raw message