couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Lehnardt (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1123) Longpolling changes feed with filter and accidental Content-Length header stalls
Date Sat, 16 Apr 2011 17:43:05 GMT


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"

> Longpolling changes feed with filter and accidental Content-Length header stalls
> --------------------------------------------------------------------------------
>                 Key: COUCHDB-1123
>                 URL:
>             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:

View raw message