Couchdb: POST to _changes timeout when request.body is included

[stheobald]

Description

When POSTing to the _changes endpoint with a request.body, and not using one of the builtin filters (doc_ids for example) the connection always times out.
@rnewson has looked into this, and says "the code starts the response, and may even send it, but the web server itself (mochiweb) won't proceed because it still needs to read the request body first. we should send a 400 Bad Request if you send a body when it's unexpected"

Steps to Reproduce

curl 'foo:bar@localhost:15984/db1/_design/foo'
{"_id":"_design/foo","_rev":"1-1cfd4ef84175f09eb3d41bda94062244","filters":{"bar":"function() { return true; }"}}
​
curl 'foo:bar@localhost:15984/db1/_changes?style=all_docs&since=0&limit=100&filter=foo/bar' -XPOST -Hcontent-type:application/json --data-raw '{"doc_ids": ["foobar"]}'

Expected Behaviour

Return a 400 Bad Request error in preference to waiting for a timeout if a req.body is provided but unexpected (see enhancement request https://github.com/apache/couchdb/issues/3086 which may solve this bug as a side-effect)

Your Environment

Couchdb 3.1

[ricellis]

I think it is preferable to solve this by always reading the body rather than changing the existing behaviour to a 400 Bad Request. The existing POST /{db}/_changes endpoint that has been released in the wild for a long time permits other requests (i.e. not just those not using a filter) and any change to that behaviour would break existing code/users.

For example, whilst it is perhaps unusual to POST a {} body it's not completely unexpected given the way the API is described in the docs:

Requests the database changes feed in the same way as GET /{db}/_changes does, but is widely used with ?filter=_doc_ids

Nothing stated about it being valid _only_ for filters.

[stheobald]

@ricellis after discussing this with some of the maintainers, it has become apparent neither this, or the related enhancement is considered a high priority item, and is accordingly unlikely to be fixed by the volunteer maintainers in their free time. They did suggest that they'd consider fixing it as a paid gig.

In the meantime, I have found a workaround by having an API endpoint maintain a design document filter for each user. This mechanism allows me to pass what I would have hoped to pass in a req.body as a doc instead. Then I restart the replication with a reference to that updated filter. Replicating that design document to the client allows me to keep all clients associated with that user in sync.

[eiri]

Just want to drop a note here that I've found the root case for this bug and going to open PR with the fix after Holidays.

[eiri]

Fixed in https://github.com/apache/couchdb/pull/3373