[
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 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.
--
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
