[ 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