couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Creating attachments from HTML's INPUT type="file"
Date Tue, 21 Apr 2009 15:52:40 GMT
On Tue, Apr 21, 2009 at 11:44 AM, Dean Landolt <> wrote:
> On Mon, Apr 20, 2009 at 11:54 PM, Curt Arnold <> wrote:
>> On Apr 19, 2009, at 7:01 AM, Jan Lehnardt wrote:
>>> On 19 Apr 2009, at 05:16, Oliver Boermans wrote:
>>>  ...
>>>>  Excellent summary, thanks! We're open to enable the API handlers for
>>> pure HTML forms with more features, if you can line out what you would
>>> want to have.
>>> Moving to dev@
>>> Cheers
>>> Jan
>>> --
>> I haven't had the time I would like to research this adequately.  I thought
>> it would good to keep the discussion going, so please forgive any obvious
>> blunders.
>> Feature: End point for HTML form submissions for file uploading
>> Use case: Uploading files from browser when their is not intermediate
>> layer.
>> Info that must be encoded somewhere:
>> database URL
>> docID
>> rev (for modifications)
>> content type of attachment
>> content of attachment
>> attachment name
>> Possible locations:
>> database URL: That has to go in the action URL for the form
>> Content of attachment: In body of POST request per HTML spec
>> docID: Could be encoded in either the action URL, content of a field
>> (possibly hidden), or field name.
>> rev: Same options
>> Content type: The POST request will have a content-type from the browser in
>> the header for the file content, however the form author may want to allow
>> the user to explicitly specify a content type.
>> Attachment name: Name of input type="file" field, names of files selected,
>> content of hidden field
>> Considerations:
>> Should we provide a mechanism to change the body of the document
>> simultaneously.  For example, if there is a field "body", it would be
>> interpreted as JSON and replace the current document contents.
>> A file input control can select and upload multiple files.  If attachment
>> name is based on the field name, likely would need to add an index to
>> support the case when there are multiple files selected.
>> The local file names may be missing from the post body, might not be unique
>> and might be approximations.  I'd avoid basing the attachment name off of
>> them, thought it would be good if they could be preserved.  Any chance that
>> they could be added to the _attachments metadata?
>> My current though is something like:
>> Action URL: http//server:5984/database/_form?multi=true|false
>> Special field names for docID, rev and body
>> If multi=true, multiple selections of files would be supported and
>> attachments would be named from the field name + [index]
>> If multi=false, if multiple files were selected, the request would be
>> rejected.  Otherwise attachment would be named after the input field
>> For every file input control, if there is another field with that name +
>> "content-type", the value of that field would be used for the content type.
>>  Otherwise, the content type provided by the browser would be used.
>> Ideally, the local names of the uploaded files would be preserved in the
>> metadata for the attachment.
> This seems like an awful lot of special case weirdness, and there are
> probably more edge cases than you've identified so far. And this only
> addresses attachments -- there were some interesting ideas posed on the list
> some time back about how to do unobtrusive form handling, but there were
> still were some oddities, particularly around strings vs. numbers and
> deeply-nested objects.
> I know this is sacrilege, but wouldn't this be best handled by action
> servers?

This is the way to go. Not action servers exactly, but an update
handler, for JavaScript which can translate a Req to JSON for PUT.
Patches welcome or I'll get to it eventually.

>Of course, you could always bury a form handler in a wsgi or rack
> app or whatever (even a jack app in js) as an _external, but obviously
> that's not very portable. Baking action servers into couch is the only sane
> way to solve this problem for something like couchapps (a jsonp service is
> out of the question for write ops). And it shouldn't be any trouble with
> sharding.
> So maybe action server is the wrong word, and I know it could totally get
> abused (hell, I *know *I would abuse it), but wouldn't it be great if form
> handling could be embedded in design docs with all the other app logic?

Chris Anderson

View raw message