jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3240) Wrong Content-Type when uploading via MAC OS Webdav client
Date Tue, 21 Feb 2012 11:29:34 GMT

    [ https://issues.apache.org/jira/browse/JCR-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212518#comment-13212518

Julian Reschke commented on JCR-3240:

a) Jackrabbit not looking at the input stream for PROPFIND is strange; we should find out
what's going on here.

b) Jetty re-using the stream is weird; I'd be surprised if the servlet spec allows that behavior...
> Wrong Content-Type when uploading via MAC OS Webdav client
> ----------------------------------------------------------
>                 Key: JCR-3240
>                 URL: https://issues.apache.org/jira/browse/JCR-3240
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-server
>    Affects Versions: 2.2.5
>         Environment: Jetty 6.1.22, Mac OS X Webdav Client: "WebDAVFS/1.8.3 (01838000)
Darwin/10.8.0 (x86_64)"
>            Reporter: ZFabrik
> 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
> 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

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message