You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Jan Lehnardt (JIRA)" <ji...@apache.org> on 2011/04/16 19:43:05 UTC
[jira] [Commented] (COUCHDB-1123) Longpolling changes feed with
filter and accidental Content-Length header stalls
[ https://issues.apache.org/jira/browse/COUCHDB-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020635#comment-13020635 ]
Jan Lehnardt commented on COUCHDB-1123:
---------------------------------------
As per RFC2616 GEt requests can have a body and thus a valid Content-Length header.
Technically, you are sending a malformed HTTP request. The question now is how CouchDB should behave. I agree that the current behaviour is odd.
I'd propose that we respond with a 400 Bad Request, but I am happy for other suggestions.
Fwiw, querying with a GET body does work as expected:
> curl -X GET $COUCH'/a/_changes?filter=test/foo&feed=longpoll' -H"Content-Length: 2" -d "ab"
{"results":[
{"seq":1,"id":"_design/test","changes":[{"rev":"1-0b4478e601ec850f0d3c009b9889917b"}]},
{"seq":2,"id":"3fb73daa9078091698c732c8130018be","changes":[{"rev":"1-23202479633c2b380f79507a776743d5"}]}
],
"last_seq":2}
> Longpolling changes feed with filter and accidental Content-Length header stalls
> --------------------------------------------------------------------------------
>
> Key: COUCHDB-1123
> URL: https://issues.apache.org/jira/browse/COUCHDB-1123
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
> Affects Versions: 1.0.2
> Environment: Mac OS X Snow Leopard, Ubuntu 10.10.
> Reporter: Jyrki Pulliainen
> Priority: Minor
> Labels: changes, contentlength, couchdb, header, http
>
> CouchDB behaves erroneously when doing a GET request with Content-Length header to long polling changes feed with filter set.
> Easiest way to reproduce:
> 1. Create a new DB
> 2. Create a single design doc with a filter that just returns true
> 3. Query database with curl: curl -v -H "Content-Length: 123" http://localhost:5984/database/_changes?feed=longpoll&filter=designdoc/filter
> At this point CouchDB behaves strangely. It does not wait for the client to feed the Content-Length bytes of content (which I think is correct, since GET should not have payload), instead, it returns 200 OK and starts the response with '{"results":['. However, no changes done to database ever get emitted and the connection never gets closed, not even if explicit timeout is set upon the request.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira