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.
