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.
