You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@couchdb.apache.org by Brian Candler <B....@pobox.com> on 2009/01/25 17:41:43 UTC

Issue with null MIME type for attachments

I am running couchdb SVN r736610 under Ubuntu Hardy (but with Erlang 12B3
packages from Intrepid)

After deploying sofa (git id 5222915fded972ddc55058c3fd97fa2bca366499) using
couchapp (gem 0.1.4), I notice that one of the attachments to _design/sofa
has a null content_type:

   "_attachments": {
       ...
       "to_couch.rb": {
           "stub": true,
           "content_type": null,
           "length": 1460
       },

And if I try to retrieve this using HTTP, I get an error:

$ curl http://127.0.0.1:5984/blogdb/_design/sofa/to_couch.rb
{"error":"error","reason":"badarg"}

Retrieving other attachments with non-null content types works fine.

Is it expected behaviour that a client app can upload an attachment in such
a way that it cannot be downloaded again? I think the server should either
fail the upload, or default the MIME type to application/octet-stream.

I see that couchapp is mapping MIME types via a Ruby hash:

    "content_type" => MIMES[path.split('.').last]

and since .rb is not known it is setting it to nil, which ends up as null in
the JSON.

The problem can be replicated easily without sofa/couchapp as follows:

$ curl -d '{"_attachments":{"foo.bin":{"content_type":null,"data":"aGVsbG8="}}}' http://127.0.0.1:5984/test_suite_db
{"ok":true,"id":"d166ec286f8fb05279e7770c225a610f","rev":"1376559224"}
$ curl http://127.0.0.1:5984/test_suite_db/d166ec286f8fb05279e7770c225a610f
{"_id":"d166ec286f8fb05279e7770c225a610f","_rev":"1376559224","_attachments":{"foo.bin":{"stub":true,"content_type":null,"length":5}}}
$ curl http://127.0.0.1:5984/test_suite_db/d166ec286f8fb05279e7770c225a610f/foo.bin
{"error":"error","reason":"badarg"}

Regards,

Brian.

Re: Issue with null MIME type for attachments

Posted by Michael McDaniel <co...@autosys.us>.

On Sun, Jan 25, 2009 at 10:10:10AM -0800, Chris Anderson wrote:
> On Sun, Jan 25, 2009 at 8:41 AM, Brian Candler <B....@pobox.com> wrote:
> 
> > Is it expected behaviour that a client app can upload an attachment in such
> > a way that it cannot be downloaded again? I think the server should either
> > fail the upload, or default the MIME type to application/octet-stream.
> 
> This is definitely a bug in Ruby couchapp, but you raise an
> interesting question.
> 
> Anyone have a strong opinion on which way to go (default vs error)?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 1) If a proper upload is defined that app must provide a MIME type,
    and none is provided by the app, return an error.  

 2) Define an upload as "provide your MIME type, or you'll get X".
    And it wouldn't hurt to send back info to the app that
    "MIME type was set to X".


 I suggest '1)'

~Michael


> 
> Chris
> 
> -- 
> Chris Anderson
> http://jchris.mfdz.com

-- 
Michael McDaniel
Portland, Oregon, USA
http://autosys.us

Re: Issue with null MIME type for attachments

Posted by Noah Slater <ns...@apache.org>.

On Mon, Jan 26, 2009 at 07:04:31AM +1030, Antony Blakey wrote:
>
> On 26/01/2009, at 6:55 AM, 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
>
> And deal with Windows.

Windows isn't supported. :)

-- 
Noah Slater, http://tumbolia.org/nslater