jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Subscriber <subscri...@zfabrik.de>
Subject Re: Wrong Content-Type when uploading via Webdav
Date Tue, 21 Feb 2012 10:31:12 GMT
Hi all, 

I found the cause and would like to post my findings:
The problem seems to be caused by the way Jetty and Jackrabbit interoperates with each other
conditioned by a peculiarity of the MAC OS Webdav client:

0) Jetty resuses the request input-stream instance: org.mortbay.jetty.HttpParser$Input for
new requests.

1) A PROPFIND arrives with Content-Length=123 for example. It seems however that Jackrabbit
is not interested into the xml content at all.
2) A PUT arrives with Content-Length=0 (seem to be a peculiarity of the MAC OS Webdav client,
I have no clue why MAC OS is doing this. The real payload will be send a "few" requests later
within another PUT). 
3) Jetty reuses the InputStream which contains the xml content from the previous PROPFIND
request!
4) Jackrabbit uses Apache Tika in order to sleuth the content type and finds the xml from
the previous request (ignoring the fact the the Content-Length is 0)

The workaround I found proves my findings. I extended Jackrabbit's org.apache.jackrabbit.j2ee.SimpleWebdavServlet

containing an overwritten service() method:

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException {
    	super.service(request, response);
    	
    	// make sure input stream is eaten up
    	ServletInputStream ins = request.getInputStream();
    	while (ins.read() != -1);
    }

Now the input-stream is always eaten up so that the following request will get a clean input-stream.

Best regards
udo

Am 17.02.2012 um 15:48 schrieb Subscriber:

> Hi all, 
> 
> Uploading files via the Webdav servlet results to wrong content types under Mac OS X.
> 
> I mount a Jackrabbit (version 2.2.5) workspace under Mac OS X and copy files (e.g. images)
using the Finder.
> The problem is that the file is stored in the repository always as application/xml (javax.jcr.Property.JCR_MIMETYPE)
regardless what file is copied.
> 
> As a workaround I wrote a Servlet-Filter that sets the Content-Type according to the
http path. This filter is processed just before the WebdavServlet.
> While the PUT operation is processed the content type is read from the http request header
inside 
> 
>   org.apache.jackrabbit.server.io.ImportContextImpl.ImportContextImpl(Item, String, InputContext,
InputStream, IOListener, Detector) line 81.
> 
> However the "real" mimetype is determined using Apache Tika (it seems the Content-Type
is just a hint or so...).
> 
> I have no idea why this leads always to "application/xml" when using MAC OS as client
(maybe the stream is missing some magic bytes).
> 
> Does anybody have an idea how to fix this? Is there a way to force Jackrabbit to use
a certain content-type. 
> A workaround using a filter or so would be fine for me...
> 
> Thanks in advance and best regards
> 
> udo
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message