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.
