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
