You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Ning Tan <ni...@gmail.com> on 2010/04/08 04:14:33 UTC
Re: Do change notification (filters) support HTTP verbs other than
GET?
On Wed, Apr 7, 2010 at 2:05 AM, J Chris Anderson <jc...@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.
Thanks for your help.
Re: Do change notification (filters) support HTTP verbs other than
GET?
Posted by Ning Tan <ni...@gmail.com>.
On Thu, Apr 8, 2010 at 7:11 PM, J Chris Anderson <jc...@gmail.com> wrote:
>
> On Apr 8, 2010, at 4:06 PM, Ning Tan wrote:
>
>>> On Thu, Apr 8, 2010 at 10:45 AM, J Chris Anderson <jc...@gmail.com> wrote:
>>>>
>>>> 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.
>>
>> I did this and was able to see the body in my function also.
>>
>> Unfortunately, the same hanging behavior persists as long as the
>> request has a body. I'll see if I can post a script that mimics what
>> I'm doing soon. Meanwhile, it's pretty simple. Just create a filter
>> function that simply returns true and have a body in the changes
>> request against that function.
>
> This should be pretty trivial to add as a test case to the change.js test that ships with CouchDB. If you write that test you get your name in our THANKS file. (Maybe not the most glorious reward, but still pretty solid!)
>
Hi Chris, I added a test case in change.js as well as the httpd erl
file as you suggested. Should I create a ticket and attach my patch or
e-mail the patch to you directly?
Thanks.
Re: Do change notification (filters) support HTTP verbs other than
GET?
Posted by Ning Tan <ni...@gmail.com>.
On Thu, Apr 8, 2010 at 7:11 PM, J Chris Anderson <jc...@gmail.com> wrote:
>
> This should be pretty trivial to add as a test case to the change.js test that ships with CouchDB. If you write that test you get your name in our THANKS file. (Maybe not the most glorious reward, but still pretty solid!)
>
> Chris
Hi Chris,
I just submitted a Jira ticket for this:
https://issues.apache.org/jira/browse/COUCHDB-735
Thanks.
Re: Do change notification (filters) support HTTP verbs other than GET?
Posted by J Chris Anderson <jc...@gmail.com>.
On Apr 8, 2010, at 4:06 PM, Ning Tan wrote:
>> On Thu, Apr 8, 2010 at 10:45 AM, J Chris Anderson <jc...@gmail.com> wrote:
>>>
>>> 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.
>
> I did this and was able to see the body in my function also.
>
> Unfortunately, the same hanging behavior persists as long as the
> request has a body. I'll see if I can post a script that mimics what
> I'm doing soon. Meanwhile, it's pretty simple. Just create a filter
> function that simply returns true and have a body in the changes
> request against that function.
This should be pretty trivial to add as a test case to the change.js test that ships with CouchDB. If you write that test you get your name in our THANKS file. (Maybe not the most glorious reward, but still pretty solid!)
Chris
Re: Do change notification (filters) support HTTP verbs other than
GET?
Posted by Ning Tan <ni...@gmail.com>.
> On Thu, Apr 8, 2010 at 10:45 AM, J Chris Anderson <jc...@gmail.com> wrote:
>>
>> 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.
I did this and was able to see the body in my function also.
Unfortunately, the same hanging behavior persists as long as the
request has a body. I'll see if I can post a script that mimics what
I'm doing soon. Meanwhile, it's pretty simple. Just create a filter
function that simply returns true and have a body in the changes
request against that function.
Re: Do change notification (filters) support HTTP verbs other than
GET?
Posted by Ning Tan <ni...@gmail.com>.
On Thu, Apr 8, 2010 at 10:45 AM, J Chris Anderson <jc...@gmail.com> wrote:
>
> 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.
Great. I'll give it a try and let you know.
Re: Do change notification (filters) support HTTP verbs other than GET?
Posted by J Chris Anderson <jc...@gmail.com>.
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 <jc...@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 <jc...@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.
>>
>>
Re: Do change notification (filters) support HTTP verbs other than
GET?
Posted by Ning Tan <ni...@gmail.com>.
On Thu, Apr 8, 2010 at 8:41 AM, Ning Tan <ni...@gmail.com> wrote:
> My filter function is
>
> function(doc, req)
> {
> return true;
> }
>
> :-)
What I meant is that I'm even having the hanging problem with the
above barebones function. The actual function I wrote earlier was:
function (doc, req)
{
// !code lib/json/json2.js
var found = false;
if (req.query.oids)
{
var oids = JSON.parse(req.query.oids);
var found = oids.indexOf(doc._id) >= 0;
}
return found;
}
json2.js was taken from Crockford website.
Re: Do change notification (filters) support HTTP verbs other than
GET?
Posted by Ning Tan <ni...@gmail.com>.
My filter function is
function(doc, req)
{
return true;
}
:-)
On Wed, Apr 7, 2010 at 11:37 PM, J Chris Anderson <jc...@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 <jc...@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.
>
>
Re: Do change notification (filters) support HTTP verbs other than GET?
Posted by J Chris Anderson <jc...@gmail.com>.
On Apr 7, 2010, at 7:14 PM, Ning Tan wrote:
> On Wed, Apr 7, 2010 at 2:05 AM, J Chris Anderson <jc...@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.