Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 15261 invoked from network); 25 Jan 2009 21:25:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Jan 2009 21:25:47 -0000 Received: (qmail 60335 invoked by uid 500); 25 Jan 2009 21:25:45 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 60303 invoked by uid 500); 25 Jan 2009 21:25:45 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 60291 invoked by uid 99); 25 Jan 2009 21:25:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Jan 2009 13:25:45 -0800 X-ASF-Spam-Status: No, hits=2.4 required=10.0 tests=NORMAL_HTTP_TO_IP,SPF_PASS,URIBL_RHS_DOB,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of b.candler@pobox.com designates 208.72.237.25 as permitted sender) Received: from [208.72.237.25] (HELO sasl.smtp.pobox.com) (208.72.237.25) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Jan 2009 21:25:37 +0000 Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 1F3851D47C for ; Sun, 25 Jan 2009 16:25:14 -0500 (EST) Received: from mappit (unknown [80.45.95.114]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id C4E9D1D47B for ; Sun, 25 Jan 2009 16:25:13 -0500 (EST) Received: from brian by mappit with local (Exim 4.69) (envelope-from ) id 1LRCTg-0007IP-AC for user@couchdb.apache.org; Sun, 25 Jan 2009 21:25:12 +0000 Date: Sun, 25 Jan 2009 21:25:12 +0000 From: Brian Candler To: user@couchdb.apache.org Subject: Re: Issue with null MIME type for attachments Message-ID: <20090125212512.GA27830@uk.tiscali.com> References: <20090125164143.GA19119@uk.tiscali.com> <20090125202548.GL24162@tumbolia.org> <20090125210622.GB26564@uk.tiscali.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090125210622.GB26564@uk.tiscali.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Pobox-Relay-ID: A76BF862-EB26-11DD-A2AF-BE78113D384A-28021239!a-sasl-quonix.pobox.com X-Virus-Checked: Checked by ClamAV on apache.org 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.