-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Attachment length is undefined in validation function #1320
Comments
2.2.0 and forward will have a new way of defining maximum document sizes and may or may not have maximum allowed attachment sizes as well. See for reference: #1253 #1200 These will, however, be set at a server-wide level, not on a per-database setting. Unfortunately, the view server (couchjs) subsystem intentionally has no facility for accessing information as regards attachments. This was done intentionally very early on in CouchDB's development to ensure rapid performance of view building, even when attachments are large. We don't expect this to change any time soon. I hate to close this as a wontfix, but I hope that the above will provide some hope that you'll be able to achieve what you want soon. I would encourage you to comment on #1253 with your thoughts, and any enhancements you might think would be useful, so that we can enforce useful limits without having to resort to an inefficient VDU. |
The attachment size constraints (i.e. `attachmentConstraints.maximumIndividualSize`, `attachmentConstraints.maximumTotalSize` and the `attachmentReference` validation type's `maximumSize`) cannot be applied correctly to CouchDB documents due to a performance optimization that makes it impossible for a validation function to determine the size of an attachment as it is being created ([more info](apache/couchdb#1320)). The documentation has been updated to remove mention of the attachment size constraints, since they cannot be enforced. They will be removed from the code altogether in the future.
Expected Behavior
When a new attachment (e.g.
my-attachment.txt
) is added to a document by way of thePUT /db/doc/attachment
endpoint, the length/size of the attachment should be exposed to the validation function by way of thenewDoc._attachments['my-attachment.txt'].length
field.Current Behavior
In the case described above, the
newDoc._attachments['my-attachment.txt'].length
field has a value ofundefined
when the attachment is first added. However, on subsequent revisions to the document, thenewDoc._attachments['my-attachment.txt'].length
field is correctly populated with the length of the file in the validation function. For example, consider the following sequence of events:my-attachment.txt
is added to document A viaPUT /db/doc/attachment
in revision 2In step 2, the attachment object's
length
will beundefined
when the validation function is executed. But in step 3, the attachment object'slength
will have the correct integer value when the validation function is executed.Steps to Reproduce
The request will be rejected with the following response, indicating that the attachment that was added in the previous operation (
foo.txt
) is too large:Context
This issue prevents fine-grained control by the validation function over the maximum size of each individual attachment or the maximum size of all attachments combined since the size of each attachment as it is being added is
undefined
. For instance, one might want their validation function to prevent document attachments larger than 100KB and to ensure that all attachments combined are no larger than 500KB to prevent malicious/clueless users from filling up the DB's hard drive.Your Environment
The text was updated successfully, but these errors were encountered: