couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1123) Longpolling changes feed with filter and accidental Content-Length header stalls
Date Thu, 28 Apr 2011 21:33:03 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026706#comment-13026706
] 

Randall Leeds commented on COUCHDB-1123:
----------------------------------------

Without looking I think throwing here would cause a 500 to be sent to the client when we should
probably send 400 instead and put something useful in the response body.

> 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

Mime
View raw message