incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <jch...@gmail.com>
Subject Re: Do change notification (filters) support HTTP verbs other than GET?
Date Thu, 08 Apr 2010 14:45:29 GMT

On Apr 8, 2010, at 5:41 AM, Ning Tan wrote:

> My filter function is
> 
> function(doc, req)
> {
>   return true;
> }
> 

OK. that looks good enough. :)

Somehow I thought you were doing something stateful, based on your earlier description.

BTW, you don't need to include json2.js as it is already available to your functions.

If you want to try with a POST instead of a GET, you can edit one line in couch_httpd_db.erl

handle_changes_req(#httpd{method='GET'}=Req, Db) ->

to:

handle_changes_req(Req, Db) ->

which should allow for POSTs to _changes.


> :-)
> 
> On Wed, Apr 7, 2010 at 11:37 PM, J Chris Anderson <jchris@gmail.com> wrote:
>> 
>> On Apr 7, 2010, at 7:14 PM, Ning Tan wrote:
>> 
>>> On Wed, Apr 7, 2010 at 2:05 AM, J Chris Anderson <jchris@apache.org> wrote:
>>>> 
>>>> On Apr 6, 2010, at 8:48 AM, Ning Tan wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> Do change notification filters (or change notifications in general)
>>>>> support HTTP verbs other than GET?
>>>>> 
>>>> 
>>>> Currently they only support GET, but it'd be a very short patch to expand
support to include POST.
>>> 
>>> Thanks. I'm going to see if I can create such a patch. Time to learn a
>>> bit more about Futon tests.
>>> 
>>> Also, in the meantime, I'm trying to "hack" the solution by sending a
>>> request body with a GET. It seems that the body reaches my filter
>>> function fine (via req.body), but for some reason the response from
>>> Couch hangs whenever I send the body, even for a filter function that
>>> just returns true.
>>> 
>>> If I remember correctly, the response was like
>>> 
>>> { results: [
>>> 
>>> and then the curl session just sits there.
>>> 
>>> My curl command was something like:
>>> 
>>> curl -d '["id1","id2"]' -X GET $DB/_changes?filter=app/myFunc
>>> 
>>> The minute I took out the body, the problem went away.
>>> 
>>> I understand that sending a body with GET is not a standard way of
>>> doing things, but the hanging part was really weird anyway. It was so
>>> close to being a working solution. :-) I can get you more details if
>>> needed.
>>> 
>> 
>> It might just be the filter function.
>> 
>> Can you provide the code for your filter function?
>> 
>> Your GET/body trick is intriguing. I think a lot of proxies and clients wont' support
it, but it could work in your use case.
>> 
>>> Thanks for your help.
>> 
>> 


Mime
View raw message