Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of tom@thomas-harding.name
 designates 88.170.168.121 as permitted sender)
Message-ID: <4AA27D6A.1040102@thomas-harding.name>
Date: Sat, 05 Sep 2009 17:02:02 +0200
From: Thomas Harding <tom@thomas-harding.name>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: attachments "Content-Type" seems to be based on file extension.
References: <4AA27CAD.5080001@thomas-harding.name>
In-Reply-To: <4AA27CAD.5080001@thomas-harding.name>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


As Paul Davis said, Content-Type is filled by the client which upoads 
the file,
not the server.

apologies...

Thomas Harding wrote:
> Hello,
> As said in the title, attachments "Content-Type" seems to be based on 
> file extension.
>
> Simply renaming an UTF-8 text file from "test" to "test.text", and 
> upload both with
> Futon, causes the first to be interpreted as 
> "application/octet-stream" and the
> second to "text/plain".
>
>
> This is a bit annoying while indexing as fulltext via couchdb-lucene, 
> as the last
> uses the provided content-type to fill apache tika requests, which 
> handles a few
> files types.
>
> Is there a way to ensure (force) the "Content-type" given by couchdb?
>