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 <[email protected]> wrote:
>>
>> On Apr 7, 2010, at 7:14 PM, Ning Tan wrote:
>>
>>> On Wed, Apr 7, 2010 at 2:05 AM, J Chris Anderson <[email protected]> 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.
>>
>>
