Attachment length is undefined in validation function

[OldSneerJaw]

Expected Behavior

When a new attachment (e.g. my-attachment.txt) is added to a document by way of the PUT /db/doc/attachment endpoint, the length/size of the attachment should be exposed to the validation function by way of the newDoc._attachments['my-attachment.txt'].length field.

Current Behavior

In the case described above, the newDoc._attachments['my-attachment.txt'].length field has a value of undefined when the attachment is first added. However, on subsequent revisions to the document, the newDoc._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:

1. Document A is created in revision 1 with some arbitrary content
2. Attachment my-attachment.txt is added to document A via PUT /db/doc/attachment in revision 2
3. The content of document A is replaced in revision 3

In step 2, the attachment object's length will be undefined when the validation function is executed. But in step 3, the attachment object's length will have the correct integer value when the validation function is executed.

Steps to Reproduce

1. Add a design document with the following validation function:

function(newDoc, oldDoc) { 
  var names = Object.keys(newDoc._attachments); 
  for (var nameIndex = 0; nameIndex < names.length; nameIndex++) { 
    var name = names[nameIndex]; 
    var attachment = newDoc._attachments[name]; 
    if (attachment.length > 25) { 
      throw { forbidden: 'Maximum attachment length (25 bytes) exceeded by ' + name }; 
    } 
  }
}

2. Add an attachment that exceeds the 25 byte limit defined in the validation function. Much to my chagrin, it will be allowed.

PUT /test/attachment-length-test/foo.txt HTTP/1.1
Host: localhost:5984
Content-Type: text/plain
Authorization: Basic ********

This is a simple text file whose length exceeds 25 bytes.

3. Attempt to add a second attachment that does not violate the constraint:

PUT /test/attachment-length-test/bar.txt?rev=1-0300ab1eae40ff6acda7c8772ed7a3e7 HTTP/1.1
Host: localhost:5984
Content-Type: text/plain
Authorization: Basic ********

This is short enough!

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:

{
    "error": "forbidden",
    "reason": "Maximum attachment length (25 bytes) exceeded by foo.txt"
}

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

• Version used: 2.1.1
• Browser Name and version: N/A
• Operating System and version (desktop or mobile): macOS High Sierra
• Link to your project: https://github.com/OldSneerJaw/couchster

[wohali]

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.