couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kai Griffin <...@griffinbyteworks.com>
Subject Re: URL encoding issue
Date Tue, 19 May 2009 19:07:21 GMT
That's an interesting discussion.  I can't say I'm as concerned about 
using POST to _bulk_docs in lieu of PUT as some, but that's probably a 
reflection of my relatively recent move into the RESTful world, not to 
mention to couchdb itself.  I guess I'm just struggling to understand 
why one is preferable to the other, even if the other is represents a 
work-around.  In any case, _bulk_docs certainly works for me :-)  Mind 
you, I would no doubt feel a lot more strongly about the 
x-http-method-override idea if I needed DELETE; in my application, 
remote clients will not be deleting stuff - at best, records will be 
flagged as "deleted", but left in place.  The only work around I can 
think for the lack of DELETE in my http client would be to write an 
external process that gets launched via couchdb's external http handlers 
mechanism to handle the deleting for me - that's certainly clunky, but 
would get the job done.

While discussing problematic clients like Flash, couchdb's lack of 
support for the need of a crossdomain policy file for certain clients 
such as Flash and Silverlight had me tearing my hair out for awhile (I 
have been evaluating both, though have since tossed out Silverlight).  
The biggest problem is Silverlight, because it expects the crossdomain 
file to not only exist on the remote server, but also to exist through 
the same port (ie, 5984).  In the end, I got it working by duplicating 
the erlang code that handles favicon.ico requests to make a new handler 
for requests to /crossdomain.xml .  Rather fun, as it was my first 
exposure to erlang... but obviously very much a hack!

Cheers,
Kai

On 19/05/2009 17:12, Jared Scheel wrote:
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message