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:25:12 GMT
On Sun, Jan 25, 2009 at 09:06:22PM +0000, Brian Candler wrote:
> 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.

And the other case I hadn't considered was inline attachment with no
content_type specified at all:

$ curl -d '{"_attachments":{"foo.txt":{"data":"aGVsbG8="}}}' http://127.0.0.1:5984/test_suite_db;
echo
{"ok":true,"id":"463a4a56aed36c3de44cae6f35df2507","rev":"2681060313"}
$ curl http://127.0.0.1:5984/test_suite_db/463a4a56aed36c3de44cae6f35df2507; echo
{"_id":"463a4a56aed36c3de44cae6f35df2507","_rev":"2681060313","_attachments":{"foo.txt":{"stub":true,"content_type":"application/octet-stream","length":5}}}

Ah, so *now* you get application/octet-stream :-)

Summarising current behaviour:

1. uploading attachment with no Content-Type: header: fails
2. inline attachment with no content_type: gives application/octet-stream
3. inline attachment with bad (non-string) content_type: stores the bad value,
   and this gives badarg when you later try to download it

I think (1) should behave as (2), and (3) should behave as (1).

However I wouldn't object if "content_type":null was treated more gracefully
as if content_type were absent entirely.

Regards,

Brian.

Mime
View raw message