Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <20209404.post@talk.nabble.com>
Date: Tue, 28 Oct 2008 08:42:54 -0700 (PDT)
From: Dave Fried <dfried@phoenix-int.com>
To: users@jackrabbit.apache.org
Subject: Re: GET webdav method - bad http content type
In-Reply-To: <4905CE76.4020903@sib.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
References: <4905CE76.4020903@sib.fr>


I have seen this happen with Slide when the content type property of the fi=
le
was not set correctly on upload.  Do you know if your client sends the
appropriate client type on a PUT/POST request?  If it is a bad content-type=
,
one of the following MAY be the problem:
 * the client is sending the wrong content-type
 * the client is not sending any content-type and the server is
mis-interpreting the type
 * the client is not sending any content-type and the server does not
recognize the file type, so it is defaulting to text/html
 * same as previous, but the server isn't sending anything at all, so the
web browser defaults to text/html

Make sure your build contains the properties file "mimetypes.properties",
which contains mappings for file extensions to MIME types.  This is require=
d
for the server to interpret file types when the client does not send the
type.  I see that .doc, .rtf, etc. are already listed in the default versio=
n
of the file, so your build may just not be loading it properly.

If you want to know whether it's a default value being provided by the
server or browser, you can edit config.xml to enable the
"<mimetypeproperties>" element, then set something random for
"<defaultmimetype>".  If this shows up in the browser, then it's falling
back to the default.

Not sure if that will help, but hopefully it will.


THIBAULT Joseph wrote:
>=20
> We try to use jackarabbit webdav server to store several document format=
=20
> (word, rtf, excel, txt ...).
> When we send a GET HTTP webdav request to these documents (from ie for=20
> instance), jackrabbit return the document with HTTP header content-type=
=20
> value =E2=80=9Ctext/html=E2=80=9D and not a content-type value text/rtf o=
r=20
> application/msword or text/plain or =E2=80=A6
> As a result, ie doesn=E2=80=99t display correctly some documents like exc=
el or=20
> rtf. It displays the binary and doesn=E2=80=99t call correct editor like =
excel=20
> or word for rtf.
> Is it a jackrabbit 1.4 bug or a bad use?
>=20
> Joseph
>=20
>=20

--=20
View this message in context: http://www.nabble.com/GET-webdav-method---bad=
-http-content-type-tp20188808p20209404.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.