Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <76AF69AA-BEA6-493C-9554-EE74149D162C@apache.org>
From: Curt Arnold <carnold@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <0E06DEA4-4F96-4B85-A632-9789B3FAFD4A@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Creating attachments from HTML's INPUT type="file"
Date: Mon, 20 Apr 2009 22:54:07 -0500
References: <1A1A730B-6A6C-4CD6-81B1-58F1D7F4980A@apache.org>
 <b11e05440904190216r63756c3bh405aa634c205b9c1@mail.gmail.com>
 <0E06DEA4-4F96-4B85-A632-9789B3FAFD4A@apache.org>


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.