jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: Wrong Content-Type when uploading via Webdav
Date Tue, 21 Feb 2012 10:46:49 GMT
On 2012-02-21 11:31, Subscriber wrote:
> 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

Good catch!

Can you please file an issue in JIRA?

Best regards, Julian

Mime
View raw message