incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: Issue with null MIME type for attachments
Date Sun, 25 Jan 2009 21:06:22 GMT
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.

Mime
View raw message