Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of b.candler@pobox.com designates
 208.72.237.25 as permitted sender)
Date: Sun, 25 Jan 2009 21:06:22 +0000
From: Brian Candler <B.Candler@pobox.com>
To: user@couchdb.apache.org
Subject: Re: Issue with null MIME type for attachments
Message-ID: <20090125210622.GB26564@uk.tiscali.com>
References: <20090125164143.GA19119@uk.tiscali.com>
 <e282921e0901251010sebf718ej8c218063a0a61725@mail.gmail.com>
 <B686ACEB-FACC-4F5D-B13C-95F09B529B58@gmail.com>
 <20090125202548.GL24162@tumbolia.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090125202548.GL24162@tumbolia.org>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

On Sun, Jan 25, 2009 at 08:25:48PM +0000, Noah Slater wrote:
> On Mon, Jan 26, 2009 at 06:49:53AM +1030, Antony Blakey wrote:
> > Treat a supplied null as an error.
> >
> > If mimetype isn't supplied, use a default based on the attachment name.
> 
> Default based on attachment name sounds misleadingly simple
> 
> I agree that this should be the way forward but we will need to:
> 
>   * ship a custom mime.types configuration file under /etc
>   * know how to read the system mime.types file usually at /etc/mime.types
>   * know how to pick up any other user supplied mime.types file
>   * add configuration options for this in the ini files
> 
> Check your local mime.types file for more hints. The format is pretty simple.

For consistency, whatever logic chosen should also apply to uploads of
standalone attachments without any Content-Type header. As far as I can tell
using telnet, these give a badarg response at the moment.

RFC 2616 allows you to guess based on extension, but also allows you to
default to application/octet-stream. (7.2.1)

   Any HTTP/1.1 message containing an entity-body SHOULD include a
   Content-Type header field defining the media type of that body. If
   and only if the media type is not given by a Content-Type field, the
   recipient MAY attempt to guess the media type via inspection of its
   content and/or the name extension(s) of the URI used to identify the
   resource. If the media type remains unknown, the recipient SHOULD
   treat it as type "application/octet-stream".

For now though, couchapp could use the ruby MIME::Types gem in place of its
own hard-coded table.

irb(main):008:0> MIME::Types.type_for('citydesk.xml').first.to_s
=> "application/xml"

Regards,

Brian.