janl commented on issue #1200: [DISCUSS] CouchDB Request Size Limits
URL: https://github.com/apache/couchdb/pull/1200#issuecomment-370381759
Summing up, here are the things we need to decide:
1. What is the desired behaviour for CouchDB?
1. Replication can fail if sum(attachments.size) > max_http_request_size
(2.1.0 and later). We document this and move on.
1. Things fail randomly plus a DOS vector, because, if at all, we have a
4GB limit for documents sizes (CouchDB 2.0.0 and earlier).
1. A document that can be written to CouchDB can also be replicated to
another CouchDB instance with the same configuration (including itself) AND
there are request/document/attachment size limits in place that make it easy to
operate CouchDB on the internet.
* * *
If iii., there are two options (so far, please suggest more ;):
1. As outlined in this issue, use a combination of `max_document_size`,
`max_attachment_size` and `max_attachments_per_doc` to stay under
`max_http_request_size` to ensure smooth replication.
1. alternatively: on document/attachment write, check against a
`max_http_request_size` quota and reject doc updates, attachment updates, and
attachment additions that would take a document over `max_http_request_size`.
* * *
2. Should we decide on iii, what is the baseline for the new behaviour with
regards to semantic versioning?
1. We start enforcing new limits in the next *minor* version release of
CouchDB (2.2.0 or 2.3.0 depending on how fast we can resolve this). This would
mean breaking backwards compatibility with 2.0.0 and earlier releases,
including all 1.x releases. If we do this, the release notes should be very
upfront about this.
1. Same as i., but we do this for the next *major* version of CouchDB
(3.0.0), BC-breaks are of less concern here, although the upgrade notes should
be extensive.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services